Software Astrology

The Day of Intense Computation

Modules, products or systems built on December 11 have very serious code and purposeful goals. They are so directed towards their computational goals that sometimes it is difficult to stop them. In addition to intense and thoughtful computation they have commanding presence of UI. This combination makes them powerful software entities. Neglected and not sufficiently supported products and systems experience significant stress and may even break. Fortunately, having built-in resurrection (computational restart) capabilities they come back stronger with even more intense computation. These traits make them the most influential modules and subsystems both computationally and when presenting UI. Their messages are transparent and they display them openly sometimes even not aware of that. Modules, products or systems built on December 11 judge data to be right or wrong very seriously and may err on the wrong side which might have a severe effect on their component surroundings. Parent executables should be very careful not to over-control their children processes and their best strategy should probably be to close handles. Products and systems built on December 11 should be idle from time to time and threads belonging to subsystems and modules should voluntarily relinquish their assigned CPU. December 11 executables tend to gain vast memory sizes during their computational life. In such cases the amount of rich data they consume should be reduced.

DLL, SYS and EXE born on this date:

nvlddmkm.sys     Tue Dec 11 21:03:03 2007
WMP54Gv41x86.sys Mon Dec 11 09:38:10 2006
INDICDLL.dll     Sat Dec 11 01:16:39 1999

Weaknesses: Self-computation coupled with self-unawareness.

Strengths: Purposeful and influential both from UI and computational perspectives.

Advice: Fly with the direction of case resolution and accept whatever its outcome. Be positive about software and its creators. Do healthy laughing exercises.

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Inner Corruption

Modules, products or systems built on December 10 internalize their interactions and demand attention to themselves. Their computational goal is to serve other components which rarely understand their internals. On the contrary, components built on December 10 easily reveal their own internals even in untrusted environments. They constantly ponder about data they receive, check its existence and put their computational faith in CPU. We may thus say that modules, products or systems built on December 10 like to ask deep questions of philosophical nature in the realm of computing. As a result, their external interfaces give an impression of interface distancing and if they find a matching component it will be their protecting component container. Executables built on December 10 make good parent computational processes caring about their children and as controlling and elevated in priviledge processes they maintain good communication links with their co-processes and avoid resource conflicts. However products or systems built on December 10 may not handle stress well and therefore they must be careful not to corrupt themselves internally. They should always keep external interfaces open otherwise it can be very difficult to understand shared data they put and they should not depend on only one relationship component. It seems that spawning child processes and shared data consumption helps to improve their internal state.

DLL, SYS and EXE born on this date:

Tppwr.sys    Tue Dec 10 17:36:51 2002
cpqcissm.sys Fri Dec 10 18:19:51 2004
test.exe     Wed Dec 10 17:29:43 2008
WS2HELP.DLL  Fri Dec 10 20:33:21 1999
NETRAP.DLL   Fri Dec 10 20:33:20 1999
MPRAPI.DLL   Fri Dec 10 20:32:55 1999
ICMP.DLL     Fri Dec 10 20:32:54 1999
RTUTILS.DLL  Fri Dec 10 20:32:51 1999
atidrab.dll  Fri Dec 10 20:33:26 1999
rarext64.dll Sun Dec 10 23:14:54 2006
dtscsi.sys   Sat Dec 10 15:33:44 2005

Weaknesses: Inscrutable machine code.

Strengths: Calm threads. Spiritual computation. Appreciative UI.

Advice: Develop bonds with other debuggers and maintain a link with a family during debugging sessions. Believe in customers, users as well as in science. Don’t panic if debugger attach fails: fight to the end of problem resolution.

- Dmitry Vostokov @ SoftwareAstrology.com -

