loblolly986

For what it's worth, here's Microsoft's old Knowledge Base article describing how MS-DOS assigns drive letters: http://ftp.zx.net.nz/pub/archive/ftp.microsoft.com/MISC/KB/en-us/51/978.HTM. No mention of it looking at whether a partition is active, just that it assigns C: to the "primary MS-DOS partition on the first physical hard disk" (I'm not sure if this specifically means the first partition listed in the partition table or the first one on the drive in physical order). Also for what it's worth, I have a similar setup to what I suggested on my NT 4 system but with FreeDOS 1.2 installed in a FAT16 primary partition at the beginning of the drive, followed by an NTFS primary partition that is the active partition and contains NTLDR and an NT installation; and when booting FreeDOS using either a boot sector image for its partition (actually generated using FreeDOS's sys command) or a chain-loader image generated by BootPart, it assigns C: to its partition just as if it was the active partition and booted directly by the BIOS. I was assuming that MS-DOS would do the same, but on second thought making such assumptions can backfire. In any case, Wunderbar98's recommendation to make a backup of the drive first is a wise one, in case things get messed up somehow.

I'll admit that I'm straying from the conventional/Microsoft-prescribed way to multi-boot NT and DOS/9x in utilizing NTLDR's flexibility here; and if you do it this way and NTLDR and its associated files are located on an NTFS partition, you won't be able to access them from an OS without NTFS support should they somehow become corrupted—probably why putting them on a DOS-accessible FAT16 partition has been commonly suggested, like on the BootPart site. But you could always make an emergency boot floppy by formatting a floppy in NT (this is important) and copying NTLDR and associated files (NTDETECT.COM, boot.ini, any boot sector images you're using, and ntbootdd.sys if present) to the floppy, and use it to boot should the need arise. I do personally like the idea of being able to utilize NTFS's file permissions with the bootloader files, to help protect them when not logged in as an administrator. Having just tested BootPart a bit, this does seem to be a really good choice for a utility to make the approach I suggested easy; and its method of generating special "boot sector" images that chain-load partitions' actual boot sectors (as I've now confirmed is the case) is arguably better than simply saving copies of the boot sectors as the images, should the actual boot sectors need updating later which would otherwise require you to re-save them to the image files to keep those in sync. In the O.P.'s case, assuming that the second partition with NT is the "active" partition and contains NTLDR and associated files (and that installation of NT has been successfully completed), and the first FAT32 partition with Windows 95 is unmodified (i.e. boots correctly when set as "active"): when running NT, you would first run BootPart with no parameters to list all partitions and see which number corresponds to your 95 partition (likely 0 since it's the first partition). Then you would run it like this (using 0 as an example number): bootpart 0 C:\bootw95.bin "Windows 95" BootPart adds an entry to boot.ini for you, using the last parameter as the name to be displayed in the boot menu. (If you omit the last parameter, it just generates the image without updating boot.ini.) When you later choose the "Windows 95" option in the boot menu, NTLDR will load and execute bootw95.bin, which loads and executes the boot sector of your Windows 95 partition, which then proceeds to boot 95 as normal.

