loblolly986

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.

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...