Leaderboard

Why Windows 10? You just could install Windows 8.1 X64 and dual boot it with your XP X86. Windows 8.1 is much better than Windows 10.

NTOSKRNL Emu_Extender Library of missing functions for Windows XP/2003/Vista/7 NTOSKRNL.EXE Project is intended to help in porting drivers from Windows 7/8/8.1/10 for work with Windows XP/2003/Vista/7 How-To: Compile sources to make ntoskrn8.sys Make corrections to target driver XXX.sys so that it loads ntoskrn8.sys instead of the original ntoskrnl.exe If XXX.sys is driver made for Windows 8, change security_cookie to random value, security_cookie is constant 0x4EE640BB(x32) / 0x32A2DF2D992B(x64) inside file, change only first match ! Place ntoskrn8.sys to X:/Windows/system32/drivers/ folder Compiling: 1) Install Windows 7 DDK v7.1.0 (download from Microsoft site) 1a) Original DDK header files has mistake with definintion of MmAllocateContiguousMemorySpecifyCacheNode, apply fix to two files \WinDDK\Win7\inc\ddk\ntddk.h and \WinDDK\Win7\inc\ddk\wdm.h: replace: #if (NTDDI_VERSION >= NTDDI_WIN2K) typedef ULONG NODE_REQUIREMENT; to: #if (NTDDI_VERSION >= NTDDI_VISTA) typedef ULONG NODE_REQUIREMENT; 2) Download project files to any local folder git clone https://github.com/MovAX0xDEAD/NTOSKRNL_Emu 3) Choose Target OS (XP, 2003, Vista or WIndows 7) for which OS Emu_Extender will be compiled. Keep in mind that depending on the target operating system the way of exporting the functions changes, if a function already exists in the kernel it will be simply redirected without injecting emulation code 4) Run shell: "Start Menu\Programs\Windows Driver Kits\Win7 7600.16385.1\Build Environments\Windows XXX\YYY Free Build Environment" (XXX - target OS, YYY - target CPU) 5) In shell change current directory to local project folder 6) Use shell command BLD to compile project 7) Compiled ntoskrn8.sys will be in ntoskrn8/objfre_XXX_x86/YYY folder STORPORT Windows 7 Emu_Extender This is Library of missing functions for Windows 7' STORPORT.SYS v6.1.7601.23403 to emulate Windows 8' STORPORT.SYS How-To: Compile ntoskrnl Emu_Extender Place storpor8.sys to X:/Windows/system32/drivers/ folder Make corrections to target xxx.sys so that it loads storpor8.sys instead of the original storport.sys Place backported storport.sys from Windows 7 to X:/Windows/system32/drivers/ folder Ported drivers: Windows 7's WDF 1.11 for Windows XP/2003 x32 Last version for Windows XP/2003 is 1.9, but possible to backport 1.11 version: 1) Get files from Windows 7 Updates (KB3125574): WDF01000.SYS v 1.11.9200.20755 WdfLdr.sys v 1.11.9200.16384 2) In WDF01000.SYS replace string ntoskrnl.exe to ntoskrn8.sys in import section 3) Recalc checksum If need coexist with original WDF1.9 drivers: 4) Rename WDF01000.SYS->WDF01_W8.SYS, WdfLdr.sys->WdfLdr8.sys 5) In WDF01_W8.SYS replace string WdfLdr.sys to WdfLdr8.sys in import section 6) In WdfLdr8.sys replace unicode string \Registry\Machine\System\CurrentControlSet\Services\Wdf%02d000 to \Registry\Machine\System\CurrentControlSet\Services\Wdf%02d_w8 7) In WdfLdr8.sys replace hex pattern F6 78 1B F6 to F6 EB 1B F6 (x32), ** ** to ** ** (x64) 8) In target driver XXX.sys replace string "WdfLdr.sys" to "WdfLdr8.sys" in import section 9) In .INF of ported driver add creating new service: AddService=WDF01_W8,, WDF.AddService .... [WDF.AddService] DisplayName = "Windows Driver Framework v1.11 for XP/2003" ServiceType = 1 ; SERVICE_KERNEL_DRIVER StartType = 3 ; SERVICE_DEMAND_START ErrorControl = 1 ; SERVICE_ERROR_NORMAL ServiceBinary = %12%\WDF01_W8.SYS LoadOrderGroup = Base Recalc checksum of all edited *.sys Windows 7's Storport.sys for Windows XP x32 Storport was released since Windows 2003, but possible to backport Windows 7 version: 1) Get files from Windows 7 Updates (KB3125574): storport.sys v 6.1.7600.23403 2) In storport.sys replace string ntoskrnl.exe to ntoskrn8.sys in import section, now storport.sys will import all kernel functions only from Emu_Extender 3) Storport uses MSI interrupts, need to force use only legacy/compatible interrupts x32 - replace hex pattern 8B 8E 3C 01 00 00 to B9 00 00 00 00 90 (mov ecx, [esi+13Ch] -> mov ecx, 0) x64 - replace hex pattern 8B 83 C0 01 00 00 to B8 00 00 00 00 90 (mov eax, [rbx+1C0h] -> mov eax, 0) 4) Recalc checksum Windows 7's NVMe driver for Windows XP x32 1) Get files from Windows 7 Updates (KB3125574): stornvme.sys v 6.1.7600.23403 2) MS Win7 NVMe driver require Win7 Storport.sys, use backported one Windows 8's USB3 driver for Windows XP x32 1) Get required files from Windows 8 (KB4534283/4556840, KB2984005, RTM ISO): ucx01000.sys v6.2.9200.22453 usbhub3.sys v6.2.9200.21180 usbxhci.sys v6.2.9200.22099 wpprecorder.sys v6.2.9200.16384 usbd.sys v6.2.9200.20761 from Vista Beta/Longhorn 5456.5: ksecdd.sys v6.0.5456.5 2) In files ucx01000.sys, usbhub3.sys, usbxhci.sys, wpprecorder.sys, usbd.sys change security_cookie to random value 3) In files ucx01000.sys, usbhub3.sys, usbxhci.sys, ksecdd.sys replace string name "ntoskrnl.exe" to "ntoskrn8.sys' in import section 4) Rename ksecdd.sys->ksecd8.sys, usbd.sys->usbd_w8.sys 5) In usbhub3.sys replace string name "ksecdd.sys" to "ksecd8.sys' in import section 6) In usbhub3.sys replace string name "usbd.sys" to "usbd_w8.sys' in import section, 7) recalc checksum Windows 8’s STORAHCI driver for Windows XP x32 STORAHCI driver requires storport.sys from Windows 8, but possible to use storport.sys v6.1.7601.23403 from Windows 7 Storport.sys from Windows 7 more compatible with Windows XP/2003 because it still call required PoStartNextPowerIrp when processing power IRPs. Microsoft removed calls to PoStartNextPowerIrp in Windows 8's storport.sys, without this call Windows XP/2003 kernel cannot finish current power IRP and start next IRP => it generate BSOD (0x0000009F). Also storport.sys from Windows 7 has compatibility mode to allow old XP/2003 kernels write crashdumps through storport based disk drivers. In storport.sys from Windows 8 compatibility mode was removed, writing crashdumps possible only with new kernels. Take attention: Windows 8's STORAHCI + Windows 7's STORPORT may have significal performance drop and high CPU usage, there is no fix yet 1) Get files from Windows 8 (RTM ISO): storahci.sys v 6.2.9200.16384 2) In storahci.sys replace string storport.sys to ntoskrn8.sys in import section 3) Storahci.sys was compiled with Windows 8 DDK's storport.h and writes values to new fields of _PORT_CONFIGURATION_INFORMATION struct, these fields not exist in Windows 7's storport.sys. Need to skip these writes to avoid damaging other structures in memory x32: Replace hex pattern 83 A6 C8 00 00 00 00 to 90 90 90 90 90 90 90 (and dword ptr [esi+0C8h], 0 -> nop) Replace hex pattern 83 8E CC 00 00 00 03 to 90 90 90 90 90 90 90 (or dword ptr [esi+0CCh], 3 -> nop) x64:Replace hex pattern 44 89 B7 D8 00 00 00 to 90 90 90 90 90 90 90 (mov [rdi+0D8h], r14d -> nop) Replace hex pattern 83 8F DC 00 00 00 03 to 90 90 90 90 90 90 90 (or dword ptr [rdi+0DCh], 3 -> nop) If you want compile storahci from sources (from Windows 8 DDK Samples), comment two lines ConfigInfo->BusResetHoldTime = 0; ConfigInfo->FeatureSupport |= STOR_ADAPTER_FEATURE_STOP_UNIT_DURING_POWER_DOWN; 4) In storahci.sys change security_cookie to random value 5) Recalc checksum Windows 7’s MSAHCI driver for Windows XP x32 1) Get files from Windows 7 Updates(KB3125574): atapi.sys v 6.1.7600.23403 ataport.sys v 6.1.7600.23403 msahci.sys v 6.1.7600.23403 pciidex.sys v 6.1.7600.23403 2) In ataport.sys, pciidex.sys replace string ntoskrnl.exe to ntoskrn8.sys in import section 3) Pciidex.sys uses MS Internal/Undocumented HalDispatchTable way to call functions from Kernel/HAL, for Windows XP/2003 need to use compatible variant: x32: Replace hex pattern FF 50 3C to FF 50 40 same in asm code: mov eax, ds:HalDispatchTable ... call dword ptr [eax+3Ch] => call dword ptr [eax+40h] x64: Replace hex pattern FF 50 78 to EB 2A 90 Replace hex pattern at offset +2Ch: CC CC CC CC CC CC CC CC to FF 90 80 00 00 00 EB CF, same in asm code: mov rax, cs:HalDispatchTable ... call qword ptr [rax+78h] => jmp patch orig: mov r10d, eax patch: call qword ptr [eax+80h] jmp orig 4) Recalc checksum 5) MSHDC.INF from Windows 7 conflict with original mshdc.inf from Windows XP/2003. msahci.sys enumerates IDE/SATA channels as "Internal_IDE_Channel" and compatible ID is "*PNP0600". Original mshdc.inf from Windows XP/2003 for compatible Device ID "*PNP0600" will install wrong "Standard IDE/ESDI Hard Disk Controller" driver Intel RSTe (Enterprise/Premium) AHCI/RAID driver 4.7.0.1098 for Windows XP/2003 Intel RST AHCI/RAID drivers (any version, last compatible is 16.8.3) for Windows XP/2003 These drivers require storport.sys from Windows 7, use backported version. 1) In file iaStorA.sys/iaStorAC.sys/iaStorAVC.sys replace string “ntoskrnl.exe” to “ntoskrn8.sys” in import section (do not change second string “NTOSKRNL.exe”) now these *.sys will import kernel functions only from Emu_Extender 3) Recalc checksum Implemented Func List v60: _chkstk _i64toa_s _i64tow_s _itoa_s _itow_s _ltoa_s _ltow_s _makepath_s _snprintf_s _snscanf_s _snwprintf_s _snwscanf_s _splitpath_s _strnset_s _strset_s _strtoui64 _swprintf _ui64toa_s _ui64tow_s _ultoa_s _ultow_s _vsnprintf_s _vsnwprintf_s _vswprintf _wcsnset_s _wcsset_s _wmakepath_s _wsplitpath_s _wtoi _wtol DbgkLkmdRegisterCallback EmClientQueryRuleState EtwActivityIdControl EtwEventEnabled EtwProviderEnabled EtwRegister EtwRegisterClassicProvider EtwUnregister EtwWrite EtwWriteString EtwWriteTransfer ExAcquireRundownProtectionCacheAware ExAcquireRundownProtectionCacheAwareEx ExAllocateCacheAwareRundownProtection ExDeleteLookasideListEx ExEnterCriticalRegionAndAcquireFastMutexUnsafe ExEnterCriticalRegionAndAcquireResourceExclusive ExEnterCriticalRegionAndAcquireResourceShared ExEnterPriorityRegionAndAcquireResourceExclusive ExEnterPriorityRegionAndAcquireResourceShared ExFreeCacheAwareRundownProtection ExfReleasePushLockShared ExfTryToWakePushLock ExGetFirmwareEnvironmentVariable ExInitializeLookasideListEx ExInitializeRundownProtectionCacheAware ExReInitializeRundownProtectionCacheAware ExReleaseFastMutexUnsafeAndLeaveCriticalRegion ExReleaseResourceAndLeaveCriticalRegion ExReleaseResourceAndLeavePriorityRegion ExReleaseRundownProtectionCacheAware ExReleaseRundownProtectionCacheAwareEx ExRundownCompletedCacheAware ExSetFirmwareEnvironmentVariable ExSizeOfRundownProtectionCacheAware ExWaitForRundownProtectionReleaseCacheAware IoAllocateSfioStreamIdentifier IoConnectInterruptEx IoDisconnectInterruptEx IoFreeSfioStreamIdentifier IoGetActivityIdIrp IoGetAffinityInterrupt IoGetDevicePropertyData IoGetIoPriorityHint IoGetSfioStreamIdentifier IoInitializeWorkItem IoQueueWorkItemEx IoSetActivityIdIrp IoSetDevicePropertyData IoSizeofWorkItem IoUninitializeWorkItem IoUnregisterPlugPlayNotificationEx KdRefreshDebuggerNotPresent KeAcquireGuardedMutex KeAcquireGuardedMutexUnsafe KeAlertThread KeAreAllApcsDisabled KeEnterGuardedRegion KeExpandKernelStackAndCallout KeGetCurrentNodeNumber KeGetCurrentProcessorNumberEx KeGetProcessorIndexFromNumber KeGetProcessorNumberFromIndex KeInitializeGuardedMutex KeInvalidateAllCaches KeInvalidateRangeAllCaches KeLeaveGuardedRegion KeQueryActiveGroupCount KeQueryActiveProcessorCount KeQueryActiveProcessorCountEx KeQueryDpcWatchdogInformation KeQueryGroupAffinity KeQueryHighestNodeNumber KeQueryLogicalProcessorRelationship KeQueryMaximumGroupCount KeQueryMaximumProcessorCount KeQueryMaximumProcessorCountEx KeQueryNodeActiveAffinity KeReleaseGuardedMutex KeReleaseGuardedMutexUnsafe KeRevertToUserAffinityThreadEx KeRevertToUserGroupAffinityThread KeSetActualBasePriorityThread KeSetCoalescableTimer KeSetSystemAffinityThreadEx KeSetSystemGroupAffinityThread KeSetTargetProcessorDpcEx KeTestAlertThread KeTryToAcquireGuardedMutex LdrResFindResource LdrResFindResourceDirectory LpcReplyWaitReplyPort LpcRequestWaitReplyPortEx LpcSendWaitReceivePort memcpy_s memmove_s MmAllocateContiguousMemorySpecifyCacheNode MmAllocateContiguousNodeMemory ObDeleteCapturedInsertInfo ObfDereferenceObjectWithTag ObfReferenceObjectWithTag ObGetObjectType ObQueryNameInfo PcwAddInstance PcwCloseInstance PcwCreateInstance PcwRegister PcwUnregister PoDisableSleepStates PoEndDeviceBusy PoGetSystemWake PoReenableSleepStates PoRegisterPowerSettingCallback PoSetDeviceBusyEx PoSetSystemWake PoStartDeviceBusy PoUnregisterPowerSettingCallback PoUserShutdownInitiated PsAcquireProcessExitSynchronization PsEnterPriorityRegion PsGetCurrentProcessWin32Process PsGetCurrentThreadProcess PsGetCurrentThreadProcessId PsGetCurrentThreadTeb PsGetCurrentThreadWin32Thread PsGetCurrentThreadWin32ThreadAndEnterCriticalRegion PsGetProcessSessionIdEx PsIsProtectedProcess PsIsSystemProcess PsLeavePriorityRegion PsReleaseProcessExitSynchronization PsSetCreateProcessNotifyRoutineEx RtlCheckPortableOperatingSystem RtlGetIntegerAtom RtlGetThreadLangIdByIndex RtlIsNtDdiVersionAvailable RtlQueryElevationFlags RtlQueryRegistryValuesEx RtlSetPortableOperatingSystem SeReportSecurityEventWithSubCategory SeSetAuditParameter SeSetAuthorizationCallbacks sprintf_s sscanf_s strcat_s strcpy_s strncat_s strncpy_s strnlen strtok_s swprintf_s swscanf_s vsprintf_s vswprintf_s wcscat_s wcscpy_s wcsncat_s wcsncpy_s wcsnlen wcstoul ZwAllocateLocallyUniqueId ZwAlpcConnectPort ZwAlpcSendWaitReceivePort ZwQueryLicenseValue ZwQueryVirtualMemory Download Sources https://github.com/MovAX0xDEAD/NTOSKRNL_Emu

