Software Astrology

The Day of Heap Expansion

Modules, products or systems built on December 15 compute big. Their expansive algorithms run free into wilderness. Few limitations exist for their code because it knows how OS works, but once they are on top of the list they don’t know how to keep staying there. December 15 components need to learn how to be satisfied at various resource levels and security restrictions. They do their best in computation when they care about other modules and do not interfere with other processes and threads. Products built on December 15 are liked by many customers. When they see them compute they feel good with their easy and open interfaces. December 15 modules from financial products are open to exploits and have vulnerabilities discovered with depends.exe. They are usually not concerned with such matters and can be sometimes computationally fatalistic, destined to loose data but can restart instead of hanging on exception. Thoroughly compute with all possible checks and then move to another step of their algorithm is the safest thing for them. Modules, products or systems built on December 15 may overestimate resources available for them and overlook deterioration symptoms so various external checks are recommended during their normal computational life span. Training is mandatory for their troubleshooters. Data restrictions are not necessary unless insisted by a security engineer. Running on open platforms is advised for December 15 systems.

DLL, SYS and EXE born on this date:

usrxcptn.dll Fri Dec 15 08:33:42 2006
PCIWNT.SYS   Tue Dec 15 19:46:09 1998
AegisP.sys   Thu Dec 15 10:31:20 2005
srv.sys      Mon Dec 15 21:42:35 2008


Weaknesses: Unrealistic expectations of available resources. Blind messaging.

Strengths: Well-linked modules. Cheerful sounds.

Advice: Don’t have a condescending attitude towards customers. Learn to deal with security constraints. Remember that heap can contract too.

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Software Exhibition

Modules, products or systems built on December 14 impress potential buyers at software exhibitions viewing their GUI but they rarely open their internals to show what they really are inside and what they are really computing. December 14 components have very complicated code and complex architecture. Many of their computations are bizarre. Their code is not ordinary, is self-aware and often confronts their parent processes and computational authorities. Sometimes it is not even possible to fit them into a predefined algorithm and even if it works initially later it causes enormous problems, for example, outraging a customer. However the good side to their challenging behaviour is that they are catalysts for software change. Modules, products or systems built on December 14 should be very careful with accidental violations. Their code might not be understood or they themselves might not understand their environment and that could result in their withdrawal from computation.

DLL, SYS and EXE born on this date:

ialmrnt5.dll Wed Dec 14 20:47:26 2005
ialmdnt5.dll Wed Dec 14 20:47:19 2005
ialmdev5.DLL Wed Dec 14 20:47:09 2005
ialmdd5.DLL  Wed Dec 14 20:54:40 2005
ialmnt5.sys  Wed Dec 14 20:55:38 2005
lknuhst.sys  Thu Dec 14 22:11:24 2006
lknuhub.sys  Thu Dec 14 22:11:15 2006
cygwin1.dll  Fri Dec 14 19:21:07 2007


Weaknesses: Excessive computation. Isolated code.

Strengths: Original and provocative UI. Daring computation.

Advice: Make your code fix suggestions quietly while carefully considering what you propose and what you say to another engineer. Choose the middle way in troubleshooting, debugging and code reviewing and be philosophical with your peers, internal and external customers.

- Dmitry Vostokov @ SoftwareAstrology.com -

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 -

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 -

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 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 -

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 -