roytam1

see this for solution: http://www.msfn.org/board/topic/173049-windowsmicrosoft-update-not-working-on-windows-2000xp2003/#entry1089383

Does win2000 support Paragon GPT Loader?

http://bearwindows.boot-land.net/scsifix.7z

harkaz, i appreciate the work that you have done.. i installed your "FIX" for the MS15-010/3013455 update, which, incidentally, took a leap of faith, since it is a modified "windows" file and it also requires installing a "certificate" for it.. with all of the talk about komodia's installing certificates etc, and with "privdog", and everything else associated with that, when you talk about installing a certificate (not to mention installing a modified windows file), it is concerning: http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/ http://www.pcworld.com/article/2887632/secure-advertising-tool-privdog-compromises-https-security.html i would like to know how to remove your certificate that i installed, in case i ever want to.. does it have a name? to remove the certificate, would you simply delete the "HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\Root\Certificates\F2C90A445A5E0F0F79AEDEB694D50B9656B24A71" regkey, or would deleting that regkey cause problems with other certificates? i just wanted to mention something.. looking at the screenshot that you posted, you say that "the order of command execution is reversed", but there seems to be more to it.. in your screenshot, in the code in the window on the left, it has a "@sc1_InitializeTwilightcontours@12" while the code in the window on the right doesn't, at least that is the way that it looks to me.. maybe you already noticed that, or maybe i am confused and that actually was the point that you were making.. regarding the MS15-010/3013455 update, from what you have posted, it seems that the "win32k.sys" file that was installed by the 3013455 update was flawed, and that the 3037639 update, which was meant to fix the font problem, simply tweaks windows in order to allow it to use the flawed win32k.sys file, but without the font-problems.. tweaking windows to where it can use a flawed win32k.sys file (but without the font problems) doesn't sound good to me.. from reading some of the other posts here, it seems that some people opted to tweak the win32k.sys file themselves.. i suppose that they also had to use their own certificates in order for windows to allow the modified win32k.sys file to be installed and to run.. for the record, i don't know anything about "coding" software.. i am not an "expert".. i am just a regular home-computer-user.. nope, I just modified win32.sys and replace them(in both dllcache and system32) on-the-fly right after installing original KB3013455 patch. So no cert. are needed.

I do not believe there's a similar project for Windows NT 4.0 sadly. That's one reason why I've sort of given up using it, even though I like NT 4. The only thing I know of that exists for NT4 is a transformation pack that makes NT4 look a bit like Windows Vista and the link can be found in this forum, but that just changes the looks, it won't change the functions. BWC's FCW doesn't even run on NT4 and just crashes with an error message. So someone can correct me if I'm wrong but I don't believe I am.There is a group of people playing around the leaked sources to reconstruct an usable build. http://opennt.net/?id=Home

Thanks for report. Did I misunderstood the instruction?Patch harkaz code as fixed code for all languages? Patch 55D1F : E8 F7 04 00 00 Patch 55D2A : E8 17 7E FF FF seems so.

Adjust PE checksum http://www.coderforlife.com/projects/utilities/#PEChecksum A XP at a virtual machine does boot still. Edited: Ignore this. Try you patch. A different approach, the same patch: search for 8b cb 8b d7 e8 expect address about 55D1F find e.g. E8 22 7E FF FF at 55D1F search for 8b d7 8b cb e8 expect address about 55D2A find e.g. E8 EC 04 00 00 at 55D2A Patch 55D1F : E8 EC 04 00 00 Patch 55D2A : E8 22 7E FF FF Yeah, that was exactly the result I got by doing it my way, but I didn't adjust PE checksum - after using the tool you suggested, I didn't get a BSOD anymore when booting, but the font corruption wasn't cured. So, as Dave-H said that he had to re-do the ClearType tuning, I tried this, too, by installing Microsofts Cleartype Tuner Powertoy. But then I got BSOD after BSOD, so in the end, I had to recover my imaged file :-( Has anyone an idea what did go wrong? not only copying bytes but also need offset value adjustment as http://www.msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/page-13#entry1095037posted.

I can't find such difference in my 6712 CHT when comparing with 6648 CHT. EDIT: oh you mean WindowsServer2003-KB3013455-x86-ENU vs WindowsServer2003-KB3037639-x86-ENU in post http://www.msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/page-13#entry1095037does work. thanks!

