Leaderboard

So yesterday LibreOffice launched v25.8, which will be released in August this year. As anticipated, this version will drop support for Windows 7 and 8.1. Nonetheless, I was curious if it will work on these OS. On Windows 7 it does not work, since Windows 7 doesn't support Python 3.9+. You will receive the error "api-ms-win-core-path-l1-1-0.dll" is missing. I used VxKex, which fixes that error, however another dependency from Windows 8+ is missing On Windows 8.1, Alpha 1 works without any errors. I copied the folder from another Windows 10 install and I could launch Writer, Calc, Office... Here, Windows 8.1 definitely benefits from higher Python support and newer APIs

Tutorial: Building and Patching csmwrapper.efi to Add INT 13h Disk Services This guide walks you through setting up an EDK II build environment, compiling the original csmwrapper.efi source, and integrating an INT 13h hook so that SeaBIOS can recognize SATA, USB, and NVMe boot devices. —-------------------------------------- 1. Prerequisites • Host OS: Linux (Ubuntu 20.04 or later) or WSL • Packages: git, build-essential (GCC, Make), uuid-dev, iasl, python3, python3-distutils, bzip2, libssl-dev, libncurses5-dev, nasm (optional) On Ubuntu: sudo apt update sudo apt install git build-essential uuid-dev iasl python3 python3-distutils bzip2 libssl-dev libncurses5-dev nasm —-------------------------------------- 2. Obtain EDK II Base Clone the repo: git clone https://github.com/tianocore/edk2.git cd edk2 git checkout edk2-stable202203 Initialize build environment: source edksetup.sh Verify environment: echo $EDK_TOOLS_PATH echo $CONF_PATH —-------------------------------------- 3. Prepare the csmwrapper Sources Copy csmwrap-1.1.0 into edk2/CSMWrap Ensure it contains: CsmWrapper.inf Platform .dsc including this package Source files (.c, .h, optional .asm) Build scripts/Makefile Directory structure example: edk2/ └── CSMWrap/ ├── CsmWrapper.inf ├── Platform.dsc ├── x86thunk.c └── ... —-------------------------------------- 4. Configure INF and DSC – In CsmWrapper.inf: • Add x86thunk.c to Sources • Add dependencies under LibraryClasses: UefiDriverEntryPoint UefiBootServicesTableLib DebugLib CpuIoLib BaseLib LegacyBiosPlatformLib LegacyBiosThunkLib – In your Platform .dsc under Components: COMPONENTS = CSMWrap/CsmWrapper.inf —-------------------------------------- 5. Patch x86thunk.c to Hook INT 13h In Legacy16Init(...), after the null-handler registration loop, insert: // Hook INT 13h for disk services Status = Private->Cpu->RegisterInterruptHandler( Private->Cpu, 0x13, LegacyBiosDiskInterruptHandler ); if (EFI_ERROR(Status) && Status != EFI_ALREADY_STARTED) { return Status; } At the top of the file, declare: VOID EFIAPI LegacyBiosDiskInterruptHandler( IN EFI_EXCEPTION_TYPE InterruptType, IN EFI_SYSTEM_CONTEXT SystemContext ); And add a stub to prevent build errors: VOID EFIAPI LegacyBiosDiskInterruptHandler( IN EFI_EXCEPTION_TYPE InterruptType, IN EFI_SYSTEM_CONTEXT SystemContext ) { // TODO: implement INT 13h dispatch return; } —-------------------------------------- 6. Implement the Disk Handler Inside LegacyBiosDiskInterruptHandler: Save registers from SystemContext.SystemContextX86 Extract AH (RegEax >> 8) to determine function If AH < 0x41, call legacy I/O via Block I/O thunk If 0x41 ≤ AH ≤ 0x48, set up Disk Parameter Packet (DPP) at ES:SI and handle extended calls Set CF/ZF and registers in SystemContext per BIOS spec Tip: Consult EDK II’s LegacyBiosDxe/Int13Handler for reference. —-------------------------------------- 7. Build with EDK II From edk2 root: source edksetup.sh build -a IA32 -p CSMWrap/Platform.dsc -b DEBUG Result: csmwrapper.efi in Build/DEBUG_IA32/CSMWrap/Application/. —-------------------------------------- 8. Test in SeaBIOS Copy the new csmwrapper.efi to your firmware’s CSM path. Boot and verify that SeaBIOS now lists SATA/USB/NVMe devices. Use DEBUG((DEBUG_INFO, ...)) in your handler for logging. —-------------------------------------- 9. Next Steps • Complete full dispatch in the handler (reset, status, etc.) • Validate large-drive support via functions 0x48 (get parameters) and 0x42 (extended read) • Consider upstreaming your patch to the CSM wrapper project

