jaclaz

Or maybe you just fancy (not need) it. Loosely - and with a few exceptions - a new OS installed on an older machine will always be slower, in some cases VERY noticeably, and particularly with a not-so-great amount of RAM (though may other factors may concur with the added sluggishness of the system). If your PC was manufactured/built before 2008/2009 or so and came originally with Windows XP, surely it will be noticeably slower with Windows 7. jaclaz

Well, not entirely unexpected: http://arstechnica.com/tech-policy/2015/10/drone-slayer-cleared-of-charges-i-wish-this-had-never-happened/ I guess it has become a personal matter ... jaclaz

Good , in some cases the issue might be actually memory related, but with 4 Gb of RAM it is not possible. Clearly it is a resource limit of some kind, the "root" cause of similar errors has been reported in the past to be connected with the "driver packs" when they are "integrated", but this should be not your case since you use them as "external" resource. jaclaz

Of which we know nothing about. jaclaz

Just do it. jaclaz

Well, why don't you actually try clicking on the CORRECTED link? jaclaz

Not really-really plainly it means that you weren't able to find in that .dll you examined a reference to USER32.EnumDisplayMonitors. Writing a new driver. I am not sure you understand the way a .dll works. A .dll is nothing but a container with a number of fuctions inside. You can think of it as a number of small .exe files inside a .zip archive. What happens transparently when the .dll is in use. i.e. a function in it is called, is that the archive is opened, a single small executable is loaded into memory and executed and the archive is closed again. The issue here is that this archive is (besides read only) indexed/assembled in such a way that you cannot insert (add) in it anything, not even a single byte. You can normally replace the whole archive with a new version (including the added needed function), but this poses a problem, you need to re-write from scratch all the other functions besides the one you need and rebuild the whole archive or you need to find a function that is never used, that has a suitable name and size and manage to replace it with your new function, and fix checksums/indexes/etc.. This in the case of a "system .dll" such as USER32.DLL is in practice very, very difficult. The question is not really "what program", but rather "How/where can I learn how to edit a .dll" and the answer to this other question is "you study the windows OS in depth, including a bit of low-level (assembly) programming, a lot of reverse engineering and debugging, try and get familiar with each and every available related tool, you try hacking non-system .dll's first and after due time you will know what to do (and also which program to use or you write your own)". jaclaz

No , basically you need a custom Gina or "credential provider". Yep , though it is a "show-stopper" kind of problem and that is exactly the reason why you need a custom Gina or "credential provider", Q.E.D. An alternative might be a "Native NT" or "bootexecute" executable but if creating a custom GINA/credential provider wasn't complex enough, Native NT programs are possibly "worse". There is the pGINA project: http://pgina.org/ http://pgina.org/docs/v3.1/user.html but it's not something I would recommend without a deep knowledge and understanding of the involved matters. It's pretty much binary or you do something before having logged in ("right") or you do that after having logged in (wrong in this case of choosing between different login methods). You might find this of interest: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/windows-nt-6-boot-process.html jaclaz

Good, now I could suggest you to try the v6.1.3.35 AMD's "pure" AHCI Drivers (only AHCI mode supported) ones Fernando recommends: http://www.win-raid.com/t29f25-Recommended-AHCI-RAID-and-NVMe-Drivers.html and you will say how you already tried them and they don't work as well. jaclaz

WHERE? Post a link to what you have found. jaclaz

Well, and how exactly do you plan to execute it BEFORE the login? Under which credentials would the hypothetical script be run? In which Win station? My guess is that you have not entirely clear the whole NT logon processes, and what you really want/need is a custom GINA (up to XP/2003) or a custom "credential provider" (Vista and later). jaclaz

I am not sure to understand (actually I am pretty sure I do not understand ). Can you try explaining what is the actual scope/goal (or intended usage paradigm) and when this hta would be run? jaclaz

Try these ones: http://www.symantec.com/connect/downloads/amd-ahci-mass-storage-driver-windows-xp jaclaz

Well, it doesn't work that way. "Make sure that API call USER32.EnumDisplayMonitors is NOT present" does not mean "Make sure that API call USER32.EnumDisplayMonitors is NOT present, if it is just edit the .dll removing the call" and BTW Dependency Walker has NO editing capabilities. If you prefer what was described in the mentioned post was just a "diagnostic method", not a "cure". To expand a .dl_ file usually 7-zip will do nicely, if it doesn't try Universal Extractor. jaclaz

