somewan

Bringing the terrifying amount of bloatware that litter a standard installation of XP, onto almost any other system does indeed appear to be a daunting task. The question is whether you'd have to, or perhaps more importantly, *want* to. I think it would be far more desirable to find methods to accurately identify the essentials or "show stoppers" that keep XP-only apps from functioning adequately on alternative Win32 implementations. Tools that intercept operating system calls applications make seem to be the most plausible approach to that. Once such information is available, a reasonable next step might be special program loaders (or patching existing ones) that implement, emulate, fake, etc. the expected XP interfaces. Some of those concepts are demonstrated by the Linux DOSEMU and WINE environments, and by the *BSD emulation of Linux system calls. Also, the latter is an excellent example of how shared libraries (DLLs) of one operating system can be kept from interferring with native ones: when Linux apps ask for a particular file, FreeBSD first looks for it under the /usr/compat/linux directory tree, and only if that fails, the file is looked for in the regular tree.

It's true that portability sometimes results in complications and compromises. NT was designed for portability, and according to the designers' personal convictions rather than reality at the time - it is only recently that hardware has caught up with it. If I recall correctly, version 3.1 was the first to be distributed commercially rather as an internal Microsoft toy. It wasn't until 4.0 that it became widely known - perhaps because compromises were made in order to speed it up - large chunks of the GUI and Win32 subsystem were moved into the kernel or something along those lines. Regular Windows, on the other hand, evolved step by step, firmly grounded in the realities of the industry. The only thing making the first versions of it different from a DOS shell was the APIs it provided, making it a popular platform for third party applications. The powers of the 286 awakened dreams of Unix on the desktop, and even whole new operating systems written from scratch - most notably OS/2. The world wasn't ready for either of them. Windows, on the other hand, went on along the path of gradual refinements: In a short amount of time, it was hacked into running in protected mode, through the use of a DOS-extender, allowing it to tap the resources above the 640K and 1 MB barriers, but without tossing away the years of investments of money, time and effort of a whole industy into the PC ROM BIOS and DOS software. Windows as a 16-bit DOS-extended application, popularly known as "Standard Mode", because a tremendous success, only surpassed by DOS itself. In the late 1980s, the revolutionary 386, not only introducing 32-bit registers and a 32-bit address space with virtual memory features (paging / swapping) but addressing several compatiblity deficiencies of the 286, prepared the ground for the next step in Windows evolution. The project initially known as Windows/386 saw the birth of a modular 32-bit kernel, introducing features such as pre-emptive multitasking of DOS "virtual machines" (the Windows/GUI part remained 16-bit). In Windows 3.0, wisely retaining "Standard mode" for 286-compatibility, the new operating mode was introduced as "386 Enhanced mode". The 32-bit loadable kernel modules became known as VxDs (virtual device drivers), the most important of which was (and is) the VMM (virtual machine manager). In Windows 3.11, which dropped "Standard mode", a glimpse - albeit somewhat buggy and unimpressive - could be seen of a core foundation of the "Chicago" project: 32-bit file and disk access, implemented in the higher level VxDs IFSMGR (installable filesystem manager) and BLOCKDEV, in coordination with more specific modules such as VFAT. Under favourable conditions (such as the availability of the correct hardware-specific drivers) the new components were capable of reducing the amount of system calls passed to DOS and the BIOS to a small fraction. Initially planned for an earlier release as Windows 4.0, "Chicago" project was delayed and renamed to Windows 95. The enhancement of VFAT and IFSMGR to support long filenames was probably he feature that iimpressed non-technical users most with the exception of the new GUI and shell, but there's a lot more than meets the eye - such as the 150+ services added to the VMM. The most impressive improvement since Win95 must be the FAT32, which was added not only to the VxD layer but to DOS as well - certainly a greater step than DOS 5 to 6, for example. To further illustrate the flexibility of the kernel architecture, the addition of the peculiarly NT-like driver model known as "WDM" (Windows Driver Model) in Windows 98. Indeed, anyone who thinks the "weak link" or "dark corner" of Windows 9x is the kernel does, and/or anything having to do with DOS probably doesn't know what he/she is talking about. The debatable aspect of Windows 9x is actually the Win32 implementation. It does depend too much on 16-bit code - on KRNL386 and other parts of the Win16 code. At the time of Win95, it was an appropriate compromise, for reasons of compatibility as well as a safer alternative to attempting either a complete rewrite or a port from NT, but the Win32 layer ought to have been sorted out gradually over the years. If you're referring to the Win32 layer, you have a point, although the problem isn't that the Win32 layer itself is not "natively 32-bit" (because it is), but the extent to which it depends on Win16 components, resulting in limitation (best demonstrated by the RSRCMTR applet.)

