Software Astrology

The Day of Software Craft

Modules, products or systems built on December 13 strive to compute every detail. They do it so precisely without departing from the big picture of their computational goals that there is a danger that they become stuck. Being a kind of computational psychologists or detectives they can go though interface facades and various superfluous defences. As a result components build on December 13 must respect privacy. Modules, products or systems built on December 13 are mostly crafted to help with the design of objects and less often to output persistent data. Unfortunately they can show erratic behaviour, component peculiarities and create difficulties in maintenance. Components build on December 13 should adapt themselves to be not so demanding and compromise for the harmony of computation. Being designed for design, products and subsystems built on December 13 can be overly concerned with self-checks and have strange built-in computational paths to deal with troubles. Good maintainer who is sceptical about the latest software engineering methodologies and tools is their best friend. Readjustments of their detail-driven event processing and moderate computation are encouraged.

DLL, SYS and EXE born on this date:

oleaut32.dll    Thu Dec 13 08:49:29 2007
srv.sys         Wed Dec 13 21:19:02 2000
taskhost.exe    Sat Dec 13 02:02:54 2008
uhcd.sys        Sat Dec 13 02:37:25 2003
usbehci.sys     Sat Dec 13 02:37:43 2003
kdcom.dll       Sat Dec 13 00:28:28 2008
hal.dll         Sat Dec 13 00:24:05 2008
mcupdate_GenuineIntel.dll Sat Dec 13 00:26:34 2008
PSHED.dll       Sat Dec 13 00:32:30 2008
CI.dll          Sat Dec 13 00:32:19 2008
cdd.dll         Sat Dec 13 00:19:06 2008
symmpi.sys      Mon Dec 13 21:03:14 2004
dump_symmpi.sys Mon Dec 13 15:03:14 2004
dump_arcsas.sys Wed Dec 13 11:54:58 2006
arcsas.sys      Wed Dec 13 11:54:58 2006
metsrv.dll      Tue Dec 13 05:10:41 2005

Weaknesses: Disturbing computation. Irritating UI.

Strengths: Attentive and perceptive UI. Thoughtful code.

Advice: Keep moving on when you finish your piece of code. Remember about good enough rule when feeling urge to polish code again and again.

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 3, 11
• Days of unfortunate computation: 7, 15, 26
• Days of good enough software behaviour: 5, 13, 23
• Fault-free days: 9, 18, 28

- Dmitry Vostokov @ SoftwareAstrology.com -

This is a short summary of behavioural and structural characteristics for modules, products and systems built during Winter time:

• Follow the large picture
• Tend to be dominant components ruling process and kernel space. Often initiate process space reformation
• Flexible data manipulation
• Interface acceptance
• Frequently the source of creativity

During Winter, software constructors live in expectation of coming Spring, less active, more conscious with internal aspects of their being and this channels into code construction and then into built modules, products and systems. Build activities, design of expressible and powerful UI and marketable features are diminished during this period. Some old components are even face possibility to enter the end of their life cycle.

Computational life cycles also have their winter periods, called χ-Winter (from χειμώνας, Greek) which might not coincide with the same physical periods due to the lag time of channeling. There can be one to many correspondence between one physical winter period and χ-Winter periods with some boundary overlapping due to the presence of Riemann surfaces (*) in computational space-time.

(*) Riemann surfaces are manifold representations of multivalued functions that explain side effects of many computational algorithms when doThis() function gives several unexpected results instead of the expected one.

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Assembly Language

Modules, products or systems built on December 12 emphasize the importance of hardware and interfacing with it is their main goal. They have a window into physical memory. Components built on December 12 are active and computationally healthy regardless of being thin or fat clients and give impression of being comfortable with hardware even when computing expressively. They let other components know about their presence. The voice quality of a module, a product or a system built on December 12 (*) is more important characteristic than what they are voicing. In order to grow, December 12 components must deeply explore hardware resources. However they shouldn’t be overly attached to ageing hardware. They must learn values of limits and correspondingly restrict their computational activities. Structuring their idle time and data consumption are paramount to their security. Here local data is better than remote with its network system excitations.

(*) The voice of EXE, DLL or SYS component can be generated with the help of Dump2Wave tool.

DLL, SYS and EXE born on this date:

WMEncEng.dll Thu Dec 12 13:09:17 2002
CHDART64.sys Tue Dec 12 20:07:25 2006
volmgr.sys   Tue Dec 12 22:29:12 2006
msisadrv.sys Tue Dec 12 21:42:18 2006
pci.sys      Tue Dec 12 21:42:27 2006
swenum.sys   Tue Dec 12 22:28:16 2006
mssmbios.sys Tue Dec 12 21:42:24 2006
termdd.sys   Tue Dec 12 22:53:43 2006
COMMONFX.SYS Wed Dec 12 02:47:17 2007
CTEDSPSY.SYS Wed Dec 12 02:47:15 2007
CTEDSPIO.SYS Wed Dec 12 02:47:12 2007
CTEDSPFX.SYS Wed Dec 12 02:46:05 2007
ctprxy2k.sys Wed Dec 12 02:45:54 2007
ctaud2k.sys  Wed Dec 12 02:45:52 2007
ha10kx2k.sys Wed Dec 12 02:45:39 2007
ctoss2k.sys  Wed Dec 12 02:45:38 2007
ctsfm2k.sys  Wed Dec 12 02:45:34 2007
emupia2k.sys Wed Dec 12 02:45:33 2007

Weaknesses: Expensive, stuck in development.

Strengths: Hardware expressive, computationally expansive.

Advice: Don’t spend too much time with hardware. Be realistic about software and not overly attached to its objects.

- Dmitry Vostokov @ SoftwareAstrology.com -

Interesting observation that reinforces my belief in astrology of software:

What’s in your name? A Debugging Perspective

- Dmitry Vostokov @ SoftwareAstrology.com -

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 -