Mathwiz

I can help a little with the root directory: in FAT32 it's just like any other directory or file - a linked list of clusters - except there's a pointer to the first cluster in the BPB. See offset 0x2C at https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FAT32_Extended_BIOS_Parameter_Block. FAT32 format utilities generally set this pointer to 2, the first cluster that actually exists on the volume, but strictly speaking, you're right; they don't have to. The volume label reference I made above is apparently wrong. There was some misleading discussion at reboot.pro that implied Cluster 1 exists: they kept referring to the "first" cluster, which I misread as meaning cluster 1, but actually cluster doesn't exist at all and the "first" cluster they were referring to is cluster 2. I'll edit my last post to fix that mistake. I think what threw me off was this sentence: (emphasis added), which I read as referring to an 8-sector "cluster 1" with only the volume name (and a whole lot of wasted space), but now I think it refers to cluster 2, with the volume name and the first several root directory entries. Anyway, the discussion was whether to put that "first" cluster at the end of a 1 MB page or the start of the next one. The thinking appeared to be: since it only holds the volume label and the first several root directory entries, it wouldn't change often and so shouldn't be placed in the same 1 MB page as the presumably more "dynamic" data clusters that followed it. But, since 1 MB alignment doesn't seem to matter (at least with the drive I tried) the whole discussion is moot AFAIAC.

Well, if there's only one FAT, then they just renamed "reserved sectors" to "FAT offset," but it means the same thing: the number of sectors between the start of the partition and the first/only FAT. Then they added the cluster heap offset so both the FAT and clusters could be properly aligned. In FAT32 the cluster heap offset doesn't exist, and the reserved sectors defaults to 32, which aligns the first FAT, but usually misaligns the second FAT and the clusters. By tweaking the reserved sectors, you can choose instead to align the second FAT, or the clusters, but usually at most one of the three. In theory you could achieve a triple alignment in FAT32 by choosing the partition size nicely, so that each FAT contained a multiple of 8, 16, etc. sectors. But short of that, experimentation with a "tweakable" FAT32 formatter like mkdosfs shows that aligning the clusters is by far the best choice. So I suspect there's little performance difference between exFAT filesystems (with both FAT and clusters aligned) and cluster-aligned FAT32 filesystems. Getting rid of the redundant second FAT may help exFAT a little, and the new bitmap probably speeds things up a little more, but they're not going to make a huge difference. I noticed that RMPrepUSB does this "hanging" alignment, aligning cluster 2 on a 1 MB boundary. (Thus, cluster 1, with the volume label, hangs off the start of the 1 MB page and is located at the end of the previous page, along with the tail end of the second FAT. That 1 MB page would be rarely updated as long as the drive doesn't get too full.) That may help with some older flash drives, but it didn't make any noticeable difference with mine compared to a simple cluster-aligned format done manually with mkdosfs. I think it's because newer flash drives have "smart" controllers that remap the 4K physical sectors to different 4K internal sectors, so 1 MB alignments don't really matter: with all the mapping, there's no way to predict which 4K sectors belong to the same 1 MB page. (Besides, unless the flash drive has been nearly filled up, most of the slow read-erase-rewrite operations are done by a garbage collection algorithm when the flash drive is idle, so they don't degrade performance as long as the drive has plenty of zeroed sectors for the garbage collector to work with.) So I doubt 1 MB alignments are worth the trouble, at least with newer flash drives. Edit: Ignore the struck-through references to "cluster 1" containing a volume label above. Cluster 1 does not actually exist on a FAT volume. The rest of the paragraph is OK, AFAIK. Still, with years of flash drives out there, with all their different technologies, there are probably a few somewhere that are helped by 1 MB alignment. So as usual, YMMV.

Strange they even bothered with this, since FAT32's "reserved sectors" effectively served the same purpose. It would've made more sense to add a way to align the Second FAT - and of course the cluster heap, which they did add and which is the most important thing to align by far. As for the overall value of exFAT, I haven't seen much. It does allow files >= 4GB, and it seems to be correctly aligned; aside from that, the only benefit I can find is to Microsoft, who patented exFAT so they could charge royalties for using it. But the net effect was only to ensure that manufacturers of cheap electronic devices often don't support exFAT, requiring FAT32 or NTFS instead; yet, most large USB flash drives now come formatted with exFAT, and have to be reformatted for use with said cheap electronics.

