Lack of any compression code was not the reason that Syncronys announced that the Windows 95 version of SoftRAM was defective, however. Rather, the code contains the severe problem of corrupting data structures when reentrancy occurs. If you have ever written a multithreaded program where several threads must access shared variables, then you have an idea of the nature of this problem. SoftRAM can be servicing a pagefile request with one thread, which issues a disk I/O request and then waits for its completion. While the first thread is waiting, Windows 95 can schedule another thread that also generates a pagefile request. This second request to SoftRAM's code, while one request is not completed, can cause SoftRAM to become confused about the state of its internal buffers. This can then lead to application data becoming scrambled in the SoftRAM cache: Pretty soon, applications start reporting errors, and not long after, a crash of the system results.
This problem is typically solved by incorporating locks into the code so that only one thread can access shared data structures at a time. Because this flaw in SoftRAM is exercised only when there are several threads running, it normally won't show up unless there are multiple applications executing and active at the same time. An easy way to trigger it is to start a compile, then during the compile, switch to a word processor and start a search operation. As long as enough memory is being used so that paging takes place, SoftRAM will cause data corruption. It is most likely the ease with which SoftRAM causes system crashes that forced Syncronys to issue its press release.
From looking at a disassembly, it also appears that SoftRAM was probably one of its author's first assembly-language programs. For example, the programmer seemed to lose track of the global variables that were allocated because fully one fifth of the SoftRAM global variables are written to, but never read. In addition, all the buffer-copy routines are terribly inefficient. Compare the copy routine, taken from the SoftRAM code, in Example 1(a), with its efficient counterpart, similar to what you'll find in any beginning assembly-language book, in Example 1(b).
(a)
mov edx, source mov eax, dest mov ecx, 4096/4 ; size of a page on x86 processors / 4 copyloop: mov ebx, [edx] ; read source double word (4 bytes) mov [eax], ebx ; write destination inc edx ; increment source pointer by 4 bytes inc edx inc edx inc edx inc eax ; increment destination pointer by 4 bytes inc eax inc eax inc eax loopd copyloop ; decrement ecx and loop until its zero ; (1024 times in this case)
(b)
mov esi, source mov edi, dest mov ecx, 4096/4 rep movsd ; buffer move operation - ; repeated 1024 times since operation ; moves 4 bytes at a time
Example 1: (a) Copy routine from SoftRAM 95 (Windows 95 version); (b) efficient copy routine.
The UI of the Windows 95 version of SoftRAM indicates that the software has created an amount of memory equal to the physical-memory size of the machine (SoftRAM), while preserving the original memory (HardRAM). Moreover, these same values are presented regardless of whether or not SoftRAM's system-level code is loaded, and whether or not SoftRAM's buffer allocation succeeds. SoftRAM does not compress memory, so the only effect it has is to increase paging of applications by reducing the memory available to them and in no case increases the total amount of available memory.
Inside SoftRAM 95: The Windows 3.1 Version
The internals of the Windows 3.1 version of SoftRAM are probably more interesting than the Windows 95 version because Syncronys still claims that it expands system resources, clears critical 1-MB bottlenecks, and doubles system memory using "patent-pending compression" achieving up to "5 compression ratios." The Windows 3.1 version has four components: the SR-START.EXE program that runs and then exits when Windows boots, a UI called SR95UI.EXE that displays the dials, and two drivers, PAGEFILE1.386 and PAGEFILE2.386, that replace the native Windows drivers that handle pagefile I/O.
Examining the UI, which displays the difference in resource usage as it would exist without SoftRAM versus actual resource usage, shows that the numbers presented by SoftRAM are indeed, in Syncronys's words, "a projection." To arrive at the figures, SoftRAM queries Windows for the resource usage, and then subtracts a small constant from the value it obtains. The original value is displayed as the SoftRAM resource number and the downward adjusted number as the resource usage that would occur without SoftRAM. When asked about this, Syncronys claimed that the numbers are a projection, and that what SoftRAM does can lead to slightly different results. Disassembly and analysis of the various SoftRAM components show that there is no code that deals with resource usage. In addition, experiments verify that SoftRAM does not affect resource availability.
The next claim is that SoftRAM clears critical 1-MB bottlenecks. This is one of the two places where SoftRAM actually does more than just project the numbers. Instead, SoftRAM uses code from a March 1995 PC Magazine utility, IBMFORT, that implements the memory-enhancement technique of fragmenting conventional memory, in an attempt to make Windows allocate it more effectively._The implementation is effective only under specific conditions, and at the time SoftRAM performs the fragmentation, Windows has already loaded device drivers and system DLLs that may have grabbed much of the precious 1-MB memory. Thus, only a fraction of the potential gains are realized.
Finally, the claim that SoftRAM performs RAM compression can be verified through analysis of the two drivers, SOFTRAM 1.386 and SOFTRAM 2.386. Disassembly and comparison with the corresponding sample drivers upon which they are based (included in Microsoft's DDK) leaves little differing code. What is left after the Microsoft code is removed is some initialization related to SoftRAM's system.ini settings, and a "mystery" routine of some 3000 bytes in length.
The mystery block of code is structured much as a compression algorithm might be structured, but the code is never executed. Static analysis of the drivers indicates that there are no control transfers made to the block of code from anywhere else in SoftRAM. Similarly, filling the block of code with assembly-language HALT instructions has no effect on SoftRAM's behavior, regardless of how much paging takes place. If control were ever to be transferred to this code, a HALT instruction would cause the machine to freeze.
The second thing that SoftRAM does to improve memory performance is permit a temporary paging file to grow to a size larger than Windows normally would allow. As described in the section on memory-enhancement techniques, this allows more memory to be allocated. However, this same effect can be accomplished by setting a parameter in system.ini. This has been SoftRAM's only line of defense against naysayers. Some benchmarks have shown that when SoftRAM is running, more applications can be loaded onto a system. If you see such a benchmark, note that in all cases a temporary swap file is in effect, and that the non-SoftRAM baseline system is crippled with an abnormally small paging file.