Probably higher. The major difference between Win98SE and WinME is that they tried to sweep real mode DOS under the rug. Other than that, there are some DLL and system file upgrades. Yes, I'm sure we all remember the good old days when they wanted you to move from DOS to Win3.x and from 3.x to 95...

I was expecting OS/2.

Each new version is worse, just as with any other software from major corporations. It's certainly not unique to Symantec. Anyway, the DOS version of Norton Disk Doctor is compact and useful, and much faster than scandisk.

If you're running Windows 9x, 198 MB of RAM is likely to be more than enough. The problem you described sounds like the result of a software bug. Perhaps an applications that allocates more and more memory, but forgets to release it. Another possibility is "resource" exhaustion. Try running the Resource Meter - you'll find it in the Windows directory under the name RSRCMTR.EXE. As others have suggested, try checking your system for spyware and other junk. Also check for updates and patches to the operating system.

The first problem you mentioned - finding the needle (the suspect traffic) in the haystack of filesharing and web browsing traffic - is a tough one to crack, at least in a way that isn't horribly time-consuming. It's even worse if you consider that the traffic may be compressed or even encrypted. For that reason it's also impossible to be absolutely sure (even if monitoring the traffic from a different machine). But you may be overestimating the harware and knowledge requirements for setting up a second machine for traffic monitoring. Ten years ago, installing Linux, NetBSD, etc. was tricky at times, but these days it tends to be simple, and several of them come with "tcpdump" preinstalled. As for the hardware, people are throwing away everything you need, every day, so you could get it all for free, if you knew where to look. For example, one machine I've used for the task is a Pentium 60 MHz I got for free from my college. On the topic of paranoia and conspiracy theories... It is sometimes interesting to consider not what's likely, but what's *possible*. Any Win9x program has the power to install itself into the kernel, to modify any file and read/write any area of the memory. For XP or Linux, the same is true for programs executed with superuser (administrator/root) privileges. That means they can hide themselves from listings of processes and files. They could replace the boot sector or even flash themselves into the BIOS. Fortunately no virus has made use of the latter option, but in the DOS heydays replacing the boot sector was relatively common. There has also been at least one virus that destroyed the BIOS, but none that infected it (as far as I know).