I did notice one cosmetic change with the latest Serpent 52 version: When enabling and using the hidden "Developer Edition" theme, the "Classic Theme Restorer" add-on can no longer "square" the browser tabs! The Tab Appearance selection is greyed out, and there are new messages on the Classic Theme Restorer Tabs settings (Page 1) that say "Tab appearance is controlled by the current theme." and "Third party theme detected! Some options do not work with third party themes!" Apparently CTR now considers the Developer Edition theme a "third party" theme, but didn't in earlier Serpent 52 versions. I don't know if that's a new bug or a fix for a bug (i.e., square tabs were never supposed to work with the Developer Edition theme, but did anyway until now). That's pretty minor in the grand scheme of things, but I did happen to like the Developer Edition theme with squared tabs. I guess you can't have everything though.

Interesting that a "native" Basilisk user agent works, given that a "native" FF 52.9 UA does not! It implies that Github has chosen to support Basilisk (at least, the official version), which is hopeful for the future. Once Github stops supporting 60.9, it may be best to move to the above (via a SSUAO) vs. trying to spoof FF 68. Why lie if telling the truth works?

I agree with @VistaLover; it seems to work OK for me. But I do use a user-agent override to Mozilla/5.0 (Windows NT 6.1; rv:60.9) Gecko/20100101 Firefox/60.9 ... which can be implemented either by a github.com-specific SSUAO, a general UAO, or by the compatibility prefs @VistaLover mentioned. Without a UAO of some sort, Github.com hasn't worked with FF 52 or Serpent for quite some time. (I agree that before long, we'll need to start spoofing FF 68 to have a chance, and even that may not work, depending on what new Javascript and/or CSS features Github decides to start using.) Also, if you have enabled either dom.webcomponents.enabled or dom.webcomponents.customelements.enabled, you need to disable them for Github.com to work with Serpent. (I have no idea why.) Everything seems to work fine with these disabled, although disabling them costs you a few points on html5test.com....

Getting back to the original topic, I was intrigued by the discussion of FAT32 alignment. So I ran a couple of tests with a 64GB SanDisk Ultra flash drive plugged into a USB 2.0 port. First, I formatted it with GUIFormat.exe, a popular freeware FAT32 disk format utility. Then I ran the CrystalDiskMark6 benchmark on it: Not very impressive, but I was only using a USB 2.0 port. Next, I reformatted with RMPrepUSB, which aligns the clusters with the flash drive's (presumed) 4K sectors, and ran another benchmark (with the same USB 2.0 port): OK, that's only about a 5-10% improvement in random read speed, but a 40% improvement in random write speed, and a whopping 50% improvement in sequential write speed! With this alignment, FAT32 actually out-benchmarks (slightly) NTFS! Pretty impressive and clearly worth doing if you need a FAT32-formatted flash drive or AF hard drive. Edit: Rezeroing the flash drive (easily done with "format i: /p:1" on Windows Vista or later; WinXP unfortunately does not recognize the /p switch) before formatting with RMPrepUSB produced a bit more improvement: ... although the read speeds dropped a bit from last time, so the previously noted improvement may have been a fluke. Of course, the improved write speeds probably won't last as the flash drive fills up again, but if you're formatting, you might as well start with the drive as fast as possible.