Thanks for your information. Too late for me to read this and I wasted whole day battling with it, I even opened a question in superuser. http://superuser.com/questions/876542/ugly-font-in-xp-how-can-i-restore-it/876668#876668 http://answers.microsoft.com/en-us/windows/forum/windows_xp-windows_update/kb3013455-breaks-font-smoothing/0400147f-fe2e-4d53-8b35-1a7a06962087?tm=1423669336226

Embedded KB2686509 has kblCheckerE.dll but not kblChecker.dll and it checks for HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductSuite == "EmbeddedNT" as Prerequisite

IIRC POSReady has no .net 1.1 runtime installed

BTW blackwingcat had made .net 1.1 patch available to 2000/XP as well.

found another issue: patched kernel (with any hal) makes EAC can't read Virtual Drive created with Daemon Tools.

BTW I wrote another starter to auto-select most idle core for the program that requires single-core. https://mega.co.nz/#!GYlGjDCZ!VQGTLKL2Cjr6XCxI4jb2786KaynIMbJh3Sd-sDftTsM As it reads HKEY_PERFORMANCE_DATA for measuring CPU usage per core, it takes 1 second before starting program. And it keeps running for 2 seconds after starting program for setting active core again because some programs try to set itself to use Core 0 upon start.

The temporary solution would be to allow Virtual PC 2007 process to use only one processor. For instance, I used Process Explorer and right =click Virtual PC.exe, set the Processor Affinity to only use CPU 0. By setting the Processor Affinity to use only CPU 0 under Windows NT 3.51, I was able to install Windows NT 3.51 successfully. Once I close VirtualPC 2007 and restart it, VPC gets defaulted to use four cores which in retrospect that causes data corruption on the Windows NT 3.51 guest to appear. Other OSes such as MS-DOS, FreeDOS, Windows 3.0, Windows 3.1 and OS/2 Warp all work without problems. It seems to me that Windows NT 3.51 guest under Virtual PC 2007 doesn't even like multiple cores. Is there a permanent solution to overcome this issue? I'm sorry if my comment clearly didn't make since or that I wasn't being all that specific, but I'm tired and I'm heading for bed soon. Update 1: Nevermind. I solved it when I stumbled upon this article regarding running Virtual PC 2007 on multi-processor and/or multi-core processors. Have a look: http://virtuallyfun.superglobalmegacorp.com/?p=154 I've learned that operating systems such as Windows for Workgroups 3.11, Windows 95 and even Windows NT 3.51 won't work correctly leading up to long latency, disk and data corruption errors to a point where the operating system will not even boot at all. When Microsoft Virtual PC was a Connectix product it was mean to run on a single CPU or single core (up to 4.29 GHz). And now since newer computers with multi-core processors are replacing older computers with single core processors, the fix would be to set the Virtual PC.exe CPU affinity to a single core before any virtual machines are started. Now to overcome this limitation, I downloaded a utility called Start Affinity. It can be found on this page: http://www.adsciengineering.com/StartAffinity/ StartAffinity is a freeware tool that is designed to start software by restricting it to certain CPU affinity masks. Since Virtual PC is not designed for multi-processor/multi-core computers, I had to enter this command to make sure Virtual PC 2007 always starts on CPU processor 0: I hope that that setting the CPU affinity to use only core 0 solves the data corruption/failed installation of Windows NT 3.51. Update 2: For some reason, StartAffinity shows the command prompt window for a brief moment upon starting Microsoft Virtual PC 2007 with only Core 0 enabled. To get rid of the command prompt window, I had to modify the shortcut properties and add this line: By using HStart with the /noconsole and /idle switches, HStart will make StartAffinity start without the command prompt window and lower the CPU priority to idle status. The Hidden Start utility can be found on this page: http://www.ntwind.com/software/hstart.html If there are any questions regarding this thread, let me know. I recompiled StartAffinity with TinyCC and have no-console flag set. https://mega.co.nz/#!6cdRRCLQ!YfIM2F4j4DHPgglfuwZcuEVOLTIwp7LqJNgFYvJfW-g

I'm home now and tested new hal patch with exact environment with the procedure that caused BSoD before.And test passed. although the hal.dll is patched, the rtenicxp.sys is updated to latest version, it is still crashed.