Hi , I do not know if you care about the warranty . If you don't , you may just detach WinBonds' chip pins 7 and 8 from the board , it is located near the USB . The first pin is marked by a dot . So the number eight is right across . This will allow to bypass the uplink directly to the controller. This is intended for people with at least some skills , I'm sure you have them , but I'm not responsible for any damage . I did that with mine and it worked . It now shows as generic storage device with the right amount of capacity , I can format it and if I remove the HDD from the enclosure and plug into sata of my PC - all info is there . Though you will loose some "power saving" features and the drive will not stop spinning if you click safely remove. Don't worry , it will safely park itself (retract).

I think whether or not it'll be worth it to you depends on what you like to do with your XP machine and what parts you're able to get. During XP's support period, XP64 had a reputation for not being supported by hardware/software. I personally have rarely run into that issue ... at least until after XP lost favor with Microsoft, and compilers stopped providing support for XP, thus causing newer programs to not work. But that's a hurdle all XP OSes face. The main advantage with XP64 is the ability to run 64-bit programs. If you're doing things that require a lot of RAM (e.g. running a web browser with a ton of tabs, video editing, rendering complex 3D scenes, gaming, etc.) you will definitely appreciate this feature. It's not just XP32 that is (normally, without the PAE mod) limited to 4GB; 32-bit programs in general, I believe, are also unable to use more than 4 GB of memory. 64-bit programs can use much more than 4 GB; I'm not sure what the upper limit is. And if you're like me and you max out the (normal?) memory cap of XP64 with 128 GB (because I'm nuts) your 64-bit programs will have a LOT of real estate to use. (I'm not sure if XP64 can go higher than 128 GB. Windows XP64 is technically more kin to Windows Server 2003, and Server 2003's Enterprise and Datacenter editions can take up to 1 TB of RAM.) The main drawback will be that you'll lose the ability to run 16-bit programs. If you've got some favorite 16-bit apps and you upgrade to XP64, you'll either need to have a spare machine running a 16 or 32-bit OS, have your computer dual boot with such an OS, or run those in a virtual machine.' The other question will be sourcing parts that are known to work on XP64 and have driver support. When @XP-x64-Lover located drivers for the X99 SABERTOOTH motherboards, I used that opportunity to give my daily driver some of the best hardware I could find for such a system: i7-6950X CPU, 128 GB of RAM, and with the .inf driver mod described at Matt's Repository, a GTX TITAN X (Maxwell version). It was a long-needed overhaul and damn worth it for what I do. I don't know offhand if we have a database of motherboards with known driver support for XP64, so before you take the plunge you'll want to do research. Odds are if your desired parts have XP drivers, they should have XP64 drivers or at least their chipset will. However, you will want to be sure before you try anything.

The original Basilisk 52 project from "upstream" did have WE support, be it somewhat inferior to the one present in the Mozilla 52.6.0 platform they forked off as UXP; the MCP devs disabled/removed some WE features/APIs initially, e.g. id-less WEs were not supported, because Basilisk 52 does not observe extension-signing... Having partial WE support in their test UXP browser application (Basilisk) was something the MCP people felt quite uneasy about, given their lack of any will to further maintain that part of the platform code; coupled with their general disdain/aversion for WE (a Google Chrome spawned and Firefox-aped technology), they finally removed completely all traces of WE support in Basilisk 52 in February 2019 (Basilisk-52.9.2018.12.18 the last with WE support, Basilisk-52.9.2019.02.11 the first with no WE support). After consultation with members here (where are you @Mathwiz ? ) it was decided that Serpent 52 will continue to contain that (partial) WE support in an "unmaintained/use at your own risk" state ; WE related security issues are not being patched by upstream/our current maintainer; if you install from AMO, be warned that many (WE) addons there are marked in a blanket fashion as "working in Fx 48.0 and higher", but often times this is simply not true, because WEs of today are NOT being tested on Fx 48-52 ; additionally, Serpent 52 does not check AMO for WE updates, so that is left upon you (i.e. bookmark a WE addon's page on AMO and visit occasionally for eventual updates); be weary of WE updates, in many cases the updated addon uses WE APIs not present in St52... I personally use several WEs in St52, e.g. the userscript manager Violentmonkey 2.12.9 and userstyle manager Stylus 1.4.23

@Sampei.Nihirahas only been using New Moon 28; in his reply, he's not saying anything about Serpent 52; once again, the usual confusion between platform (UXP) and applications (NM28 vs St52) built on top of that same platform (i.e., the common platform does not exclude the existence of differences between the applications...) ... A simple test in Firefox ESR 52.9.1 reveals that privacy.firstparty.isolate;false indeed exists already in it, so it's no wonder it's there too in its direct descendant, Serpent 52.9.0 ... A cursory search in Bugzilla reveals that the pref itself was first implemented as part of #1260931 : [Bug 1260931 - Part 2: add pref privacy.firstparty.isolate] https://hg.mozilla.org/mozilla-central/rev/d173cefba1e1 in Firefox 51.0a1; but to give credit to Sampei , the feature behind that pref seems to have matured in Fx 55.0 stable, and this is where many Google search results agree on: https://www.bleepingcomputer.com/news/software/another-tor-browser-feature-makes-it-into-firefox-first-party-isolation/ https://www.ghacks.net/2017/11/22/how-to-enable-first-party-isolation-in-firefox/ TL;DR privacy.firstparty.isolate does not exist in NM28, but does exist in St52 (default=false); toggling that pref in St52 (to true) presents risks that (some) sites may break, because First Party Isolation in FxESR 52 was in its infancy development-wise... Addendum: privacy.userContext.ui.enabled likewise is absent in NM28, but present in St52; I'll leave it as an exercise to the reader to track down when that pref was first introduced in Firefox (and thus ended up in St52) ... Hint: it's related to Container Tabs, a feature originally present in FxESR 52 and official Basilisk 52, which the MCP devs later decided to scrap ; due to demand by members here, again expressed more loudly by MIA @Mathwiz , that feature still survives in Serpent 52.9.0...

That is exactly what I was looking for. No need javascript, videos wont buffer and site wont lag all the time (on real youtube did despite fast 100mb/s broadband and fast quad core cpu).

Yes I remember that thread, I may have chimed in as did some others. Glad it was kept too. Also good question, what happened to @Mathwiz, he seems to have vanished.

Parabola with lightweight WM and sometimes dual boot to XP to play my favorite games OFFLINE

If you specify the names of your installed devices, maybe you could find recomendations of drivers for older Windows versions.

I cannot find any information relating to Minecraft changing requirements to Windows 10 only.

@XPerceniol @sparty411 @roytam1 @VistaLover @XP-x64-Lover @RainyShadow @Win10-Hater Thank you all for the beautiful words written.

Thanks for the suggestion , actually GPUZ was the first thing I've tried . But any version of GPU-z starting from 0-8-5 hangs up the whole windows XP64 system to the point of hard reset . Please keep in mind that I'm talking about 64 bit , not x86. Older versions of GPU-z work fine , but they do not properly detect this GPU. By the way , Nvidia CPL must show the highest version of PCI express available, it shouldn't depend on the current load. And it shows gen. 2.0 on this exact PC with Vista x64. My card is not EVGA , I try to avoid EVGA as much as I can , I've had quite a few problems with their quality. It's just Nvidia (no other branding, from their website) , reference design. I do notice poor 3d performance with games on XP64, the same game is like 2x times faster with Vista. Hardware: GPU: Geforce GTX Titan 6GB mfg date February 2013, Motherboard: Fujitsu Siemens D3012-A11-GS3 DDR3 RAM 16GB with Intel chipset Q45 mfg date April 2011. CPU: Intel® Xeon® Processor X3370 12M Cache, 3.00 GHZ (Quad). PSU: FSP (Fujitsu Siemens Power) 600W ,rare design and size ,supplied with this PC, fits only Fujitsu/Siemens housings.

the source leaks have no real security impact

WinNTSetup 4.5.1 - VHD GUI will be saved to ini - ini option BootMountExclude supports DiskID - fixes listview font on non darkmode

It depends. Is it a desktop or a laptop? You typically have a much easier time getting older operating systems to work on desktops but can be spotty on laptops. Once you can answer that and tell us any other hardware it has can help determine whether or not Windows 2000 would install and actually usable.

Thus far.. @roytam1 has done our community an enormous service with his proficient browser builds. So, between Firefox 52.9.1 ESR; Serpent, and New Moon, I'm able to do everything I need to. When I do have to use Chrome, regrettably, Vivaldi/Opera/Iron are all only based on 49, so I only use it when I truly need to because of 5 years of gaping security holes. Otherwise.. I'm basically on a 'Rickroll'

Hi ntoskrnl_extender compilable and usable on xp64 too, usb3/storage drivers works (but not tested widely) "OneCore API and XomPie" - read carefully what these and this projects do, they live in different words "ring3 vs ring0" and no way to say hello to companion :)

Win32 is really busy with more important things than answering this loooong texts . You should read and re-test for youself , like many times. Like we do. Trial and error . You're not the only one , you know. And read the original instructions precisely (maybe use translate if you don't read English well enough) I repeat his words again : April 2017 . (hence the famous ISO)