The Moon represents constant change and therefore it influences computer memory. Because the Moon symbolizes fertility it also influences the direction of software execution life-cycles, for example, the creation and destruction of objects. At the Full Moon corresponding software activity also increases. Being Time keeper the Moon influences whether software crashes and hangs, the so called “software fate”. Related to water the Moon represents the Great Ocean of Bits and also represents behaviour in software occurring without creator’s will or control. Three principal phases of the Moon correlate with software life-cycle: new code, fully matured code and discarded legacy code. Changeability of the Moon corresponds to observable irrational behaviour of software and unpredictable results. Never seen the dark side of the Moon corresponds to never seen software defects. Experience with the Moon influence on computer memory provides a great vision of the inner workings of software and makes it possible to really perceive ideal non-functional requirements before they translate to their implementation.

- Dmitry Vostokov @ SoftwareAstrology.com - 

The Day of Flamboyant Architecture 

Modules, products or systems built on December 9 are active nodes of distributed information processing. For them computation is an adventure involving exploits and surprise attacks. Born out of a highly subjective world of requirements their implementation varies greatly from one engineer’s understanding to another. Components built on December 9 can be great protectors of information and dependent relationships and can therefore unleash an aggressive power which may cause damage to data that is difficult to repair afterwards. The greatest challenge to modules, products or systems built on December 9 is to achieve code maturity. By developing into wise interface roles they have to leave some computational traits behind. Aged components become effective coding examples of a philosophical mind objective about itself and therefore useful to other engineers. Modules, products or systems built on December 9 must soften their real-time requirements and aggressive resource consumption otherwise it attracts remote break-ins or damages their hosts. Self-discovery of interfaces might be very useful for them. Care must be taken when dealing with security warriors.

DLL, SYS and EXE born on this date:

oledlg.dll    Thu Dec 09 16:46:39 1999
SiSRaid.sys   Tue Dec 09 02:43:34 2003
cercsr6.sys   Thu Dec 09 05:01:10 2004
ikfilesec.sys Sun Dec 09 22:37:01 2007 

Weaknesses: Misdirected implementation from fantasy-driven requirements.

Strengths: Fiery responsiveness. Energetic computation.

Advice: Sometimes it is useful to be an ordinary engineer and not a star programmer. Be positive about customers, testers and technical support. Keep your debugging grounded in base test cases.

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Orphaned Processes

Modules, products or systems built on December 8 are totally committed to their computational goals. However this creates problems with their responsibility to users and emerging tension can leave computational processes in agonizing state unless an environment is less hostile and some resources were reserved in advance. Over period of their life time components become adapted and begin to spend less of their allotted resources. Products built on December 8 often process overwritten data but don’t see that. They also have a tendency to use destructive interfaces and they seek absorbing component containers draining computational resources from them but giving almost nothing back. As a result, modules, products or subsystems built on December 8 are driven to abandon their hosting computational processes. Highly developed December 8 components are able to direct their resources into useful data output and be stable and acceptable during their computation. Internal state watchfulness and other interface awareness are very important to them because neighbouring modules and interfacing subsystems do not always have the same level of QoS. Modules, products or subsystems built on December 8 must set realistic expectations in order to preserve their internal state. They must be aware of all sorts of interface addictions which are characterized by a computational needs with increasing number of method calls. Therefore they must develop moderate enumeration techniques including remote interface discovery via detached proxies.

DLL, SYS and EXE born on this date:

cercsr6.sys  Wed Dec 08 18:31:10 2004
symc810.sys  Fri Dec 08 18:40:59 2000
MSIMG32.DLL  Wed Dec 08 17:18:25 1999
INDICDLL.DLL Wed Dec 08 17:17:52 1999
SHLWAPI.DLL  Wed Dec 08 11:11:49 2004
WS2HELP.DLL  Wed Dec 08 17:15:40 1999
NETRAP.DLL   Wed Dec 08 17:15:38 1999
NETUI1.DLL   Wed Dec 08 17:15:38 1999
ntshrui.dll  Wed Dec 08 17:15:03 1999


Weaknesses: Troubling behaviour. Indecisive if-else. Inconsistent state.