1.alter's uniata driver may work. see http://www.betaarchive.com/forum/viewtopic.php?f=61&p=332204#p332204 2.3rd party USB 1.1 driver available 3.some old 802.11b adapter has NT4 driver 5.isn't MS released an update for AGP? more info: http://bearwindows.boot-land.net/winnt4.htm

I'm home now and tested new hal patch with exact environment with the procedure that caused BSoD before. And test passed.

BTW for those using USB WebCam with 4GB/64GB patch, it is better to replace usbvideo.sys from 2K3 SP2.

I haven't test "new" hal patch on the system that can crash(I have the patch from you running on the machine in $workplace, but since it is not using Realtek NIC I don't know how to crash it)

the assembly code around this is: INIT:8002DCF5 loc_8002DCF5: ; CODE XREF: HalInitSystem(x,x)+307jINIT:8002DCF5 mov _HalpPhysicalMemoryMayAppearAbove4GB, 1INIT:8002DCFCINIT:8002DCFC loc_8002DCFC: ; CODE XREF: HalInitSystem(x,x)+30FjINIT:8002DCFC push 1INIT:8002DCFE push 10hINIT:8002DD00 push 1000000hINIT:8002DD05 push ebxINIT:8002DD06 mov dword_800232C4, 40hINIT:8002DD10 mov esi, 10000hINIT:8002DD15 call _HalpAllocPhysicalMemory@16 ; HalpAllocPhysicalMemory(x,x,x,x)INIT:8002DD1A cmp eax, ediINIT:8002DD1C jnz short loc_8002DD20INIT:8002DD1E xor esi, esiEDIT: the page you found may be this (in Chinese):http://www.pediy.com/kssd/pediy12/142776.html

I did update it to latest version downloadable in realtek.com, but same BSoD happens.

But... let me understand this right: 1. ) You located the points to patch using the search hexstrings I provided, instead of fixed offsets, right? 2. ) You fixed the checksums, using pechecksum.exe (as recommended) or using modifype.exe, right? 3. ) You replaced usbport.sys by the one reccommended, right? 4. ) It worked, right? Your XP machine became able to see and access more that 4 GiB RAM, right? If all the above is right, please do post a new screenshot of the machine's My Computer's Properties, please. both 1 to 4 are "Yes". Then, congratulations! Now, was only because of your instigation that I came upon the idea of small unique search hexstrings unlike to change on localization as a method providing universal patches... and your success using them on a CHT version (which I did not investigate, all my work was done on the ENU version) constitutes the proof-of-concept for this method. So thanks! Now, as for your BSOD: if your debugging is right (and I do think it is), then the problem is solved for now. Let at least one week of intensive use pass before putting VPCNetS2.sys back. If no other BSOD happens, I think you can consider VPCNetS2.sys really was the source of the problem. In that case, maybe searching for a later, newer version of that file might be in order. Let's wait and see. Of course, please do keep me posted on what happens next, OK? I got another BSoD now.

Environment: VMPlayer 5.0.2 on XP SP3 with 4GB patch, i5-3450, Intel B75 chipset, 4GB DDR3 VM Settings: 1 core (ACPI Uniprocessor PC) 256MB RAM SCSI 4GB Disk (vmscsi) vmxnet with VMWare Tools 7.8.4 / 9.2.2 installed Extended Kernel v24b Game / Extended Core v14c