I just pray a new company will overtake Windows at this point. There's nothing good or stable about Windows. Everything good about Windows is stuck on older versions. Whatever happened to efficiency? Windows 10 and later is nothing more than a trainwreck covered in a bit of glitter. There is literally nothing new or innovative. You can get all the same tasks done even on Windows 98.

1. No Real-Mode Environment BIOS world: 16-bit real mode, flat 0–1 MiB memory, its own stack, segment registers, and interrupt tables (IVT/GDT). UEFI-only world: 32/64-bit protected/long mode, full paging, no real-mode segments, no BIOS stack at 0x0000–0xFFFF. Result: The little RETF instructions in CSMWrap have nowhere valid to return into or switch from—so they never execute. 2. No Legacy BIOS ROM Code BIOS ROM: Carries the actual INT 13h disk routines below 1 MiB. That’s the code CD 13 jumps into to spin the platter and read sectors. UEFI-only firmware: Contains no legacy ROM image under 1 MiB. There is simply no INT 13h handler to call. Result: Even if you could perform CD 13, the CPU would vector to garbage and immediately triple-fault or hang. 3. No IVT Vector Patching CSM-enabled systems: Before loading CSMWrapx64.efi, the firmware patches the IVT at 0x0000:0098/009A so that INT 13h points at the tiny BIOS stub. UEFI-only systems: There is no IVT to patch, and the region at 0x0000–0x03FF isn’t even mapped for interrupts. Result: INT 13h invocation has absolutely nothing registered there—no handler, no fallback. 4. No Mode-Switch Plumbing With CSM: CSM code sets up CR0, paging, GDT entries, and stack pointers so you can do a far switch into real mode and back. Without CSM: The CPU never drops out of 64-bit mode. There’s no mechanism to clear CR0.PE or reload segment descriptors. Result: You can’t magically execute 16-bit BIOS code in a 64-bit world without this plumbing—so the entire stub logic is inert. 5. UEFI’s Native Disk Interface Differs Completely Legacy BIOS: Uses registers and INT 13h for disk I/O. UEFI: Uses EFI_BLOCK_IO_PROTOCOL functions (e.g., ReadBlocks()) in 64-bit code—no interrupts, no registers, no CHS. Result: Even if CSMWrap exists, XP SP3’s INT 13h calls won’t be rerouted to Block I/O because nothing is listening for them. Bottom Line for “Dummies” CSMWrapx64.efi alone is just a collection of 16-bit byte sequences (RETF, INT 13h, RETF). Without CSM, there is no behind-the-scenes BIOS “workshop” to host them: No real-mode memory or stack No BIOS ROM code under 1 MiB No interrupt vectors to catch INT 13h No mode-switch mechanism Therefore, XP SP3’s disk-read calls (INT 13h) simply go nowhere, and the installer cannot load any sectors—so the boot stalls and fails Dietmar

Files expire after 120 days