Well , those aren't "my instructions" , those were given by win32 and PERFECTLY working in my case (the local method). If you want , you may scroll back and read it in his own words (why didn't you do that earlier, if you don't understand my explanations ?) . I'm not really sure what you do , but I remember you even had problems with BSOD after replacing the kernel in your system , yet others didn't . Win32 told many times , his files are meant to Vista updated to April 2017 , you may ask again or re-read the comments . So best solution would be the local method , yet it doesn't work in your case too . Perhaps you may wanna ask someone else.

No real reason, IMO. I do run my 4GB as a single NTFS partition, too. Among other things it avoids using more than one drive letter, which is great! @SamirD, OTOH, loves 2GB partitions, so I'm not surprised by his comment.

Banned on Rules #1.a/b/d.

It successfully compiled in the Vista x64 build environment so it wouldn't hurt to try in the XP/2003 x64 one.

This is AMAZING! I should give this a try on my XP32 laptop and see what she can do. Out of curiosity, how difficult would it be to create a version of this for XP64? Is it just a matter of compiling a certain way?

I really should have asked around here before I attempted doing this, but ... I've been looking at discussions over at Epic Games' forums for its Unreal Engine and saw a discussion about giving Windows XP64 DirectX 10 functionality. The link provided in the discussion was this: http://www.raymond.cc/blog/easily-install-and-download-directx-10-for-windows-xp/ I read through the article and decided to give it a whirl, following the "Download DirectX 10 for Windows XP" link to Softpedia, which gave me DirectX 10 for Windows XP RC2 Pre Fix 3 by LWGame. (I didn't bother with that "DirectX changer" mentioned at the end of the article. Blegh.) Has anyone ever looked into doing this for their XP or XP64 machines before, and is that LWGame patcher trustworthy? I'm not so certain it's going to work out: DXDiag 32-bit says that my machine is running DX10, but the 64-bit DXDiag says it's still got DX9.0c. And, what's a little worrisome to me is that the Add and Remove Programs list isn't propagating now ... The patcher has provided no Start Menu option with which to uninstall DX10 as Raymond.cc claims there is. Incidentally, the LWGame installer doesn't provide any options for installing DX for XP64 either. Maybe they were writing about the other patcher mentioned, the one by KM-Software, but they didn't provide a download link to that. So I guess my questions are: Is this thing actually legit, or did I get taken in by malware? If it's legit but it won't work, what should I do to get rid of it? Load a previous restore point? Pop in the XP64 install disc and run sfc.exe /scannow? EDIT/UPDATE: Okay, yeah, I think I really should have asked people in the know before I attempted this. Aside from Add/Remove Programs no longer propagating (and being forced to kill a rundll32.exe process each time I check because Add/Remove Programs won't close normally and instead gobbles up a lot of system resources in the background), I'm getting errors such as "The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll" when using programs like Media Player Classic Home Cinema (though it will still play videos and music). Winamp won't load at all. At least I feel reasonably certain this is just the result of messing around with system files when I don't have a real clue what I'm doing, and not malware. The question is ... how best to undo my mistake? I've looked up how-tos that advise deleting the entire DirectX registry under HKEY_LOCAL_MACHINE\\Software\\Microsoft\\DirectX\ then restarting and reinstalling DirectX 9.0c, as well as this explanation of the error I encountered with MPC-HC at A Blue Star ... but I have a feeling this goes beyond whatever DirectX files were replaced. Would a system restore fix all of this?

