This is the kind of work I used to do every day in the Windows Sustained Engineering team at Microsoft, this person would make an excellent kernel engineer
Funnily, one of the comments on the answer did reference Chen's ONT:
> I see your NOP (90h), and raise you an explicit DS prefix (3Eh). It's all about the style points! :-) Any instruction with a memory operand can have a segment prefix. In this case, the DS prefix is implicit/implied, but it can be explicitly specified without changing the meaning of the instruction. Both ways work to pad the extra leftover byte of space, but the explicit DS prefix does not change the instruction's execution speed, whereas the NOP actually takes 1 cycle of time to execute (plus possible decoding). – Cody Gray
> The Windows NT 3.1 CD comes with the full set of debugging symbols
Props to Microsoft for doing this. Also, for providing symbol servers which allow a debugger to pull down symbols remotely, over the network.
One part of my job is helping developers debug mobile application crashes on both iOS and Android. Fortunately, Apple makes iOS debugging symbols available (not as conveniently as they could, but you can get them). This at least allows for properly symbolized backtraces.
Android however is the bane of my mobile application debugging existence. There's no hope of getting debugging systems for any version of Android not built by Google. You can kinda sorta get something useful for Nexus devices by pulling down the Nexus images and extracting public symbols from the libraries on those images. Still not as good a full debugging symbols, but better than nothing.
Sadly, Google doesn't make available the debugging symbols for WebView, which is where I see a lot of crashes. Not being able to symbolize the stack traces makes it almost impossible to diagnose the cause.
[Background: the question author (Michael) answered their own question]
Why is this not the accepted answer - waiting for a better one? – piiperi
@piiperi To me, it feels a bit arrogant to accept a self-answered questions before a couple of days have passed. Granted, on the other hand, in the case of this question, a different answer is quite unlikely. – Michael Karcher
A different answer is quite unlikely, but improvements are always possible :). Case in point, another gem from the comments:
I see your NOP (90h), and raise you an explicit DS prefix (3Eh). It's all about the style points! :-) Any instruction with a memory operand can have a segment prefix. In this case, the DS prefix is implicit/implied, but it can be explicitly specified without changing the meaning of the instruction. Both ways work to pad the extra leftover byte of space, but the explicit DS prefix does not change the instruction's execution speed, whereas the NOP actually takes 1 cycle of time to execute (plus possible decoding). – Cody Gray
> For improved performance, I maxed out the RAM at 128MB and swapped the socketed Intel 486DX-33 by an AMD enhanced 486DX4-SV8B (write-back cache and SMM) in a voltage adapter socket.
128 MB in a 486 is insane. 16 MB was a lot in that era. I remember upgrading my Pentium II (!!!) from 64 MB to 128 MB, in order to not suffer death by loading screen in Diablo II.
Post author here: Well, this is not your run-of-the-mill Desktop Computer, but it is an Intel-based system designed as Server. Servers tend to have (a lot of) more RAM than desktop systems, so I think 128MB is not that much out-of-place. I got an acceptable price on the required 72-pin non-EDO parity SIMMs, so why not max it out?
The hard drive in that machine is still the original COMPAQ OEM version of the Fujitsu M2622F SCSI drive. In 1993, that was the entry base option for storage in that server, and I dare to say that it is typical Compaq tradition that the base level disk drive is just barely aedequate for the system. While that Fujitsu drive was a fair performer in 1991 when it was designed, in 1993 it wasn't that cool anymore. Granted, there were better options available, you could even get an EISA SCSI raid controller for that system.
And as a final remark: Diablo II was the reason my brother upgraded his K6-2 machine from 32MB to 128MB.
I believe that at the time it would have required 16Mbit DRAM, which was still not common in 1994 outside of workstations and servers. (most of them at the time came in larger "400 mil" packages, as opposed to the "300 mil" packages that would have been common by 1995, and as a side note this is part of why 16MB 30-pin SIMMs was never common as the larger package would make them very tall)
I then had a Pentium 166MMX with 64MB (16MB was what was usually offered) which I recently upgraded to 80MB with a couple of sticks I found in an old box.
One of my favorite things about the NT3.1 design was that the subsystems, such as Win32, were completely abstracted from the base system and even communicated with the kernel by means of message passing. This was changed later (for better efficiency).