I realize uBlock Origin isn't an antivirus product, but it does support several anti-malware filters, so I think a post on uBO is justified in this thread: It's not just you; Mozilla long ago decided (capriciously, IMO) to remove all "legacy" (by which they mean pre-WebExtensions) add-ons from addon.mozilla.org, and won't sign any new "legacy" .xpi's. They weren't specifically picking on uBO, but that did leave FF stuck with WE version 1.17.4. (Our pal VistaLover detailed a way to get 1.18.4 working on FF 52 in another thread, but it required jumping through several hoops.) As for MCP, they've gone the opposite direction and removed all support for WebExtension add-ons from their products! This bifurcation is why JustOff supports a "legacy" version of uBO (leaving GorHill to focus on the WebEx version): the legacy version is for PaleMoon & Basilisk; the WE version for Firefox, Waterfox, etc. As you discovered, the unsigned legacy versions of uBO will work in FF 52 ESR, provided you turn off code-signing enforcement, so FF 52 ESR (and @roytam1's Serpent, which doesn't support code signing but didn't remove WE support) give you the choice of either a legacy or WE version of uBO. As I've posted elsewhere, I personally prefer the legacy version, since on these browsers, a few features are only available with that version. Regardless of which version you choose, uBO comes with four filter lists of malware domains. I enable all four in my browsers.

Despite the cautionary note I posted above, I still use Avast Free on my XP VM myself. However, my browser of choice is @roytam1's Serpent, which Avast doesn't appear to recognize, so it doesn't set the SSLKEYLOGFILE environment variable. That would normally leave me without browser protection. Luckily, Avast has another, more transparent way to monitor browser traffic: an add-on, a la uBlock Origin. But since Avast doesn't recognize Serpent, it didn't install its add-on into Serpent either! Luckily, that's easily fixed: Start Firefox 52 Go to about:profiles or about:support (either will work) Open your profile folder (you can now close Firefox) Navigate to the "extensions" subfolder Start Serpent Go to about:addons Find Avast's .xpi file in your Firefox profile's extensions folder from step 4, and drag it onto Serpent's about:addons page Accept the prompts, and Serpent will copy the Avast add-on into your Serpent profile and install it. The drawback to the add-on (vs. SSLKEYLOGFILE) is probably speed; Serpent seems to use quite a bit more CPU with the add-on installed - and of course, I'm sure Avast is monetizing the data it collects this way too. So not a perfect solution, but the security vs. privacy trade-off may be acceptable: just remember to disable the add-on if you need to do any truly "private" browsing. Note: When I installed Avast, it also installed a second add-on into Firefox: a "comparison shopping" add-on. I didn't feel I needed its help, and the privacy implications of that one were obvious, so I removed it, but I kept Avast's main add-on installed.

Works in Serpent 55 for me but not in New Moon 27. However I just tried a straight download of NM 27 without any additional filters/codecs/etc. so that may be why.

A word of caution about Avast: https://textslashplain.com/2019/08/11/spying-on-https/ TL;DR: Avast uses an obscure feature of Chrome and Firefox, an environment variable called SSLKEYLOGFILE, to spy on https: traffic. Using Process Explorer, I confirmed that it also does this on XP with Advanced Chrome and Firefox 52.9. Note: it does not appear to do this with New Moon or Serpent. It probably looks at the name of the .exe; basilisk.exe is probably too obscure, and it wouldn't surprise me if MCP removed this support from Palemoon.exe (and hence New Moon), since it could obviously be easily abused. This isn't necessarily a bad thing. The whole idea of AV software is to scan everything coming into your PC for malware, so scanning https: traffic could just be Avast doing its job. However, the article's postscript is cause for concern: But if you think about it, what else would you expect? Avast itself is free; they have to make money somehow....

I agree with @win32; they're probably sniffing the OS version in the user-agent string. Why they suddenly think that matters is beyond me. "Not supported" should merely mean, "if it doesn't work, don't call us;" it shouldn't mean "we're going to deliberately lock you out." In FF 52 or one of its derivatives, go to about:config and try setting general.useragent.override to Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.9) Gecko/20100101 Firefox/60.9 That will tell them you're using 32-bit Firefox, version 60.9, on 64-bit Windows 7.

I don't think it will work if you install it now. Google has moved up to Widevine version 1.4.10. I think version 1.4.8 will still work if you started using Netflix while it was supported, but they won't issue new licenses for version 1.4.8 any more.

Check out this plugin: https://firefox.maltekraus.de/extensions/add-to-search-bar

Not positive but I think those *xp.dll files were from @Dibya's Extended XP kernel, not from One-Core API. You might PM him, but I haven't seen him around lately.