But... let me understand this right: 1. ) You located the points to patch using the search hexstrings I provided, instead of fixed offsets, right? 2. ) You fixed the checksums, using pechecksum.exe (as recommended) or using modifype.exe, right? 3. ) You replaced usbport.sys by the one reccommended, right? 4. ) It worked, right? Your XP machine became able to see and access more that 4 GiB RAM, right? If all the above is right, please do post a new screenshot of the machine's My Computer's Properties, please. Now... You've got a crash. Was it a BSOD? Was it a Black Screen? Was it a Full Freeze? Or did the machine just turn off? And what exactly were you doing at that precise moment? Please do bear with me, my crystal ball is out on the shop, for tunning (again!). both 1 to 4 are "Yes". screenshot: http://i.imgur.com/YtnYYBn.png and the crash was BSoD. in that moment I was messing Win 8.1 VM(1GB RAM, 32bit) using VMPlayer 5.0.2. dumpchk thinks VPCNetS2.sys cause the crash and I removed it now. windbg !analyze -v report: READ_ADDRESS: f7b5b000CURRENT_IRQL: 2FAULTING_IP:hal!HalpMovntiCopyBuffer+f806eebc7 8b06 mov eax,dword ptr [esi]CUSTOMER_CRASH_COUNT: 1DEFAULT_BUCKET_ID: DRIVER_FAULTBUGCHECK_STR: 0xAPROCESS_NAME: IdleLAST_CONTROL_TRANSFER: from 806ea404 to 806eebc7STACK_TEXT: 80551d30 806ea404 8a2a3ffe f7b5affe 00000002 hal!HalpMovntiCopyBuffer+0xf80551d50 806eb295 f7b5affe 8b2c2ef8 00000002 hal!HalpCopyBufferMap+0xb680551d9c 806ea62e 88ad4880 878cfc20 012c2ed4 hal!HalpMapTransfer+0x17980551dec 806eb6e4 8923b3f8 00000000 8b2c2ed4 hal!HalpAllocateAdapterCallback+0xa280551e18 806eacd9 02ad4880 8c18f324 00000006 hal!HalAllocateAdapterChannel+0x12680551e3c f6d9b4fe 88ad4880 8923b3f8 00000088 hal!HalBuildScatterGatherList+0x22380551e94 f6d82a08 86aceae8 8820d008 881ad140 NDIS!ndisMAllocSGList+0xd980551eb0 f75bb3e7 8820d600 86acea80 881ad140 NDIS!ndisMSendX+0x1a0WARNING: Stack unwind information not available. Following frames may be wrong.80551f00 f6d82985 8820d000 881ad140 00000002 VPCNetS2+0x43e780551f28 ae051d40 8815c008 881ad140 88157840 NDIS!ndisMSendX+0x1d680551f50 ae051916 88157840 881ad140 87494b88 tcpip!ARPSendData+0x19880551f7c ae05165a 88157840 80551f02 00000001 tcpip!ARPTransmit+0x19380551fac ae05179f 8816e888 8da8a8c0 881ad140 tcpip!SendIPPacket+0x193805520f8 ae055b07 ae08fb98 86bb9a28 86bb99c0 tcpip!IPTransmit+0x289e80552164 ae055923 11b5157f 00000002 00000000 tcpip!TCPSend+0x5d880552188 ae04ea0e 00000002 00000002 805521b4 tcpip!ProcessPerCpuTCBDelayQ+0x95805521bc ae04e955 00000002 ae04e901 ae04e3d6 tcpip!ProcessTCBDelayQ+0xc4805521c8 ae04e3d6 00000000 8917f130 ae04e7f8 tcpip!TCPRcvComplete+0x20805521d4 ae04e7f8 f6da4c40 88157840 00000000 tcpip!IPRcvComplete+0x21805521d8 f6da4c40 88157840 00000000 8746e710 tcpip!ARPRcvComplete+0x580552228 f75bb74b 00382d98 80552250 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a48055226c f6da4b9f 8820d000 883b0120 00000000 VPCNetS2+0x474b805522a8 f63b6888 00000001 883b00e8 88379000 NDIS!ethFilterDprIndicateReceivePacket+0x1c2805522b8 882102f8 805523f8 f63b87cf 00382d98 Rtenicxp+0xd888805522bc 805523f8 f63b87cf 00382d98 80552360 0x882102f8805522c0 f63b87cf 00382d98 80552360 00000001 nt!KiDoubleFaultStack+0x2cf8805523f8 f63bbf92 88439578 8923b4f8 88ac3f90 Rtenicxp+0xf7cf80552410 f6d9ae99 88ac3000 8055d0c0 ffdff9c0 Rtenicxp+0x12f9280552428 80546f9f 88ac3fa4 88ac3f90 00000000 NDIS!ndisMDpcX+0x2180552450 80546e84 00000000 0000000e 00000000 nt!KiRetireDpcList+0x6180552454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28STACK_COMMAND: kbFOLLOWUP_IP:VPCNetS2+43e7f75bb3e7 ?? ???SYMBOL_STACK_INDEX: 8SYMBOL_NAME: VPCNetS2+43e7FOLLOWUP_NAME: MachineOwnerMODULE_NAME: VPCNetS2IMAGE_NAME: VPCNetS2.sysDEBUG_FLR_IMAGE_TIMESTAMP: 3e1f20e0FAILURE_BUCKET_ID: 0xA_VPCNetS2+43e7BUCKET_ID: 0xA_VPCNetS2+43e7