Leaderboard

Many thanks for this new batch of UXP-based forks! I, for one, am not taking these builds of yours for granted, they do require dedication and considerable effort on your part (despite "upstream" constantly belittling your offerings as being just "hackjobs" ... ). Be that as it may, might I also kindly ask why the official UXP issue #1694, https://repo.palemoon.org/MoonchildProductions/UXP/issues/1694 and official Bk issue #31, https://repo.palemoon.org/moonchildproductions/basilisk/issues/31 were backed-out from your custom UXP branch? The thing is I was actually following closely the original report in the official forums, https://forum.palemoon.org/viewtopic.php?f=61&t=25728 and immediately thought that would be a favourable change to implement; after all, MCP would just be restoring what was already extant in Mozilla v51.0 and later broken by Mozilla devs in v52.0 of their platform... E.g. my (custom) date/time format configuration in my system is "dd/MM/yyyy HH:mm"; New Moon 28 respects that setting, because, while the platform code is a Mozilla v52.6 fork, the application code itself is a Firefox < 52.0 fork, so not affected... OTOH, latest Serpent 52.9.0 does not respect my custom date/time format OS configuration, because both app+platform code are Mozilla v52.6 forks and inherit the Mozilla caused breakage,,, As a result, Serpent displays date/time in a non-user-configurable US+12h clock format "M/d/yyyy, h:mm tt" ; me personally, I would have liked uniformity between NM28 and St52; what do other members here think? For the record, Mozilla, in later versions of their Firefox browser, tied date/time display to browser locale being used, but even then, the display format is fixed/non-configurable... With Serpent 52.9.0 (and now, sadly, NM28 too...) being only an en-US localised app, this is a moot point... This is just a thought, but perhaps issues UXP#1694 + Bk#31 could be implemented in our tree behind a user (i.e. about:config) pref? ... Kindest, warmest greetings!

? I'm typing in english. And my guess anyone dealing with extended kernel is familiar with this error message. If it was important, I would translate that.

512*1024=524288

Yep, first 512 bytes or first sector. The general idea is the following (even if for a number of reasons this actual message has not been clear). What we call "Partition ID's" are actually "Protective Partition ID's", not different from the concept of the 0xEE "Protective ID" used on GPT disks to avoid MBR-only enabled OS to access them. So what the 0x3C was intended to do was "let's mark this partition with a number that the OS knows nothing about". And I don't think that 7 has changed anything in the mechanism. In a nutshell DOS up to 6.22 recognized only ID's 0x1, 0x4, 0x5. 0x06 NT 4.00 only the 0x07 in addition to the above DOS 7,x/8.x and Win9x/ME added to them the 0x0b,0x0c,0x0e,0xf From 2K all of the above. More recently, when exFAT came out, its ID is still 0x07, definitely making clear that 0x07 does not mean "NTFS", but rather "DOS! Here be lions!". There is another ID (actually a non-ID) that you can try using which is 0x00. 0x00 essentially means for Windows "there is no partition entry in this slot" (but Linux can usually mount the partition in the slot just fine, this trick/quirk is used with grub4dos to directly map ISO images in the MBR). But if the issue revolves around something that uses not the MBR but *some other* mechanism/setting that is "sticky" the change to only the MBR partition ID will be ineffective . If you completely blank the first sector of a volume, on the other hand, for all Windows knows you are in the same situation as when you create a volume/partition in Disk Manager, you first create a partition and later you are asked to format it, if you choose to not format it, the partition/volume exists, it is defined in the MBR (and it is normally assigned a drive letter but its properties will show it as RAW and if you try to acces it you will be asked to format it). Now, what is "enough" to have it "recognized as RAW" (i.e. not-recognized) is another thing, the "magic bytes" are irrelevant, and as well the "NTFS " filesystem description, I believe the need is to blank the pointer to the $MFT, but at the end of the day it is easier/faster/better to just blank the whole sector. If you blank with 00's the whole first sector is surely enough and it is (relatively) safe as in NTFS there is a backup copy of that sector, last sector of the partition (outside the volume but inside the partition), so you can do everything with a couple dd commands (in Linux) or similar, the bootsector is generally "locked" on a booted windows NT system[1] so you need a suitable tool or a workaround, see also this: http://reboot.pro/topic/8200-grubinstexe-write-failed-vista-ntfs-bootsector/ Unfortunately I think that in your case you cannot use LockDismount (just in case): http://reboot.pro/topic/12413-lockdismount-v0300-update/ as it operates at \\.\PhysicalDrive (i.e. whole disk) level. jaclaz [1] meaning the stupid post-XP ones

I have a dell latitude from 2013 and I did not manage to find the wifi drivers when installing xp 64 but i did find ethernet and most of the others. Snappy driver I should have tried lol.

comctl32 seems to be fine, as the "open/save file" dialogs are fine, aside from the fact they are unskinned! So what has problems is uxtheme.dll. Here is some Dependency Walker output: The Vista version of SetDefaultDllDirectories is quite basic compared to the 7 version.

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.7.win32-git-20201212-6d0527a-uxp-4281fcc16-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.7.win64-git-20201212-6d0527a-uxp-4281fcc16-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.7.win32-git-20201212-6d0527a-uxp-4281fcc16-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.2a1.win32-git-20201212-31167a236-uxp-4281fcc16-xpmod.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.2a1.win64-git-20201212-31167a236-uxp-4281fcc16-xpmod.7z Official UXP changes since my last build: - Issue #1694 - Part 1: Use scriptabledateformat for the Cookie Accept dialog. (16a1ff22a) - Issue #1694 - Part 2: Use scriptabledateformat for Update History display. (6cb00e2cf) - Issue #1695 - Fix socket timeout logic. (6b45065f1) - Revert "Issue #1391 - Disable DOM Filesystem/dirpicker APIs by default." (4281fcc16) Official Basilisk changes since my last build: - Issue #31 - Part 1: Use nsIScriptableDateFormat in Page Info. (c7a029f) - Issue #31 - Part 2: Use nsIScriptableDateFormat in feeds. (8a74eeb) - Issue #31 - Part 3: Use nsIScriptableDateFormat in places library window. (5f97253) - Issue #31 - Part 4: Use nsIScriptableDateFormat in cookie preferences. (01c2847) - Issue #31 - Part 5: Update back-end branch pointer for toolkit changes. (6d0527a) Official Pale-Moon changes since my last build: - Back-end branch pointer update (unstable 2020-12-06) (31167a236) My changes since my last build: - Reverted Issue UXP#1694 and Basilisk#31 related changes

This happens to be my first post on the Windows XP forum, so any suggestions/additions/corrections from longtime XP users are most welcome. Antivirus: You have avast and AVG which still receive definition updates but which don't receive major app or feature updates. Firewall: Windows firewall should be enough in most cases but an additional firewall would be better, keeping in mind that XP does not have UAC . Browsers: I'm actually astonished that you have not heard of the great @roytam1's browsers! They are still supported and work well on XP, but I heard Chrome is being backported to XP. That would take some time. Until then, use roytam1's browsers. Sandboxes : I honestly don't know (lol) as I don't use any. However if sandboxie works fine, go for it. But if it doesn't, then a smart brain.exe would do. Malware scanner : Malwarebytes 3.5.1 still runs and receives definition updates. I use it instead of AV on my Vista system. In addition, update till 2019 through posready updates if you use XP x86, but if you use XP x64, then I won't be very worried as XP is used by less than 1% of worldwide PC's today, making it an unlikely target for hackers and malware.