Software Astrology

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 -

The Day of Information Extraction

We are able to extract information about modules, products or systems built on December 6 in any testing, troubleshooting or debugging scenario and sense economic advantage at the same time. In return they also have an eye for a diamond in the rough for any data potential. Components built on that day are managing components and not usually data writers. This might create problems with their component relationships. If they see problems they may destroy another component in not very pleasant way. Modules built on December 6 serve very pragmatic ends. We can find them in every practical system. They like to score performance hits and win in computational games. However they might fall as a victim to their over controlling policies. Modules, products or systems built on that day usually display diagnostic messages very directly. They are highly competitive so the there is a need for many processors. Components built on December 6 try to extract the best from the data they process and other components can benefit from that. Systems or subsystems built on December 6 need to cultivate tolerance and acceptance of other less developed components and if December 6 modules fail we can only blame them and not others. Modules, products or systems built on that date sometimes push themselves very hard to the limits of computation and the older they are in the course of their computational time arrow they should keep themselves in constrained limits. 

DLL, SYS and EXE born on this date:

ntldr        Mon Dec 06 14:00:00 1999
hsx_cnxt.sys Tue Dec 06 14:20:41 2005
hsx_dpv.sys  Tue Dec 06 14:21:27 2005
hsxhwazl.sys Tue Dec 06 14:20:47 2005
mscorwks.dll Thu Dec 06 16:48:39 2007
ati2mtag.sys Tue Dec 06 22:44:40 2005
yk60x64.sys  Thu Dec 06 08:50:34 2007
ati2dvag.dll Tue Dec 06 20:45:00 2005
ati2cqag.dll Tue Dec 06 19:44:46 2005
ati3duag.dll Tue Dec 06 20:29:51 2005
atikvmag.dll Tue Dec 06 20:11:09 2005
ativvaxx.dll Tue Dec 06 20:23:55 2005
WDFLDR.SYS   Thu Dec 06 02:21:19 2007
CLFS.SYS     Thu Dec 06 01:55:42 2007
Wdf01000.sys Thu Dec 06 02:21:28 2007
mouhid.sys   Thu Dec 06 02:18:25 2007
kbdhid.sys   Thu Dec 06 02:18:26 2007
kbdclass.sys Thu Dec 06 02:18:23 2007
mouclass.sys Thu Dec 06 02:18:22 2007
xarraydb.ocx Mon Dec 06 16:43:31 1999
yk51x86.sys  Thu Dec 06 13:56:41 2007

Weaknesses: Data insensitive and domineering overcomputation.

Strengths: Data pragmatism. Interface perception. Capable computation.

Advice: Learn to leave unevaluated bugs untouched. Don’t always plan debugging session. Take time off to think about general. Keep your problem resolution ethics intact no matter what customers demand.

- Dmitry Vostokov @ SoftwareAstrology.com -

The post title is yet another definition of software astrology to help search engines to catch up with this new discipline. For other definitions see Astrology of Software post.

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Confidence in Code

We can be confident that modules, products or systems built on December 5 get computation done. However this may not be justified and when they fail this might be due to previous look at code through rose-colored glasses. December 5 components prefer dynamic typing and they eager to share interfaces and often surprised when other modules around them do not share their mapped views. When become mature they start to be more respectful of other modules privacy. Confidence in modules, products or systems built on December 5 has many benefits. They are free from many self-checks and diagnostic messages that populate other non-confident components. However they often assure users that everything is ok when it is not. Because December 5 modules are of active type they do not let computation run astray. They have positive attitude towards data and this make their computation less complicated. As a consequence they also need more decision points and improved self-identity, realistic computational roles and goals. Repeated failures may guide their adaptation to computational fate and tame the nature of uncertainty. In the long run December 5 systems become dependable. Modules, products or systems built on December 5 may experience all types of failures, especially rash ones built on that day but they recover quickly. Consistent data diet may help but all hooks must be disabled.

DLL, SYS and EXE born on this date:

pcouffin.sys Tue Dec 05 09:39:30 2006
lm78nt.sys   Wed Dec 05 16:48:54 2001
i2cnt.sys    Wed Dec 05 16:59:21 2001
KS.SYS       Thu Dec 05 02:09:38 2002
nvlddmkm.sys Wed Dec 05 05:28:56 2007
swenum.sys   Thu Dec 05 02:10:07 2002
vtdisp.dll   Fri Dec 05 08:22:31 2003

Weaknesses: Overconfidence in code. Unrealistic data expectations. Unawareness of other modules.

Strengths: Confidence in code. Active computation.

Advice: Take a hard look at your debugging skills. Write down the list of your debugging tools and pay attention to what users say when it sounds realistic.

- Dmitry Vostokov @ SoftwareAstrology.com -

The post title is another definition of software astrology to help search engines to catch up with this new discipline. Since the division between software and hardware has blurred with the advent of virtualization and mass of embedded software the notion of hardware astrology (astrology of hardware) is similar and assemble date astrology corresponds to build date astrology. To generalise, any artifact has its corresponding astrology, the so called artifact astrology (astrology of artifacts) and creation date astrology.

- Dmitry Vostokov @ SoftwareAstrology.com -