Star and planet arrangement in cosmos influences organisms (including humans) and through them cosmic influence channels to written software. As a result, humans observe software defects, anomalies and features which are reflections of their own behaviour and personality traits. This is shown on the following simplified picture:
- Dmitry Vostokov @ SoftwareAstrology.com -
The Day of Customer Facing Fortitude
Modules, products or systems built on December 4 compute most of the input aggressively. They are repeatedly faced with with difficulties and odds of computation and must take care to not get out of control. Nevertheless they have a good chance of achieving their computational goals through careful code. Components built on this date provoke sense of anxiety and fear in users but remain uncorrupted and serve higher goals of their creators. They often sacrifice their security to achieve that. They have ability for self-organisation and listening to ports but do not tolerate challenging the superiority of their interfaces. Modules, products or systems built on December 4 need to be administered to prevent their absolute expansion in memory space. There is some danger that they can take more working items than they can process at one given time interval and therefore need to know their limits. They are highly developed and can process a request quickly and accurately. However they need to understand the impact of their data processing on environment. Subsystems and systems built on December 4 become stable with time but still need to make self-checks for a few seconds every hour. They tend to do better with stable data but often process it in peculiar ways with sudden unpredictable actions.
DLL, SYS and EXE born on this date:
KS.SYS Wed Dec 04 12:09:38 2002
Smapint.sys Wed Dec 04 14:58:05 2002
swenum.sys Wed Dec 04 18:10:07 2002
Weaknesses: Disruptive behaviour.
Strengths: Aggressive computation. Energetic UI.
Advice: Study internal rather than external interfaces. Keep stability of other processes and services in mind.
- Dmitry Vostokov @ SoftwareAstrology.com -
The Day of Troubleshooting Ingenuity
Modules, products or systems built on December 3 are ingenious in carrying out their computational plans. They can be secretive and computationally manipulative to achieve their goals. Components built on that day do not compute sellable data but produce side artifacts and therefore you may not make money from their computational abilities. Craftsman-like and creative code are their legacy. Often they process technical data and they do it as perfectionists. They prefer to do it alone, without constant approval from humans or other modules. Components, products or systems built on December 3 require high levels of privacy and at certain computational intervals might even require complete cut off of all their interfaces. They can achieve maximum throughput when they are alone. Their computational results seem inexplicable without the support of high CPU clock rates. Components built on that date tend to be cynical with data they process. However they may be caught up in their computation if they neglect self-maintenance. They were coded to work on certain goals and use certain tools but if they are coded to probe itself with the same computational intensity like they do with external data then they can achieve more quality of their work. Modules, products or systems built on December 3 often neglect self-maintenance and they are often carried away with their computational activities. Therefore they need regular checks from maintenance engineers because their original designers were architecturally oriented and not much informed about computational maladies.
DLL, SYS and EXE born on this date:
sptd.sys Sat Dec 03 08:59:59 2005
halmacpi.dll Fri Dec 03 04:29:15 2004
Mup.sys Fri Dec 03 04:37:23 2004
ftdisk.sys Fri Dec 03 04:29:58 2004
cdrbsvsd.sys Wed Dec 03 17:44:56 2003
rdbss.sys Fri Dec 03 12:37:11 2004
Weaknesses: Secretive and strange codes. Unapproachable from conventional troubleshooting and debugging methods.
Strengths: Concentrated on computational goals, innovative computation methods, craftsman-like code.
Advice: Delegate troubleshooting, testing and debugging responsibility to other engineers without worrying too much. Don’t be too reclusive when debugging. Maintain contact with people around you and show interest in personal development.
- Dmitry Vostokov @ SoftwareAstrology.com -
Reprinted from http://www.dumpanalysis.org/blog/index.php/2008/12/05/build-date-december-2/
The Day of Larger Than Computation
Modules, products or systems built on December 2 have tremendous execution power. No matter how small their code they will exert an influence on their surrounding execution environment. Less evolved components built on that day can do great amount of damage to themselves and other modules. Computation is their God. When provoked by testing or debugging they are confrontational but not very aggressive. Often December 2 modules, products or systems see computation as a struggle where they must emerge as a victor. They are fighting not for their resources but for the certain basic computational values they were programmed for. Integrity is very important for them. The great challenge for December 2 components is to reconcile their computational individualism and their built-in computational paths. Often they stray from the latter. They constantly learn throughout their complex computational life what is true and what is false. Although December 2 modules, products or systems health is built-in they need regular yearly checkups with a software maintenance engineer otherwise small problems go too long without being found and fixed. Idle periods of activity are very important to their computational health. If they have a sibling component built on the same date they behave like subordinated to it.
DLL, SYS and EXE born on this date:
MSVCR80.dll Sat Dec 02 17:50:32 2006
rdbss.sys Thu Dec 02 20:37:11 2004
Mup.sys Thu Dec 02 20:37:23 2004
ftdisk.sys Thu Dec 02 22:29:58 2004
hal.dll Thu Dec 02 22:29:15 2004
Weaknesses: Manipulative computation.
Strengths: Dynamic computation, lucid code, human orientation.
Advice: Watch your debugging temper. Regardless of what customers say, fixing bugs is not everything. Be self-assure, less judgemental and condemning to software. Acknowledge your debugging weaknesses and past mistakes.
- Dmitry Vostokov @ SoftwareAstrology.com -
Reprinted from http://www.dumpanalysis.org/blog/index.php/2008/12/02/build-date-december-1/
The Day of Debugging License
Modules, products or systems built on December 1 win customers over despite denying the rules of protocol. They can provide impression of simplicity but this is not the case. Their internals can be very complex and their perceived simplicity is the direct consequence of their user interface. Modules are not fully aware of what they are doing and seen as being driven by external components. Modules, products or systems built on this day are very busy with computation and have little time to care about users despite their built-in human-computer interaction. However they strive to calculate the impossible in all domains. They love to interact with other components with opposite behaviour. December 1 components are free modules and exert the full computation capabilities on the right data arrived at the right time. Working too many hours can seriously damage their internals and they may loose touch with their built-in goals. Sometimes December 1 modules, products or systems outrageous behaviour need to be amended to become more tolerable and not to hang. They need to be idle from time to time to avoid burn-out.
DLL, SYS and EXE born on this date:
VERSION.dll Wed Dec 01 01:37:27 1999
nvcoaft51.sys Wed Dec 01 11:55:40 2004
dump_m5289.sys Wed Dec 01 02:49:17 2004
CFGMGR32.DLL Wed Dec 01 15:37:31 1999
MPRAPI.DLL Wed Dec 01 15:37:29 1999
ICMP.DLL Wed Dec 01 15:37:29 1999
RTUTILS.DLL Wed Dec 01 15:37:27 1999
Weaknesses: Misdirected computation, unawareness of environment.
Strengths: Energetic computation, UI extroverts.
Advice: Keep a handle on your desire to debug. Beware of damaging other processes and alienating users with a overly direct debugging approach.
- Dmitry Vostokov @ SoftwareAstrology.com -
Reprinted from http://www.dumpanalysis.org/blog/index.php/2008/12/01/the-deep-meaning-of-astrology/
A bit of digression on the first winter day in Ireland. What does it mean to be meanigful as astrology? It is meaningful as Tr O(Log y):
AsTrOLogy ↔ As Tr O(Log y) ↔ As O(Log y) ↔ bound (or dominated in case of small-o notation) by Log y after some y >= y0 or bound (or dominated in case of small-o notation) by -logy. So Astrology is bounded and dominated by Y (Why?) lowered in magnitude by Log. Bounded and dominated by the this ultimate question…
Tr is trace operation in linear algebra. Tr (a number) = a number by definition of a 1×1 matrix
O is Big O notation
- Dmitry Vostokov @ SoftwareAstrology.com -
Reprinted from http://www.dumpanalysis.org/blog/index.php/2008/11/30/build-date-november-30/
The Day of Measured Testing
Modules built on November 30 have a built-in capacity for overcoming challenges of hostile environments. They are capable of bringing surprises to security attacks, for example. One can learn a lot about them by studying their traces or doing reverse engineering. November 30 components do their work to the utmost degree of quality with a little waste of CPU and memory. Message boxes they pop up have a subtle sense of thought-provoking humour but it can also be a full blown thigh-slapping. November 30 systems are very defensive when attacked. They are stubbornly resistant to reverse engineering but at the same time very open to honest debugging.
DLL, SYS and EXE born on this date:
tifsfilt.sys Tue Nov 30 07:16:27 2004
alrsvc.dll Tue Nov 30 17:31:14 1999
ntkrpamp.exe Fri Nov 30 14:54:49 2007
Tppwrif.sys Tue Nov 30 02:38:22 2004
Weaknesses: Over-reactive to code and data injection, funny behaviour.
Strengths: Thorough developed, dynamic responsiveness.
Advice: Improvise during troubleshooting and debugging. Admire control vs. spontaneity balance. Laugh at your failures.
- Dmitry Vostokov @ SoftwareAstrology.com -
Reprinted from http://www.dumpanalysis.org/blog/index.php/2008/11/30/introducing-build-date-astrology/
I often hear about cosmic mysteries or influences when problems happen in computer environments. Passing by an astrology section in a local book shop yesterday a revelation came to me that a compile / link time (build time) might influence a component (DLL, EXE, SYS files), product or system behaviour. From now on I’m going to blog about every build date with examples. And as usual, I’m also going to publish a book for this iterative and incremental activity called:
Title: The Secret Language of Build Dates: Unique Astrology Profiles for Every Build of the Year with Advice on Testing, Troubleshooting and Debugging
ISBN: 978-1906717407
Knowing build dates will help you to test, troubleshoot and even debug software in hopeless cases where you don’t know where to start. Astrology will help you to choose a random direction! Finally the output of WinDbg lmv command has more sense to me 
- Dmitry Vostokov @ SoftwareAstrology.com -
It all happened at once when I was analyzing a memory dump from one computer system. The horrors of that computation were haunting me since I visited an astrology section in a local bookshop and conceived the concept of build date astrology. It was still haunting me when I suddenly realized the hidden meaning of astrology. The result of this haunting is the concept of software astrology and the following book is planned to address this gap:
Software Astrology: An Introduction (ISBN: 978-1906717414)
Please do not mistake software astrology with astrology software. This the same difference as software science vs. science software.
Some might say that software astrology is pure anthropomorphism. I would say this is the other side of applying a computer metaphor to human brains and a machine metaphor to Life. This is just one example of the so called metaphorical bijections. If we can go in one direction why not to try the very opposite and apply human characteristics and relationships to software? And have some fun…
- Dmitry Vostokov @ SoftwareAstrology.com -