LoneCrusader last won the day on September 13 2020
LoneCrusader had the most liked content!
About LoneCrusader

Contact Methods
-
Website URL
http://
Profile Information
-
OS
98SE
LoneCrusader's Achievements
286
Reputation
-
Hello and welcome to the forum! Always nice to see some interest in 95, although I'm not able to give the level of attention that I used to give to my projects, and it's been a long time since I actually installed an unmodified version of Windows 95 to any system. Long ago I built a slipstreamed version that bypasses the need for FIX95CPU, XUSBSUPP, etc. to be installed manually and saves so many headaches such as these you are facing. So, fair warning, my memory may be a bit rusty! A few initial thoughts - I can see problems arising from trying to accomplish all the tasks in one pass so to speak... First - I would not attempt to fix the SATA issue until after the other issues are sorted. As SweetLow suggests, try using any available Legacy modes for the board storage controllers, or even leave them in compatibility mode until the rest is fixed. If I remember correctly, the SATA patch should work with the last 95 version of ESDI_506.PDR, but if not, it is possible to simply use the 98 version of this file.** (**may require "downversioning" hex-edit!) Second - XUSBSUPP, or the official MS USB updates, will replace VMM.VXD. This will break any previous installation of PATCHMEM and require repatching. Another reason to sort issues one by one. Third - The 98 INF files could definitely cause some weird issues as there are differences between them and the ones for 95. I may be able to provide a matching set specifically made for 95, but I can't promise a timeframe on this. It may be a simple copy, zip, and publish, but I'll have to go back and compare old notes and see whether the ones in my slipstreamed copy are affected by any other changes I've made. I just never expected interest for 95 on these honestly; pleasantly surprised! Fourth - MS set a hard limitation in ESDI_506.PDR that you cannot use an optical drive as the Primary IDE Master. Are you using a SATA HDD and a PATA ODD by chance? I encountered this problem before. rloew was able to patch out this issue, but I'm not certain that this patch exists "by itself" anywhere; it may only exist as one of many changes inside one of his larger packages, such as TBPLUS, which of course was only specifically made for 98. It's possible to use the 98 driver as I mentioned, but this would require a lot of time digging through our old emails for me to find a definitive answer. The meaning of "Projects" seems to vary among members; some of them see it as a place to discuss their "projects" as in patches, fixes, updates, guides, etc. While others see it as a place to discuss "project machines" they are working on. It's not really an issue either way as far as I'm concerned.. not like we get a lot of new members or posters these days, haha.
-
These had no effect on the issue. Same result, Code 39 error. Thanks again! These USB3 drivers are working properly with the USB mouse on the laptop. So far I have XP x86 and x64 up and running with the patched ACPI files and USB3 files. NVidia drivers 368.81 load under x86 with a couple of error boxes thrown when the desktop loads; but under x64 I get a BSOD, STOP: 0x00000050, PAGE_FAULT_IN_NONPAGED_AREA in nv4_mini.sys. (Given the CPU is Skylake I guess it's time to throw in the other patches... ) Not sure if anything else special needs to be done since these are "980M" cards rather than desktop 980's. If this gets much deeper I will probably create a separate thread about it; don't want to get too far off topic.
-
Good to see XPx64 getting some love. I keep finding things that have been fixed in x86 but not fixed in x64. Thanks for the package. I'm a little rusty on what all has been done; tried to follow it all however long ago before the original Win-Raid thread got messed up and changed hands but lost track of it since. Too many real life issues since then.. work, people passing away, etc. Only now getting (still limited) opportunities to experiment with XP and my newer hardware. (When are the HAL.DLL and intelppm.sys patches needed?) Using the last ACPI.SYS got XP x64 up and running on the laptop (MSI GT80S), but now I have another problem. I added the backported USB3 drivers from @George King's v24 package linked here to both XP x86 and x64 on the laptop. The USB controller and hub seem to be installed and working properly, but when I connect a USB mouse to the system, it doesn't work and shows a yellow-bang "Code 39" error under the Device Manager. Any ideas?
-
I don't know who to ask, and not to disturb admins, i will ask you this question.
Since when did signatures rules changed? On my profile, i have an old signature of 13 lines, and now i can't edit my signature properly since it requires four lines, and i have a problem with that since i can't edit my signature with updated laptops and computers specs.
I can't find a thread with a post when did that change occurred...
Thanks in advance.-
Apparently this has been the policy for a very long time. I remember reading about the 4 line text and image size requirement somewhere when I joined... Here's the best documentation I could find.
I would assume that your signature somehow slipped through the cracks before but is now broken since it exceeds the limit. Not sure how to help with this; I don't have any control over such matters. Have to ask a Super Moderator or Supervisor on this one!
-
-
Force Windows XP to treat signed and unsigned drivers equally?
LoneCrusader replied to LoneCrusader's topic in Windows XP
Luckily, someone uploaded a copy of it. Check the last few posts in the thread. But @Acheron also posted the patch bytes in the thread here at MSFN, which appears to be more helpful at the moment unless one needs the other things provided by the original package. Could be another way of approaching the issue. I hadn't thought about it that way, assuming that all paths to solve it would be similar. Based on un user's next post and an examination of that section in the registry it looks like one might get at the issue from that direction... I think that the approximate same result is achieved with one of the patches listed by Acheron; I tested them and while XP x86 still recognizes whether or not a driver is signed, it does not "prefer" one or the other on its own anymore, which solves the issue at hand. Now I just have to find someone with the know-how to port them to x64. Interesting.. is there any available documentation on this? And, I assume since you specified that it works only after setup is complete, that an attempt has been made to add these entries to the source files prior to setup? -
Force Windows XP to treat signed and unsigned drivers equally?
LoneCrusader replied to LoneCrusader's topic in Windows XP
Hmm.. looks like our Russian friends have already solved this issue long ago. Digging through an old RyanVM thread for information on Signing/Certificates inadvertently led me back around to here, and then to a thread on the OSZone Russian forum. Unfortunately I can't speak or read Russian, but a Google translate of paragraph #3 of post #10 refers to "Patch in Setupapi.dll, turning off the lowering of the rank of unsigned drivers when choosing the most suitable driver for the device." Now the problem is sorting out what patch does what exactly, and if there are any differences in different versions of the DLLs involved, and how to port it all to XP x64. All things I know nothing about. Fun! -
Force Windows XP to treat signed and unsigned drivers equally?
LoneCrusader replied to LoneCrusader's topic in Windows XP
Sure, they don't change anything. It's just a personal preference, hence why I said above that "need is subjective." But I prefer to have them installed, and it's all the more annoying that Windows refuses to do so, so I am therefore more determined to find a solution. -
Force Windows XP to treat signed and unsigned drivers equally?
LoneCrusader replied to LoneCrusader's topic in Windows XP
Yes, I know. I don't care whether they are signed or not. But Windows does. Setup refuses to use my specific-device-ID specific-name driver because it isn't signed, and uses its signed MACHINE.INF generic driver instead. As you see in the shots, I can manually force my driver to be used after Setup is done. But that defeats the purpose of having it slipstreamed. It also could theoretically cause problems in a situation where Windows has a generic driver pointed to a given installation routine, and you want to add a specific driver that points to a different installation routine. For example an IDE controller*.. MSHDC.INF will send anything matching PCI\CC_0101 to the generic IDE install routine. You might want to send PCI\VEN_8086&DEV_1C02 to an AHCI install routine with a specific driver INF. But Windows would choose the generic signed driver over your INF because yours isn't signed. *Intel avoids this particular situation because the storage controllers report different DEV ID's for different modes (IDE/AHCI/RAID) but not all manufacturers may do this. -
Force Windows XP to treat signed and unsigned drivers equally?
LoneCrusader replied to LoneCrusader's topic in Windows XP
Need is subjective.. lol. Chipset drivers usually don't "do" anything other than correctly name and prevent unknown devices/yellow bangs under the Device Manager. But installing them is one of the first tasks to be performed every time a new system is set up, so it is preferable to have them integrated and dispense with this task. Signed manufacturer files might be used somehow, but Intel insists on giving you over a hundred tiny INF and CAT files for a simple task that could be done with 3 files (1 for System Devices, 1 for USB controllers, 1 for Storage devices). And this fileset does not include any newer system devices that are "unsupported" for XP - for those you either make your own or hope XP can use the files provided for NT6x. At any rate, I tried using my compiled INF file under XP x86 along with the SETUPAPI.DLL patch. It did not have any effect on the problem, so that looks like a dead end. Still need a fixed SETUPAPI.DLL patch for x64 though, as it does help with the other things I mentioned in the other thread. Not sure if SYSSETUP.DLL patches would have any effect - there is no warning box or error box, etc. I already prevented those with the relevant registry entries. The system just silently prefers its signed, generic MACHINE.INF over my unsigned, specific INTELSYS.INF. See pics below; this is what I see when I examine the Device Manager entries for the devices after reaching the Desktop. Error/warning dialogs are not the issue. The problem is the silent preference for signed over unsigned, even if the signed driver is "generic." -
My apologies for the late testing.. every time I get a good start on a project of mine something happens to delay it. Unfortunately this patch doesn't seem to work, it triggers an endless loop at the beginning of the second phase of SETUP. The text part of SETUP completes, the system reboots and shows "Installing Windows" and "39 minutes remaining" - but it never loads the first dialog box to click to continue. After a few seconds the screen goes all light blue and the machine reboots. This repeats on each reboot. No error is displayed.
-
Force Windows XP to treat signed and unsigned drivers equally?
LoneCrusader replied to LoneCrusader's topic in Windows XP
Sounds promising. Tried using that just now, but I'm currently working on the x64 version of XP. Apparently the patch for the x64 version of SETUPAPI.DLL needs further work, it triggers an endless loop. Will elaborate further in that thread. I put this topic in the main XP section since I meant for it to apply to both x86/x64, but It may need moving to the x64 section later if divergent methods are necessary. -
Force Windows XP to treat signed and unsigned drivers equally?
LoneCrusader replied to LoneCrusader's topic in Windows XP
I've been told (and seen examples, i.e. Fernando's AHCI/RAID drivers) that one can self-sign files and/or obtain a certificate to do so, but I'm not sure that this method would necessarily work during a clean install, as "your" certificate would have to be imported and accepted as trusted prior to setup checking the files. Not saying it might not be possible, but I have no idea if it can be done in practice. I'm not aware of any way to "fix" a signature once it's been broken.. probably be hard information to find, even if it is possible, due to the possibility of using it for malicious purposes. Any of our "XP on Modern Hardware" gurus care to chime in on this? @Mov AX, 0xDEAD, @Dietmar, @George King, @pappyN4 -
Does anyone know if it is possible to force Windows XP (x86/x64) to treat signed and unsigned drivers equally, and not prefer a signed driver over an unsigned one? I know it is possible to disable signature enforcement and stop the warning popups and such, this is not what I need. I need Windows to stop automatically preferring a signed "generic" (device ClassCode [CC] INF entry) driver over an unsigned "specific" (device [VEN&DEV] INF entry) driver. I'm trying to manually slipstream motherboard chipset drivers into XP setup.. and the 250+ tiny INF and associated CAT files supplied by the OEM drive me nuts. So I decided to build a single compiled INF file, similar to what I did for my Windows 9x Chipset INFs. Which is fine, except that it is unsigned, while XP's MACHINE.INF is signed. So Setup refuses to use my INF for, say, the PCI-E Root Ports, because it has a generic Class Code entry for these in MACHINE.INF, and uses it with generic names. But it does pick up my INF for the SMBus controller and gives it its proper name, because no other driver matches it. This is maddening... Yes, I can manually force the use of the specific unsigned driver on the other devices through the device manager after the desktop is reached, but this defeats the purpose of having the driver slipstreamed to begin with. I can also edit MACHINE.INF with the new data and break its signature in the process.. but this leads to other dumb behavior, such as popups about "Terminal Server" device drivers during SETUP that require user interaction and break the unattended process.
-
+1 Have to disagree, XPx64 is in some ways the best of all worlds. It's been my actual daily driver for a long time now. Also, I can confirm the random crash on YouTube main page reported on GitHub on at least one of my machines (this machine is XP SP4 x86). All you have to do is go to the main page and "scroll down" for a while looking through what's available; sooner or later it will die. Haven't updated my XP x64 machine with the new build yet, but it's worth noting that several versions back I actually saw more crashes on the XP x86 machine than I did on the XP x64 machine. I don't remember them specifically now, they were fixed in a later build, but it was interesting that they did not happen under x64.