Strengths: Interesting code. Friendly UI. Energetic computation.

Advice: Be responsible during debugging sessions.

- Dmitry Vostokov @ SoftwareAstrology.com -

Opcodology /ɒpkɒˈdɒlədʒɪ/, noun

1: relationship between numbers and software behaviour. Derived from opcode and ology.

2: software codology. Derived from operation and codology (Irish slang).

Date: 21th century

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 2, 11, 19, 29
• Days of unfortunate computation: 7, 15, 23
• Days of good enough software behaviour: 5, 13, 21, 31
• Fault-free days: 9, 17, 26
• Days of customer grievance: 1, 2, 4, 6, 11, 12, 20

- Dmitry Vostokov @ SoftwareAstrology.com -

The Sun represents the inner self of software, its algorithm, its essence. “I see!” says a scientist or an engineer at the moment of insight and devises a clever algothrithm to illuminate a difficult problem. The Sun also symbolizes the outer software behaviour seen by its users which can be destructive sometimes (see my previous post, The Sun and Software).

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Idiosyncratic Code

Modules, products or systems built on December 7 are one of a kind. Having peculiar and just weird code they find it difficult to fit into module list or coexist with other systems and subsystems. Sometimes we can find them doing many types of abnormal things. Because of that they also interface well with other weird components. Components built on that date like to be accepted as normal so they occasionally fit well in DLL crowd. They struggle to fit and this has impact on their internals. During their earlier stages of development they often try to compute many different unrelated things and only after some time they choose the best domain of computational activity and therefore what they compute is not always financial stuff. Sometimes looking at behaviour of modules, products or systems built on December 7 we may believe in their failure to compute but in reality it was not at all. During their initial development stages they raise high expectations, often difficult to meet and this causes their violent computational behaviour resulting in their subsequent isolation. However components built on December 7 are fortunate to have caring developers during their life cycle who see their potential and bring the best and unique computational result out of them. These modules stand out of component crowd. However once they become older in the course of their life cycle of computational activity they should be careful not to become too isolated from the realities of computational world. Their computational dreams during idle cycles might leave them in abnormal memory states having little to do with their intended computational activities and goals. To counteract that they should keep minimum of normal computational activities while idle, maintain close interface contact with relationship components and post communication requests. In component relationships sometimes they might need to send messages to themselves. The code of December 7 components is very sensitive to changes. All external interfaces must be sealed. If they are surrounded by very small modules then it is good for them. To avoid computational allergies, modules, products or systems built on December 7 should have data access restrictions and do not have secret code counteracting code injection from other modules.

DLL, SYS and EXE born on this date:

cpqarry2.sys   Sat Dec 07 06:36:59 2002
CAXHWAZL.sys   Thu Dec 07 19:45:29 2006
CAX_DPV.sys    Thu Dec 07 19:48:04 2006
CAX_CNXT.sys   Thu Dec 07 19:44:27 2006
b57w2k.sys     Tue Dec 07 01:50:11 2004
ViPrt.sys      Fri Dec 07 03:12:39 2007
ViBus.sys      Fri Dec 07 03:13:17 2007
dump_ViPrt.sys Fri Dec 07 03:12:39 2007


Weaknesses: Peculiar code. Nervous computational responses to external events.

Strengths: Sensitive to external events. Highly individualized code.

Advice: Socialize with other engineers. Don’t expect much from your current debugging sessions. Take it easy and answer when phone rings.

- Dmitry Vostokov @ SoftwareAstrology.com -

It’s not about Sun company but about Sun, the star. It influences people and CPU as well. Either a single CPU or a CPU bundle in a multiprocessor or a multi-core hardware can be considered as a digital analog of the Sun that influences software. A phrase “A bug shines brighter than a thousand suns” can be attributed to an explosion inside OS kernel nucleus ruining the work of hundreds of users.

- Dmitry Vostokov @ SoftwareAstrology.com -