The graphics card is actually the newest part of the rig (aside from the hard drives). Since 2012 I've been using a N560GTX-Ti Hawk as the previous video card was damaged by a lightning strike (the bizarre thing about that: the old video card, a BFGTech GeForce 8800 GT, still works but when doing 3D graphics beyond a certain level, it will cause the computer to lock up). So the video card should be able to handle DX10 stuff ... Its specs say that it can handle up to DX11, even, and it supports OpenGl up to version 4.1.

System Restore restores the registry to a backup created at the same time with the restore point, so there mustn't be anything related to DirectX 10 left in your system's registry. The real issue is, perhaps, that DirectX 10 must be supported by your graphics card, if it is older than Windows Vista then this surely isn't the case.

OK, the System Restore seems to have taken care of the problem. Checked the registry, too. Any extraneous registry keys/files relating to DirectX 10 shouldn't cause a problem if nothing in the rest of the system actually points to them because of the restore, I imagine? Alas, it would have been nice if there were an unofficial working DirectX 10 patch for XP64 ... Or, for that matter, DX11 or 12, heh.

That's a relief, at least. Though the way my OS is behaving now after trying to install this is very troubling ... The most recent System Restore point I've got is from a few days ago, barring the one automatically created when I tried to install this. Would that fix the problem, or will this require more in-depth action?