Desktop popularity is mostly irrelevant to network security. Linux has been very popular as a network operating system from approximately the mid-90s. Due to that popularity, as well as the fact that it runs on the most popular architecture (PCs / x86), security holes have been discovered continuously and that situation remains. I've had several Linux machines broken into, always as a result of not upgrading the server software frequently enough. Meanwhile, no-one has broken into a NetBSD or FreeBSD server of mine. Interestingly, I've had only a single Win98 network intrusion, and none for Win95 (or DOS). I attribute that to the relative lack of network services. Viruses and trojans, on the other hand, is where desktop popularity comes in, but I think Linux will remain more secure even as it becomes more popular on the desktop. One reason for that is that Internet Explorer and Outlook are missing from Linux. Another reason is that using the root (the admin user) account for everything is less common and more often discouraged in the Linux/Unix world (needless to say a virus without admin rights can't do as much damage).

Actually, Win98SE has been exceptionally secure against network attacks in my experience, even unpatched. I ran two Win98SE workstations 24/7 for months, with public IP-addresses, without firewalls, and almost unpatched - in 2003 or -04, and there was only one incident. Due to a bug in MS/Windows networking, the password protection for shared network drives could be circumvented *if* at the same time there was an unpassworded shared printer. So a virus found its way in from the net, but I heard the sound of unexpected disk activity, halted the infection in its midst, and successfully reversed it. Then I patched both machines. They are still on-line as I write this, and there has been zero network intrusions since the one described above. Besides, time is on Win98's (and other old OSes) side. Almost no-one is focussing on finding security holes in them any more. Meanwhile, XP and to some extent, Linux and Win2K are hot (in the eyes of intruders). The system is faster without the IE integration, but there are some issues, with compatibility and the newer (IE-dependent) user interface does have certain improvements (eg. easier Start-Menu maintenance). Check your drive for errors (Norton Disk Doctor and the SCSI-BIOS built-in tools have worked for me, but the latter is unlikely to be available on a laptop), and perhaps try skipping setup's disk check by using the /is (I think) command line option.

But why use trash like Realtek, when you can get Intel, DEC, 3Com, and AMD cards, or clones based on the same chips? You can get a batch of quality NICs cheap on eBay.

No. 95B is the famous OSR/2 release (that Microsoft wouldn't sell unless you bought a piece of hardware with it) that added FAT32. Now *that* was an improvement. And what did 95C bring us? Nothing! Except the beginnings of the IE-integration plague and experimental USB... but who cares about cheap USB devices? It's a garbage interface that has no valid reason to exist, considering that 1) it's way too slow for fast devices, where SCSI or Firewire are better choices by far, and 2) it's not necessary for slow devices, such as mice and keyboards, where the good old and more backwards compatible serial and PS/2 interfaces are to be desired. Indeed, whatever the device, there's a better choice than USB. Almost. Win98 has considerable improvements in the memory management and disk caching architecture, and certain other "behind the scenes" aspects. While the user interface does have certain improvements, none of those features would have required contaminating the system with IE, which not only consumes disk space, but gave the GUI a feeling of slowness in comparison with Win95, although after a lot of tweaking and frustration, you can learn to live with it - perhaps because after a while, you forget how fast it ought to be.

Better printer support? OK, perhaps better than the 98-first ed. but otherwise unimpressive. Every time we attach the dot matrix printer (for infrequent, special purposes for which it is more appropriate than the network-attached PostScript-laser) and try to use it, 98SE says something about a time out, asking whether to "retry" or "cancel". Guess which you have to choose to get it to work. Even when only using the regular printer (the network laser), the print queue applet has a tendency to crash (fortunately not bringing the whole system down). As for USB, Windows insists on attempting to dig that up although it's disabled in the BIOS. The same goes for the IDE controller. On the other hand, I'm positively surprised at how easy getting the Firewire card to work, and the apparently flawless functioning of the flash (xD) memory card reader attached to it. It didn't even ask for drivers. Is there a particular reason (other than convenience), for doing an upgrade rather than a fresh install?

Assuming win9x, you can do it in autoexec.bat. Another idea for autoexec.bat might be commands to restore the ...\Windows\CurrentVersion\Run* registry keys to "approved" values and reporting suspect changes to various system files. Trojans, spyware and various resource-consuming applications like to add themselves in stategic locations in order to get reloaded on the next startup. For additional security, a write-protected boot diskette with a compatible version of DOS could be used in order to keep even boot sector viruses from being restarted. The possibilities are endless!

I can only imagine - unit creation is one of the few valuable feature my editor didn't have. Do you still have the offsets and details on that? I also didn't decipher the maps - that would have been pretty interesting too. I wish it had had the same effect on my brother (he played it almost as much as I did).

Yes, railways are important to have early, because they must either be built before a city is founded in the square, or never (and that's a shame). So if I recall correctly, that's what I used to do, as well as maxing the money, mostly leaving the rest to normal gameplay (and save+restore). I found that turning those annoying nuclear weapons into ground units and reducing their range was one of the more useful edits at some points in the game. (Although they would still occasionally roll into your city by rail...) Yes, I think that was one of the better-known cheats as I saw it mentioned elsewhere. Did you know you could build railroads on water? I didn't bother with anything else either.

I actually had a trojan on my system one or two weeks ago, for a few minutes. It demonstrated the danger of putting too much faith in programs such as virus scanners (or firewalls), letting them lull you into a false sense of security, when the single most important factors in this game are your brain and how you use it. As to the incident in question, I detected the trojan manually, simply by carrying on with normal activities - such as exploring and debugging the system. The alien entry in the list of processes was obvious, so I did a partial disassembly and a Google search to confirm the nature of the suspicious file. I'm not sure whether I did, in fact, scan the application/archive containing the trojan at first, but I did so after learning the truth, only to find that the latest version (and virus-signatures) of F-Prot (the free DOS version) said there were no suspicious files detected. Of couse, manual inspection is the proper procedure for any file that a virus scanner says is clean, if your intuition tells you it might not be, but in this case my expectations were wrong, and I presumed the files (various software analysis tools) distributed from the web site in question to be clean (as they usually are). The above also illustrates the importance of multiple lines of defence. Although a trojan, virus or network intruder has found its/his/her way in, you don't have an obligation to reward them with a long a pleasant stay. To help ensure they don't survive the next reboot, some the main things to consider are to keep track of file and registry changes, and to reverse any changes they made. The same methods can save you from software installations that make undesirable changes (in extreme cases, rendering the system unbootable, but more usually just cluttering things down), your own mistakes in tweaking the configuration, and much more. As to web sites designed to exploit browser security holes, it's not a great idea to rely on a background virus scanner either, for the same reasons. More important measures are selecting a safer browser, keeping it up to date (applying any available bugfixes, etc.) and configuring it properly (even more so if you must use IE). All in all, a background virus scanner can improve security, but only as long as you keep its limitations in mind and don't trust it enough to start running programs you would otherwise not. (And so on... people have written many large books on the topic of computer security!)

As MDGx and others have noted, the NT-series does not offer the degree of backwards compatibility that 9x does (better than Win3.x and under some conditions better than DOS itself). That goes not only for games, but many other DOS programs as well If I were ready to move on (for reasons of system stability, etc.), the destination would be Linux/BSD/Unix combined with an emulator such as VMware (for running DOS / Win9x / XP, etc in virtual machines). Admittedly, I'm a bit unusual, in the sense that I know the *nixes better than NT/XP, having had a foot in that world since the mid-90s. I certainly understand that most Win9x users would feel more at home with XP, but for me, it's merely an unfamiliar, incompatible, closed and costly operating system that offers few or no benefits.

Judging from the example script you posted, Rexx does look like a language designed for getting practical results, with features taken from at least C and BASIC - kind of like Perl, which is a mixture of at least the (Unix) Bourne shell, AWK, C, C++ and SED. By potent, you could mean a lot of things, but I suspect it may be a matter of taste... mostly whether or not you like VB and everything based on that - I personally don't, so I kind of hate to admit that I've used it enough to know that if you can endure it, you will usually get results (for example with Excel macros). All the viruses that has been written in it also demonstrate some of its power. So you're saying you wrote a cheat program for Civilzation too? That's quite a coincidence... mine was written in Turbo Pascal, in the early to mid-90s. It edits the money available, turn number, year, difficulty level, names of tribes, leaders, cities and units, the type of government, unit defence/attack strengths, tech. advances and maybe one or two other things. Of course, you could switch to a different tribe - including the barbarians (but you have to let them capture a city first, or the game will end immediately). I wrote cheat programs for some other DOS games as well, including "UFO: Enemy Unknown", "Indiana Jones and the Fate of Atlantis", "Red Baron", "Sim City", "Duke Nukem", "Cmdr. Keen" and "Railroad Tycoon". Alas, my editor for "Dune 2" was of limited usefulness because I never managed to decipher the file format well enough to calculate the money offset. Did you?

I hope you'll get around to it (learning assembly) - it should be pretty easy to someone as clever as you. I think that REXX thing looks more difficult, but I admit I'm biassed. Anyway, I think a suitable way to begin would be an instruction set reference in combination with Ralf Brown's Interrupt List (freely downloadable) and the DOS DEBUG program. Use debug's search command to look for INT 21 instructions (hex: CD 21), which is the "API" for DOS system calls - such as the version check - and then explore the surrounding code (Ralf Brown's list has all the details on system call numbers and parameters to them.). That's more or less how I fixed tree.com & comp.com (I think I took the latter from DOS 5, because it wasn't on the main DOS 6 floppies). Yes, and appearance is very important to Microsoft. Did you know they have the Win9x "clouds" boot logo embedded in IO.SYS, just in case LOGO.SYS isn't available? It gets tranferred to bootable floppies too (that's how I noticed it). I'm not familiar with DOS 8, because most of what I heard about WinME, including from Microsoft employees close to its development, was rather negative. But considering the major feature of WinMe was the feeble attempts to sweep DOS under the rug, it doesn't surprise me if they didn't spend any time on improving it. Certainly better than corrupting them (a different method to ensure that would be to calculate hashes or checksums).

In any case, having virus scanners running in the background tends to slow the system down. Unless you use Outlook and/or Internet Explorer to browse warez and porn sites, you would probably be better off with an on-demand scanner.

It seems that you're doing more extensive patching than necessary, or do any of the programs actually require it in order to function? I just refreshed my memory about what was needed for tree com (from DOS 6.22), and apparently, a two- byte patch in one location is sufficient: C:\exec> \dos6\tree.com Incorrect DOS version C:\exec>tree.com Directory PATH listing for Volume FAT16 10K Volume Serial Number is 3E2F-DAEF C:. +---WINBAT +---FDFORM18 +---GERMAN C:\exec>fc /b \dos6\tree.com tree.com Comparing files \dos6\TREE.COM and tree.com 00001500: 75 90 00001501: 03 90 C:\exec>debug \dos6\tree.com -u 1600 11FB:1600 7503 JNZ 1605 11FB:1602 F8 CLC C:\exec>debug tree.com -u 1600 11F9:1600 90 NOP 11F9:1601 90 NOP 11F9:1602 F8 CLC

Do you really have to change 6-7 locations? In my experience (and if I recall correctly), you only have to patch one byte - a conditional jump opcode - in order to get a program from an older DOS version to work with a newer one. At least that was true for tree.com.

The success list looks complete, but if you think it's a driver problem, try the "confirm" option from the boot menu and skip some drivers that look suspicious. Do you have a previous boot log to compare to? If you have a recent registry dump, try creating a new one ("regedit /e reg.txt" - works in DOS mode too) and compare. Look for recent changes in the windows directory and its system subdirectory..