Just FYI, here's the author's Web page: http://www.gerhard-schlager.at/en/projects/ctfmonremover/ Has info on what CTFMon does and whether you need it. Bottom line AIUI: you need CTFMon if you use Speech recognition Handwriting recognition Multiple keyboard layouts (e.g., for multiple languages) (Probably) Asian languages/character sets (Chinese, Japanese, Korean) If you use none of the above, might as well get rid of it! AIUI it should prevent the vulnerability, which is caused by the CTFMon.exe service not validating requests from clients. The CTFMon remover appears to replace CTFMon with a dummy program that doesn't actually handle client requests, so I'd think it can't be used to compromise your system like the "real" CTFMon can.

Unfortunately, for what Dave is doing - blocking a few Web sites in the hosts file, then bypassing those blocks for a particular browser - he needs a proxy server that's outside of his own PC, where it won't be affected by the hosts file. The Proxomitron might actually work, but it'd need to be on a separate system (although I suppose a VM might be made to work).

That's an elegant solution, @Dave-H! If FF accesses one of the three sites blocked in HOSTS, it instead goes to the proxy server you specified, which does its own DNS lookup (and presumably doesn't have those three sites blocked)! Anything else goes direct.

Well - as long as you never need to visit www.sky.com....

Probably a registry thing: more often than I'd like, 8.3 file/path names are stored in the registry, instead of the long file/path name in quotes. Correct; of course to add to the confusion, the Serpent .exe file is still named basilisk.exe (as the New Moon .exe file is named palemoon.exe). Even more confusing, clicking Help / About opens up a dialog entitled "About Serpent" but containing the text "Basilisk is community software released by the Pale Moon team and Mozilla developers."

That matches @VistaLover's results. (SSUAOs don't work in FF 52ESR unless you install some funky JavaScript to run at startup, or use an add-on like User Agent Switcher.) I wonder if @Dave-H's results are a kind of "runs once" situation? Dave, if you have the time, try creating another clean FF 52 profile (don't forget to turn off the proxy); see if Skype works once, then fails after you exit and restart the browser?

So, XP probably comes with it; 2000/98/ME probably get it with Office XP or later. I wonder what starts the process? Let me try starting an Office 2010 app and see what happens. Edit: Strange; Excel 2010, PowerPoint 2010, and Word 2010 don't seem to start CTFMon.exe. Maybe it only starts if you use one of those alternate input methods. If so, most of us are probably safe.

I suspect that a lot of Win 7 users are either upgrading to Win 10, switching to new Win 10 machines, or just abandoning Windows altogether. That's probably due to all the hype M$ is pushing as Win 7 EOS nears. Win 7 users abandoning Windows would push up the percentages of all other Windows versions. That may explain the apparent rise in Win XP users. To confirm whether the apparent rise in XP use is real, you'd need to see the raw numbers, not just percentages.

I'm probably in way over my head here, but.... CTFMon.exe doesn't seem to exist on either my Windows XP system (even though Office 2010 is installed) or my Windows 7 one (even though Office 2013 is installed). Edit: That was wrong; CTFMon.exe does exist. (I was fooled by SwiftSearch doing a case-sensitive sort on file names.) But it doesn't seem to be running as a process. Also, WinObj's "BaseNamedObjects" doesn't show any MSCTF* object names on either system. On Windows 7, there is a MsCtfMonitor task that is run at log-on. That task doesn't exist on XP. Concentrating on XP hereinafter, MSCTF.dll and MSCTFIME.ime do exist, in C:\Windows\System32\. Per Process Explorer, most processes seem to have MSCTFIME.ime loaded. I assume that's necessary to read keyboard input. At least one (Windows Live Mail) also has MSCTF.dll loaded. This makes me think that on at least some XP versions, CTF is implemented via simple .dll's vs. a client/server architecture; those versions may lack the vulnerabilities discovered by Google Project Zero. But the screen shot above implies that other XP versions do implement clients and a server, so they would be vulnerable. It would be interesting to know which XP versions include CTFMon.exe - perhaps MUI versions, and/or versions with Eastern (Chinese/Japanese/Korean) characters?

Another "about:" URL that might help is "about:support". Try this on your regular profile, and scroll down to "Important Modified Preferences." (Might be easier to print them out.) Compare with your "clean" profile (should be very few there) and see if any look like they might be related.