Couple of notes here: 1. You say that you have a "6 GB" partition with Windows 95, followed by a "4 GB" partition that you want to install NT on. This is potentially problematic, as NT 4's version of NTLDR, with a normal configuration (not using an NT storage miniport driver to access the partition), can only access the first ~7.8 GiB (~8.4 GB) of the hard drive; and if the NT kernel or other binaries loaded by NTLDR end up located past that point (e.g. after installing an update or new boot-time driver), booting will fail. Therefore, the partition on which NT 4 is installed should be contained entirely within the first 7.8 GiB/8.4 GB of the disk. (Note that even a 1 GB partition is large enough to contain NT 4 itself plus some programs.) Once NT 4 has booted, however, it can access the entire extent of the disk without issue provided that the storage driver in use supports it. 2. If it were me setting this up, I'd just let NT 4 take over as the primary/"active" OS partition, and manually add the Windows 95 FAT32 partition as an option in the NTLDR boot menu. This is done by placing an image file of the target partition's boot sector in the root directory of the boot partition with NTLDR/boot.ini, and adding a line such as C:\bootw95.bin="Windows 95" to boot.ini (if you name the boot sector image "bootsect.dos", you can omit specifying the filename and just write: C:\="Windows 95"). NTLDR simply loads the boot sector from the file and executes it, and the boot sector is then responsible for loading the OS or boot loader from its corresponding partition as normal. You'll need to procure a suitable boot sector image yourself, using a disk editor or other utility running on NT to save the first 512 bytes of the target partition to a file, or perhaps using Gilles Vollant's BootPart utility, which I haven't yet used myself but which seems to be a good choice (sounds like it doesn't save the actual boot sector of the target partition to a file, but generates a special boot sector image that chain-loads the boot sector from the actual partition). Following this, if you want to be able to access the FAT32 Windows 95 partition when running NT 4, install the Winternals/Sysinternals FAT32 driver.

The bugginess of XWin 1.6.2 is not OS-specific and includes messed-up rendering of xeyes with antialiasing enabled (also encountered in testing on Vista) and menus not lining up with the menu bar in FontForge. The source code changes I had to implement to make Cygwin 1.7.9 and XWin 1.11.4 work well on NT 4.0 are frankly pretty insignificant and the issues just reflect the developers' lack of adequate (or any) testing on NT 4 and not paying attention to/being familiar with what API features it supports, combined with—sadly—NT 4 usage evidently having all but evaporated among the community of Cygwin users who might have noticed and reported the issues in a timely manner, or raised objections when the intention to officially drop NT 4 support was brought up on the Cygwin mailing list. To be clear, I only got into using Cygwin on NT 4.0 last year. The real hero in all this is Peter Castro of the Cygwin Time Machine project, whose vast archive of snapshots of the Cygwin package repository has preserved the ability to install and use almost any version of Cygwin and its corresponding software from the present to as far back as 2002. The installation method I intend for my fixes will be for the user to have already installed the corresponding original packages using Cygwin Setup and extract my updated files over the originals. Old versions of Cygwin Setup can be acquired via the Wayback Machine or the Setup archive provided by the Cygwin Time Machine, though I also plan on putting up a custom build of Setup 2.752 with improved NT 4 compatibility.

1.7.9 was indeed the last release of the Cygwin DLL/runtime that supported NT 4.0. But it does have a handful of compatibility problems, such as the method used for allocating consoles invisibly being ineffective on NT 4.0 (resulting in one being stuck with useless console windows when running, e.g., X11 applications or mintty), bugs in the locale support (notice that locale -a hangs in an infinite loop), issues in a couple of the other runtime utilities (ldd has pre-XP compatibility needlessly broken), etc. NT 4.0 compatibility de-facto ended in the XWin X11 server much earlier, the last working version being 1.6.2-2 from when Cygwin 1.7 was still in the development/beta stage (note that the "setup-1.7.exe" referenced above is a special version needed to access those test releases and associated packages, not a regular setup.exe version from the 1.7.x era). This old XWin version does still work on Cygwin 1.7.9, but it's buggy compared to later versions such as 1.11.4-2 (the last version from the 1.7.9 period). It just so happens that I undertook producing new builds of Cygwin 1.7.9 and XWin 1.11.4-2 (and other things) with the problems fixed last summer, and just recently revisited this project to implement further fixes and tidy up the patches' code style a bit (I just discovered a way to implement the invisible console code that actually does allocate consoles invisibly on NT 4.0; the best I'd come up with previously had the consoles flashing onscreen after allocation, which still beat the heck out of being stuck with them but was still unsightly). I was thinking of putting these up somewhere and posting a thread here before too long, once I'm satisfied with how I have them. Suffice to say that 1.7.x is a definite advancement over 1.5.x for Windows NT systems, and at least with these fixes there'll be little to no good reason to settle for earlier versions... As for the "bloat" of that third-party ISO, in fairness, Cygwin had a sizable amount of software ported to it and available through its repository, and seeing that the ISO is intended as a portable solution that can run directly from a DVD, the author presumably included much of that software to increase the DVD's usefulness. My Cygwin 1.7.9 installation on my NT 4 machine has grown to roughly 1.5 GB (excluding all the stuff under /usr/src ), with a fair chunk of that no doubt due to the various packages I had to install to be able to build various things (and otherwise wouldn't have). If all you need is a basic bash shell environment and runtime dependencies for some applications, needless to say you could get away with much less.

Okay, I figured out what I was doing wrong... It occurred to me to see what would happen if I tried the "SSL" connection type... and lo and behold, it works like a charm. The default IMAP and SMTP port numbers even change to the correct ones for AOL when "SSL" is chosen. I had assumed that the "TLS" or "TLS, if available" options would be the correct choice since actual SSL is obsolete/insecure (and I have it disabled in RetroZilla) and the term is often used informally for secure connections in general that nowadays actually use TLS, but apparently those options actually correspond to the "STARTTLS" option in Thunderbird 52.9.1, while the "SSL" option is equivalent to "SSL/TLS". Neither AOL nor Spectrum accepts whatever authentication method RetroZilla presents with "Use secure authentication" checked. I anticipate having to generate an "app password" for AOL access starting in June, but it works nicely for now.

Yeah, I got notification emails about that. From looking at their help page about it, I get the impression that AOL will simply be requiring that clients support OAuth 2.0 (or "OAuth2") authentication for normal usage, and users of those that don't will need to generate special "app passwords" in their AOL account settings to use with such clients. Thunderbird 52.9.1 offers "OAuth2" as an "Authentication method" option in the server settings for one's accounts, so I suspect I'll be covered in that regard, though the "Normal password" option still works for now so this wouldn't seem to explain why I can't get RetroZilla to work as a client.

Took me long enough, but I've noticed that updating an installation of official RetroZilla 2.2 with Roytam1's build merely by extracting his package over it actually doesn't work properly. The problem is that while Roy's build, unlike the official 2.2 release, has many components statically linked into the EXE instead of in separate DLLs, it will still load and use unnecessary DLLs left over from the old version. Symptoms include the wrong Gecko build date in the user agent as seen on the "About" page ("Gecko/20190223" instead of "Gecko/20200201") and the additional TLS ciphers supported by Roy's build not actually being presented to web servers (as reported by, e.g., https://www.howsmyssl.com/). The fix is to delete all of the 2019-dated DLL and XPT files in the root installation folder and the "components" subfolder, except for gkgfx.dll in the root folder and gkwidget.dll in "components", and also delete the compreg.dat and xpti.dat files in the "components" folder to ensure that RetroZilla regenerates them to reflect the changes. The reason I advise keeping those two DLLs is due to a bug in Roy's build where it does not display a "hand" cursor when the cursor is over a link; Windows 95 and NT 4.0 do not support a "link select" cursor at the system level, so applications such as browsers must use their own, and Roy's build on its own fails to do this. Retaining those two DLLs from the official 2.2 release fixes this.

Has anyone successfully used RetroZilla's Mail & Newsgroups module as an email client? I just got around to trying it with my AOL and Spectrum email accounts, but I can't get it to work. I've entered the correct IMAP port numbers, etc., and tried different security settings ("TLS, if available" vs. "TLS", "Use secure authentication" checked and unchecked), but to no avail: with AOL, connecting soon results in an "Unable to connect to your IMAP server" dialog, while with Spectrum it sits there until the connection times out. I even tried AOL's POP3 server settings, but it tries connecting for a bit then just stops without any error message. In all cases it never gets to the point of prompting me for a password. I've tried both Roytam1's 2.2 build (with updated TLS support) and the official 2.2 release. My primary email client is still Thunderbird 52.9.1 on a Vista system, so I wouldn't think a requirement for some ultra-recent TLS cipher is the culprit. I don't really need to have this working, but it would be cool to use it to access my email on my NT 4.0 system...

@Wunderbar98 - Roy's package adds support for additional ciphers such as ChaCha20-Poly1305 and a SHA384-based cipher; it doesn't just enable a couple existing about:config settings by default. A couple screenshots of the ciphers listed in my updated installation's about:config are below. Roy's forked RetroZilla repo is here (different patches are stored as separate "branches"): https://github.com/roytam1/RetroZilla "Pull requests" page for rn10950's repo with requests by Roy that haven't yet been merged: https://github.com/rn10950/RetroZilla/pulls

The comparison is actually ~29.7 MiB vs. ~33.8 MiB looking at the uncompressed size of Roy's updated 7z package vs. the official 2.2 ZIP package, respectively. The official package includes some additional executables and DLLs compared to Roy's package. To at least some degree, this is evidently due to Roy's retrozilla.exe being statically linked with various libraries (~9 MiB in size) while the official 2.2 retrozilla.exe is dynamically linked (and is 156 KiB in size); note that Roy's package is missing most of the DLLs in the "components" folder. Static linking can carry less overall size overhead when the static libraries are only used by one executable, or when the linker omits parts of the libraries that aren't used by the program. Again, you'd have to ask Roy to be sure about the rest of the omissions. Some of them may have been unintentionally omitted, or they could simply be optional (but still may be worth having). I should clarify that when I suggested extracting Roy's package over an existing 2.2 installation, I did not mean replace the 2.2 installation. I meant extract it on top of the existing installation; any 2.2 files not included in Roy's package will still remain. I should also note that if one is concerned about messing up an existing RetroZilla installation, just make a backup copy of it (and perhaps your profile folder as well). I backed up my installation (and K-Meleon as well), but haven't yet had a need for the backup.

Regarding NVIDIA ForceWare drivers for NT 4.0: 77.56 is the last "Quadro certified" release, but the last of the "regular" releases is 77.72. The problem with the control panel software is that it is just another example of shoddy software from a Microsoft-kool-aid-drinking developer that expects you to have crap like IE installed just to use your video drivers. I highly recommend *not* bloating an NT 4 installation with invasive Microsoft frameworks like IE to cater to such crapware. In this case it only really needs the following (the first two should preferably be added before installing the drivers): - SHLWAPI.DLL. I extracted and use the version from IE 3.01, as it is much smaller than versions from IE 4 and later. - The "Version" entry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer should be set to an IE 5 or 6 (preferably 6) version number so that nView won't whine about the lack of IE. I use "6.0.9999.9999". - The nView Desktop Manager Setup Wizard didn't work until I installed the Visual C++ 6.0 runtime redistributable; probably it only needs the updated comctl32.dll provided by the included 50comupd.exe package, which can also be found separately. This part can be considered optional, as the Setup Wizard didn't seem to offer anything not configurable in the main settings pages. (Note: unless you are using a multi-monitor setup or need to temporarily enable them to use the LCD calibration screen, I would recommend keeping the nView Desktop Manager features disabled, as the hooks they install in running applications cause a considerable bump in memory usage.) With the above, the software seems to by and large work fine. I've tried versions 66.93, 71.84, and 77.72 and experimented with their multi-monitor support. On such setups, 77.72 has a bug where clicking the "Device Settings >>" button on the "nView Display Settings" property page caused the dialog to hang and max out the CPU instead of showing the menu. In 71.84 it works fine; as such, I would recommend 71.84 over 77.72 unless you have a specific need for something provided by 77.72. 71.84 and 77.72 do not show the Display Wizard after the first reboot following installation on a multi-monitor system; 66.93 does show the wizard but it does not work properly, with some settings not taking effect; the corresponding settings in the main property pages work fine. Perhaps I should have tried one or more of the "Quadro certified" releases, but they appeared to be target specifically at users of Quadro cards. Looking at NVIDIA's documentation, it seems they may have continued building NT 4 drivers after 77.72, but the functionality actually got worse (e.g. removal of PCI Express support). Note that while the NVIDIA Driver Helper Service (nvsvc32.exe) is not configured with "Allow service to interact with desktop" enabled, it actually circumvents this and maintains a hidden window on the desktop anyway - creating the same security problems (and triggering the same NT bug with the disappearing "Shutdown in Progress dialog) as any other interactive service that does this. Unless you require one of the specific features that depend on the service (it is supposedly involved with the hotkey feature, and I suspect application-specific profiles also), I recommend disabling it. I am currently satisfactorily using 71.84 with a GeForce 6800 PCI Express card. The OpenGL 3D screen savers included with NT look good with antialiasing enabled.

I haven't tried the RetroZilla package on its own myself but would think it would run fine. The chief advantage I know of to just extracting it over an existing 2.2 installation is that, assuming you used the 2.2 EXE installer, you'd still have the desktop and Start Menu shortcuts provided by the installer. You'd have to ask Roy about the differences in which files are included versus the official 2.2 release. It doesn't appear that rn10950 has made any changes to the GitHub source repository since releasing 2.2, so any differences would more or less be Roy's fixes and updates. I extracted the package over the 2.2 installation on my NT 4.0 system and haven't regretted it.* My understanding is the K-Meleon package is just an updated version of the official 1.5.4 7z package with components taken from RetroZilla, hence why it includes k-meleonW9x.exe (for NT 4 and 9x) in addition to k-meleon.exe (the official EXE installer only installs one or the other---renamed to k-meleon.exe if needed---depending on your OS). K-Meleon is a Gecko-based browser that uses native Win32 widgets for the "chrome" (dialogs and, sadly, scroll bars still use XUL apparently). * For NT 4 I'd suggest checking out Roy's build of QtWeb 3.8.4 available here (this is a portable program; move it to a suitable installation folder, (optionally) rename it to QtWeb.exe, and launch it. Note: it requires SHLWAPI.DLL extracted from IE 3 or newer). This browser provides considerably better rendering abilities over the current RetroZilla, and the TLS 1.2 cipher support provided by OpenSSL 1.0.1e was still enough to get quite far on the web last I checked. I'm hoping to make and release my own build in the near future that builds upon Roy's patches with additional improvements, hopefully including updating OpenSSL to the latest 1.1.1 release to provide support for TLS 1.3 and the latest ciphers. Maybe I'll be able to update the QtWebKit engine to a slightly newer version as well. (Not sure if it could be easily ported to 9x; maybe with the UnicoWS library?)

Regarding TLS in RetroZilla, note that Roytam1 released an unofficial build of RetroZilla with updated cipher support earlier this year: http://o.rths.ml/gpc/files1.rt/retrozilla-suite-tls12-20200131.7z You can extract the contents of this over an existing RetroZilla 2.2 installation to update it. This update appears to also make the about:config additions to manually enable certain ciphers unnecessary (those entries were no longer highlighted in bold after I installed the update). Roy also released a copy of K-Meleon 1.5.4 with the same updated cipher support; you can also extract this over an existing K-Meleon 1.5.4 installation (and replace k-meleon.exe with k-meleonW9x.exe): http://o.rths.ml/gpc/files1.rt/K-Meleon1.5.4en-US.tls12.7z

Don't have a 2000 system handy at this time, but on Vista one disables the "Use personalized menus" setting under the classic Start Menu customization settings.