So, Windows 10 is more secure than previous Windows OS's. Too bad that it is the ONLY OS here: https://technet.microsoft.com/library/security/MS16-007 where 5 (five) items out of 6 are considered "important", whilst all the older OS's are affected by only one ... jaclaz

Ok, what is the pay/hours/location for each open position? Who exactly are the "I" and the "we"? jaclaz

Hmmm. Then, let's try another way, maybe you can "trick" the installer by using a AHK (AutoHotKey) or AutoIt or similar script to "virtually" click on the popup warnings? jaclaz

Sure and I did that by design (as I tested the behaviour with several different browsers, ultimately, before posting I made sure that the issue was on the board side). And yes , I can confirm that right now the given links that did fail to resolve previously, do resolve correctly with the same browsers. Whenever this board software is involved there is always some kind of unknown, unrepeatable, undocumented (or mis-documented) magic. jaclaz

Yep, my bad , corrected. jaclaz

To be fair, it is not a "particular trick" it is the intended use of the kernel and hal parameters. It would be a good idea to use a "universal" hal/kernel BOOT.INI, such as those represented here: http://www.vernalex.com/guides/sysprep/hal.shtml http://www.etherboot.org/wiki/appnotes/port_winnt_sanboot or (go to point #5 #6) here: http://www.911cd.net/forums//index.php?showtopic=23553 at least when experimenting (having a "way back" should something go wrong). jaclaz

Good . Now it has to be seen if after all this trouble, it actually works for your "automatic install"... jaclaz

Try just REMming out those two lines, i.e. putting a ; in front of them, and see what happens. More generally, what you need is to have the stupid .inf file be signed on your specific machine only, so you know (or should know) what VID/PID device "Generic Hub" (if any) you have... jaclaz

I am no too sure about this, but seemingly you are using a "different" usb.inf. The error you reported earlier: should not happen if you actually added (like you did in the file analyzed by chkinf): Though I doubt that the above is correct anyway. IF I recall correctly that should be: and W2kcd should be defined in the [strings] section. As I see it (but I may well be wrong) the good MS guys are playing the secret 7, see: http://homepage.ntlworld.com./jonathan.deboynepollard/Humour/microsoft-monopoly.html The original driver.cab and install relies on a directive "layoutfile" that points to layout.inf (and most probably *somewhere* they further rely on drvindex.inf) and Heaven only knows what other secret or undocumented syntax, while the chkinf and the inf2cat tools were released for "the rest of us" and accept a more limited set of "features", the "error" provided by chkinf: ; (E22.1.1004) Provider listed is Microsoft, but should be the organization who wrote this INF. makes it clear that only Microsoft can use the Microsoft name , by the same token it is probable that inf2cat has similar limitations and it is intended only for OEM's and limited to "self-standing" and "dedicated/specific" drivers, as evidenced by the error: I would try finding some simple third party (USB related) drivers and try modifying their .inf (adding the actual contents, VID/PIDs, etc. of the XP usb.inf) andd see how both chkinf and inf2cat behave with them. jaclaz

IMHO it would make more sense to find out why exactly the same floppy works fine in DOS but doesn't in 9x/Me. However, you may try to run Letter Assigner, see: http://www.msfn.org/board/topic/163405-slipstreamable-intel-chipset-inf-drivers/?p=1115060 cannot say if it will work for your specific needs, though. The driver for the PCMCIA should be (usually they are at least) configurable to another drive letter "internally", possibly to drive letter B, you may need to disable the internal floppy in BIOS to get letter A: available... jaclaz

Actually Android in itself is (as said before) a derivative from Linux and is nice in theory. In practice Google (and ALL the phone manufacturers) managed to make it the terrible, intrusive, ad-ridden madness you probably refer to. The (thank goodness retired) Microsoft (Nokia) version of Android, Nokia X : https://en.wikipedia.org/wiki/Nokia_X_platform was - if possible - even worse, sporting the look/UI of Windows Phone AND MS/Nokia services/crap instead of Google's ones (nonetheless crap): https://www.techmesto.com/avoid-nokia-x-xl/ jaclaz