Re: Missing INT 13h in csmwrapper.efi When you inspect your x86thunk.c, you’ll find this loop around line 312: for (Vector = 0x20, Count = 0; Vector < 0x100; Vector++) { Status = Private->Cpu->RegisterInterruptHandler( Private->Cpu, Vector, LegacyBiosNullInterruptHandler ); … } That only hooks vectors 0x20–0xFF. INT 13h is vector 0x13 (decimal 19), so it never gets handled. As a result, all BIOS disk calls (legacy AH<0x41 and extended AH = 0x41–0x48) fall through to the null handler—hence “No boot device found.” Patch to hook INT 13h Insert this immediately after the null-handler loop in Legacy16Init(): // … existing null-handler registration for vectors 0x20–0xFF … // Hook INT 13h so BIOS disk services reach our real-mode thunk Status = Private->Cpu->RegisterInterruptHandler( Private->Cpu, 0x13, // BIOS Disk Services LegacyBiosDiskInterruptHandler // implement this! ); ASSERT_EFI_ERROR_OR(Status, EFI_ALREADY_STARTED); Next steps Declare the handler prototype near the top of x86thunk.c: VOID EFIAPI LegacyBiosDiskInterruptHandler( IN EFI_EXCEPTION_TYPE InterruptType, IN EFI_SYSTEM_CONTEXT SystemContext ); Add a stub implementation to avoid build errors: VOID EFIAPI LegacyBiosDiskInterruptHandler( IN EFI_EXCEPTION_TYPE InterruptType, IN EFI_SYSTEM_CONTEXT SystemContext ) { // TODO: // 1) Save/restore registers from SystemContext.SystemContextX86 // 2) Decode AH: legacy (AH<0x41) vs. extended (0x41–0x48) // 3) Build/locate Disk Parameter Packet (ES:SI) for extended calls // 4) Call your 16→32→64 UEFI Block I/O thunk // 5) Set CF/ZF/EAX/etc. per BIOS spec and return (IRET) return; } Implement full dispatch by referencing EDK II’s LegacyBiosDxe/Int13Handler: AH = 0x00…0x01 (reset/status) AH = 0x02 (read sectors) AH = 0x41 (install extensions) AH = 0x42 (extended read) AH = 0x48 (get drive parameters) Once your handler is hooked and fully implemented, SeaBIOS will enumerate SATA, USB and NVMe devices normally.

XP only has problems creating the partition in 4K format. But if you create it elsewhere it can read it fine. What I do is I partition and format the hard drive using any Windows 7 setup DVD. Then restart and install XP in that partition. It installs fine and is correctly aligned.

No, the problem is not my IP, r3dfox 128 opens all sites from Cloudflare. 115 and older ones don't pass the check. 115 sometimes, and versions below 98 always fail.

Forum rules have been updated to remove the following: - screenshot/image size limitations - account deletions due to inactivity Both of these were due to issues in the past that are generally not present any longer. Screenshot size due to olden days of dial-up users. Account deletions due to previous software versions table size and other database related limitations.

Maybe it works for this too? Thank you very much! Setting dom.forms.button.standards_compliant to false did the trick. For the very first time, I was able to upload a test file from New Moon 28 to my main folder on Codeberg. I am really happy. Great find! Thanks again!

What issue do you refer to? Your statement is a bit unclear, at least for me.

Why didn't you say right away that you mean the Adguard filter lists inside uBlock Origin if I understood you correctly this time? Clear questions would be more effective in obtaining suitable answers. Anyway! I will test these filter lists and report. However, in single-process mode, uBlock Origin works great as far as I can say.

So far, I have only used two extensions in multi-process mode, uBlock Origin and Clear Cache. Now that uBO is presumably working again, even if only by neutering the multi-process mode, I will test this mode more closely and report. In any case, I use it especially to access Codeberg because, as you already know, this website is not stable in single-process mode and does not work properly in New Moon 28 or Serpent 52.

Ok. Although Mypal 68 is based on Firefox 68, however, its JavaScript engine is more recent on 83 level. So theoretically, some other extensions may no longer function properly as a result. I will keep that in mind and report in my thread about extensions when such problems appear.

At least, on my old computer with a 32-bit single-core CPU. I did a little research about the preference extensions.webextensions.remote. This is a preference to disable separate webextensions process(es). When set to true, Mypal 68 will use separate content process(es) for webextensions that are installed in the web browser. The number of these processes can be set by the preference dom.ipc.processCount.extension with the default value of 1. When extensions.webextensions.remote is set to false, then Mypal 68 won't use separate content process(es) for these webextensions. The extensions.webextensions.remote preference will only be read once. If you are changing this preference, the browser needs to be restarted for it to apply. I now assume that this preference has no effect when using Mypal 68 in single-process mode because there is only one process.

Thanks for replying! I injected the Event.submitter polyfill code into the Codeberg website in New Moon 28. Unfortunately, it doesn't solve the issue.