loblolly986

That feature is also in the Windows 95 Power Toys pack, installable via DOSHERE.INF. http://web.archive.org/web/20120206031214/http://download.microsoft.com/download/5/2/e/52e8fd68-e528-4995-abe2-5644583536e1/W95powertoy.exe I don't recommend everything in the Power Toys pack for NT as some things are incompatible, and some things are just too buggy or have superior alternatives available. But Send To X—recommended. Tweak UI 1.1 (where disabling 8.3 filename case adjustment actually works)—recommended, though I hear some features are incompatible with IE 4 or later if you have that installed. The "Target" shell extension is also helpful—it adds a "Target" submenu to shortcut context menus, with an "Open Container" item that opens the folder containing the target in a regular window (from which you can then right-click the window icon and choose "Explore" to open a proper file browser). There's also an INF for an "Explore From Here" action for folders—it opens an Explorer window with that folder as the "root" of the directory tree. Instead of "Deskmenu", I recommend SnadBoy's TopDesk 3.0b (same idea—makes your desktop icons accessible via a tray icon—but a much more thorough and polished implementation). And instead of "CabView", I'd just associate .cab archives with 7-Zip via its file association options. An NT version of QuickRes is included in the Windows NT 4.0 Resource Kits, but note that some graphics drivers such as NVidia's already include equivalent tray icon functionality. I find NT's own cmd.exe to be pretty satisfactory, but as far as alternative shells I'll mention "Yori" by Malcolm Smith; it's designed to work on all NT versions. Don't forget to tweak the console window defaults (via the control panel icon) to be more optimal. You can set the screen buffer size to 300 rows or so, as was eventually made the default in Windows, to have room to scroll back on console output. You can also choose a different font. The Ultimate Oldschool PC Font Pack is a good source for them. I don't recommend bogging down you system by installing the whole pack; just install a handful that you're particularly interested in. The "PxPlus" fonts support an expanded set of characters over the standard codepage 437 character set. I suggest "PxPlus IBM VGA 8x14" or "PxPlus IBM VGA 9x16", the former to save space if you are using a lower screen resolution such as 1024x768. NT 4.0's console control panel will detect them as compatible and list them automatically after you get them installed; no need to jump through any registry hoops to use them. They look much nicer than the default "Terminal" font.

I'm sorry for not following up on this before now. Attached is a REG file for the "Explore in New Window" action, and below is its content: REGEDIT4 [HKEY_CLASSES_ROOT\Folder\shell\explorenew] @="Explore in New &Window" [HKEY_CLASSES_ROOT\Folder\shell\explorenew\command] @="Explorer.exe /e,/n,/idlist,%I,%L" ExplNewW.reg

The trick to the early, non-IE integrated, incarnation of Windows Explorer supplied in NT 4.0 (and Windows 95) is that the "Open" and "Explore" actions for folders open distinctly different types of folder window. The latter is what opens a "full-fledged" file manager window with "Exploring" in the title. It has a directory tree sidebar, the toolbar visibility and selected folder view format are remembered and applied across all folders and future Explorer windows, and double clicking folders always opens them in the same Explorer window. This is what you want: This is light on system resources, pretty easy to use, and gets the job done without the bloat and security flaws of the later Internet Explorer based shells. I'm used to just right-clicking on My Computer or a folder and choosing "Explore" when working on NT, but it's possible to configure "Explore" to be the default action when double-clicking if that's what you want. The "Windows NT Explorer" shortcut in the Start Menu's Programs menu is another way to open one of these windows. It's also possible to add a custom "Explore in New Window" action to the Folder file type to enable easily opening a folder in a separate Explorer window from another such window (if interested, I can supply a REG file). And, of course, one can enhance its functionality with shell extensions—the "Send to X" extension in the Windows 95 Power Toys pack, with the "Any Folder..." option it adds in the "Send To" menu, is one I especially recommend and am always using. The "Open" action opens a different type of folder window that saves its view settings on a per-folder basis and, by default, is "bare bones" in layout, opens other folders in new windows, and uses large icons. (It also provides access to the folder's context menu by right-clicking its window icon.) It's perfect for things like the Control Panel and for viewing folders on the desktop that one has organized shortcuts into, but for general file-managing purposes the Explorer windows are where it's at, in my opinion. One improvement the NT 4.0 version of Explorer has over the 95 version, besides the additional "Attributes" column in the Details view, is the ability to disable the "prettifying"/case-adjustment of uppercase "8.3"/DOS-style filenames. Tweak UI 1.1 from the Windows 95 Power Toys pack provides the ability to change this setting. Tweak UI 1.33 is supposed to let you do it as well, but my experience is that it's buggy in this regard and doesn't actually apply the change to the registry.

Just FYI: not sure off-hand if this works with the Supermium installer (I won't be trying this browser until/unless I can have it fully "ungoogled"/spyware-free), but if it's like the normal [ungoogled-]Chromium installer, running it with the --system-level command-line option will install the browser under Program Files.

Thanks for checking. Here's a screenshot of the popup I was getting (it contained more content accessible with the mouse wheel, but a "cached" link/button was nowhere to be found). Turns out the problem was cookie cruft: prompted by your post, I tried deleting all cookies containing "google", and now I'm also getting the "beta" popup with the "cached" button (which is what I was getting in Mypal 68). Good points. No disagreement from me. I may end up changing my mind and switching back to the "legacy" interface myself, though the features/functionality offered by the "modern" one are useful at times. Though I guess I could pull up Mypal and get to it there on the occasions I needed it... I need to work harder at minimizing my use of Google (with its user tracking/data mining) anyway. DuckDuckGo is okay, but its results sometimes don't catch things Google does, and its regular interface doesn't split the results into separate pages either (though like Google, it does at least currently allow one to switch off the dreadful automatic loading/"infinite scroll"); its "HTML" and "Lite" interfaces do, but are also stripped-down in functionality. One search engine I keep forgetting to use is Startpage, which delivers Google results (that they pay Google to use) without the tracking; I just tried it, and am pleased to report it still uses traditional pagination.

Thanks for this tip for New Moon 28. Although pleasingly lighter-weight, I finally got tired of the "legacy" Google Search interface's limited functionality compared to the regular version (which, as I recall, used to be what N.M. 28 in "Native" user-agent mode was served a while back). I just added this user-agent override, and it still works like a charm. (Though as of right now, I'm still not seeing any link to the "cached" version of a result in its "about this result" popup, while Mypal 68 gets a different popup that does have such a link.) Any particular reason such an override isn't part of the default configuration?

JSmooth comes to mind as an old, free Java EXE wrapper that I used many years ago on XP.

Just tried postimages.org in New Moon 28 (latest build), including uploading an image as a test, and it worked fine for me as it always has. I should note that (a) I did so as an unregistered user and (b) I use uBlock Origin.

For what it's worth, this particular bug also occurs with Thunderbird 52.9.1 (at least on Vista with the "classic" style).

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.