jaclaz

Yep, it looks like a start Modifying the .inf may be tricky, AFAICU it is a win or lose situation, a teeny tiny error in the way it is edited and it won't work (without excluding that with a slightly different change it would work) . Post original and changed lines. jaclaz

What I would still try would be what happens with the Samsung "unified" drivers . Latest I could find is Touchpad_4.9.0.0.ZIP, it is 256 MB of pure bloat as it contains both the Synaptics and the Elantech drivers: https://www.helpjet.net/Fs-52207751-65343120-34459956.html The good news are that the various .exe's are 5/1 and the driver is up to Windows 8 (unfortunately not 8.1). IF (and it is a huge IF) the Windows 8 drivers can install on 8.1 , after modifying the .inf to (hopefully) install on ETD0108, than maybe (and it is still maybe) even if the ETD.SYS doesn't make it functional it would be possible to replace only the ETD.SYS (and the ETD.cat) with the version that has been already tested working on 8.1. And from that (again IF we manage to have it working on 8.1) it should be a breeze to port it back to XP. jaclaz

Yep, that is why I needed the winsetup.lst, it needs to be commented excluding the RDSK and other checks or, much better when experimenting NOT executed and replaced by manual commands (if they work they can be later reassembled in new, dedicated entries in winsetup.lst). Namely in the winsetup.lst the : root (hd%RDSK%,0) is fixed to first partition entry of %RDSK% while you only have a fourth partition entry on the UFD. The whole point is that WinsetupfromUSB provides an "automagical" way that works in most cases (but not on this specific motherboard) and we need to manually find a procedure that works and only later modify the .lst accordingly. I need to know the output of geometry (fd0) geometry (hd0) geometry (hd1) geometry (hd2) after you have run: map (fd0) (hd1) map --floppies=0 map --harddrives=2 map --hook usb --init Hopefully you should have only (hd0) as the internal disk and the UFD as (hd1) but even if you have the (fd0) and the (hd2) it is fine, as long as the internal disk is actually (hd0) and the UFD is the (hd1), the other devices are not used in the following. DO NOT run shiftd bat. then run: find --set-root /WINSETUP/XPpSP3.ISO root you should have as output: (hd1,3) then - still on command line - this is corresponding to the "title First part of Windows XP Professional SP3 setup from partition 0", executing these on command line you should see for most commands some feedback : ls /WINSETUP/XPpSP3.ISO map --mem /WINSETUP/XPpSP3.ISO (0xff) map --rehook root (0xff) root chainloader /I386/SETUPLDR.BIN boot Then (if everything above goes well) - this is corresponding to "title Second part of Windows XP Professional SP3 setup/Boot first internal disk": chainloader (hd0)+1 rootnoverify (hd0) boot jaclaz

Ok, this one is seemingly fine: together with the "internal" hard disk: Now try: map (fd0) (hd1) map --hook usb --init Though it seems to me like even without the manual remapping the mapping is correct (the internal disk remains first disk aka (hd0) and the stick is second disk aka (hd1), that is fine. It may be needed to also run: map --floppies=0 map --harddrives=2 before the "map --hook" You must NOT run the shiftd batch, that one is intended - in most common cases - to shift disks and if the device is seen as floppy it calls Plop. You cannot - generally speaking - root to (hd1), you can only establish root on a recognized volume. that would be in your case root (hd1,3). (normally the UFD is seen as boot hard disk, i.e . it becomes (hd0) and the internal hard disk is shifted to (hd1) the shiftd bat is intended to remap the dirves so that the internal becomes (hd0) - thus indirectly allowing the setup to install to the C:\ drive - and UFD is shifted back to (hd1)) Unless I am mistaken, the winsetup.lst is created when the tool is run (in the archive it is almost empty) so I need to see the one you are actually using. Maybe simpler, replace the shiftd.bat (make a copy) with this: !BAT echo This grub4dos batch does nothing pause jaclaz

Ok, forget the miniMBR, it is likely way too complex for now. The try with version 1.0 was just an attempt costing nothing. I am perplexed by the two partitions (and the specific way you have them) in some cases having two partitions (one hidden) is needed to have the USB stick recognized as hd device, but normally the first partition (hd0,0) is the "good" one and a "dummy" one cylinder partition (not formatted and with a hidden ID *like* 21) is added (RMPREPUSB uses this approach), but this is to somehow "force" the BIOS to recognize the stick as hard disk device, if with your setup it is still recognized as floppy I fon't see the utility of the double partition. Anyway, if you can boot from grub4dos, however the UFD is setup, that is fine. It is entirely possible that the shiftd grub4dos batch has an hiccup, but you should be able to manually remap the device(s). Can you post your current winsetup.lst (or whatever .lst you are executing)? Boot to the grub4dos prompt. Run: geometry (hd0) geometry (fd0) If needed repeat with (hd1) and post what you see. then run usb --init and repeat the geometry commands (they should have the same output), only post differences - if any. Basically, once you are booted, and if everything is seen by grub4dos, you can manually run *something like*: map (fd0) (hd1) map --hook and you should be in the "normal" situation where the internal hard disk is (hd0) and the UFD is (hd1), i.e. what the shiftd batch qould do if the UFD was from the beginning mapped to (hd0) and the internal disk as (hd1). jaclaz

the dud: http://www3.telus.net/_/dud/ jaclaz

Your thought has been duly recorded. What now? jaclaz

That BIOS you describe is very "queer". Technically a (real) ZIP drive is a partitioned device with a single partition entry in 4th partition slot (with a given CHS geometry of n/64/32 but that should be later ignored by the NT based OS, as long as PBR iis on sector 32). You might want to try this approach: http://reboot.pro/topic/12436-usbzipls120-booting-with-minimalist-mbr-code-and-grldr/ and verify that the UFD is bootable that way. I mean, it is possible that your hidden FAT16+FAT32 current formatting works for booting but creates other issues. About installing starting from DOS, there is a (now old. and if not deprecated at least not recommended anymore) approach that keeps Windows drive letter C:, BUT the install is first done on FAT32 and later the volume is converted to NTFS: https://web.archive.org/web/20100329105739/http://www.911cd.net/forums//index.php?showtopic=16713 Back to the specific WinntsetupfromUSB: 1) which version are you currently using? 2) have you tried one of the earliest versions (they were "simpler") with the same results? < if not try the WinSetupFromUSB 1.0 jaclaz

Well, if the Asus driver works, it has to be seen the structure of Registry settings you have on 8.1, replicate them on XP and see if the driver "catches" them. In the case of Elantech, all in all it seems to me like the results of the (many) experiments lead to believe that: 1) one thing is changing the settings (using the ELAN "mouse" tab or the Dell touchpad) and another is: 2) have the driver "read" these settings, which seemingly happen in both cases ONLY by having running in the background the ETDctrl.EXE No idea whether the Asus driver is "self-standing" or needs as well a background running service. jaclaz Note for later: Being optimistic , I still believe that *somehow* it is possible to have a FrankenInstall of the Elantech drivers picking and editing (carefully) bits and pieces from various versions, point revolves more around what amount of editing/patching/esperimenting is needed.

I am getting older and forgetful , it is not there in a default install of XP "automatically", you need to invoke it using "Windows+U" (if the keyboard works "enough" for that) so not really possible in your case, Otherwise you need to set it up to run it in: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\Cu rrentVersion\Winlogon\System Which again doesn't apply if you cannot log in, maybe from the other 8.1 install in your case. Forget about it, a senile moment. What could work might be an external USB keyboard. jaclaz

jaclaz

Only as a side note, with a USB mouse you should be able to invoke the OSK (on screen keyboard) on the login screen. jaclaz

Good, so we can now exclude that the data in the optional header of the .sys is relevant for XP compatibility. At this point - once you will have tested the 8.2.0.35 - it is probably the case of finding a later driver that works for the ETD0108 on a later system (I lost count, what do you have on 8.1 - apart the Asus software - also an Elantech driver that works)? jaclaz

Good (bad). Try to restore the value with CFF explorer (on the installed ETD.SYS) and reboot/disable/restart the device. What happens? It is possible that you need to correct the PE checksum (or something else) to have the system accept the edit? jaclaz

Next test. Use the 10.0.0.20, (with the modified .inf with the ETD0108 added) BUT try editing the .sys with CFF explorer so that the MajorSubsystemVersion to 5. To recap, this 7.0.5.5 version has; MajorOperatingSystemVersion:0006 MinorOperatingSystemVersion:0000 MajorImageVersion:0006 MinorImageVersion:0000 MajorSubsystemVersion:0005 MinorSubsystemVersion:0001 and *somehow* it works (without working touchpad). While the 10.0.0.20 has: MajorOperatingSystemVersion:0006 MinorOperatingSystemVersion:0001 MajorImageVersion:0006 MinorImageVersion:0001 MajorSubsystemVersion:0006 <- the test is with only this one changed to 0005 MinorSubsystemVersion:0001 and it works (and it doesn't) in different ways. No idea if it will make any difference. Before that, while you have the 7.0.5.5 still installed, what happens running the DellTpad.exe? jaclaz

As a side note, there is an "unified" Samsung driver (allegedly) for XP, with .sys version 10.0.0.100 that has as well 6/1; https://drivers.softpedia.com/get/KEYBOARD-and-MOUSE/Elantech/Samsung-RV515-Elantech-Synaptics-Touchpad-Driver-4100-for-XP.shtml and an earlier one https://drivers.softpedia.com/get/KEYBOARD-and-MOUSE/Elantech/Samsung-NP530U3C-A05US-Elantech-Touchpad-Driver-3900-for-XP.shtml with .sys version 10.0.0.72, also 6/1. Now the (good?) news. This one 7.0.5.4 has at least (the major/minor subsystem 5/1) https://www.hwdrivers.com/drivers/012725 And here is definitely an XP driver (DELL) version 7.0.4.9 https://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverid=mhw9f&oscode=ww1&productcode=inspiron-mini10&lwp=rt that has as well the major/minor subsystem 5/1 7.0.5.5: https://drivers.eu/m8N2j is still subsystem 5/1 7.0.5.8 (.sys) or 7.0.5.9: https://www.techspot.com/drivers/driver/file/information/13154/ has (already) subsystem 6/0 jaclaz

I thin we need some more (better) opinions on this matter. (cdob, where are you?) I am starting to believe that the .sys having 6/0 or 6/1 in the optional header means that it is not XP compatible, and that the beginning on the .inf where XP is stated is misleading and a remnant of previous drivers/versions. It is "queer" as the OS should throw a fit instead of installing such a .sys. I found a 10.0.0.24 where the DellTpad.exe is 10.0.0.3 and the major/minor is 5/2 http://freedriver.org/drivers/notebook.php?n_firm=Asus&driver=007623.rar&n_model=K46CM As said earlier, it is a big, huge mess. On the other hand, I found on microsoft update: https://www.catalog.update.microsoft.com/Search.aspx?q=touchpad elan a couple of ELAN Dell Drivers version 0.0.0.0. dated 12/31/1899 (no they do not apply directly to this case as they are "Vista/7/8/8.1/10" and duly marked by MS as "Windows 10 and later drivers" ), that should tell us something about the reliability of versions, dates and compatibility one can find. jaclaz

Yep, maybe it is important, maybe it is not, cannot say. I find more interesting that *somehow* it decided to install the driver as the "generic" ETD0101. Now we have something to compare with trying again but with the ,inf (actually I believe both the .inf and the .infdrp) modified to use the ETD0105 with a hardware id of ETD0108. Anyway, only to state the contrary of what I just said, the actual ETD.sys version 10.0.0.20 has - as seen in CFF explorer - Major/Minor 6/1, so either: 1) the setting is incorrect (and one could try to set it to 5/1) 2) that setting is ignored/irrelevant And to further complicate the matter I found here (the file on sendspace version 11.8.19.3 is MIA, but the one version 11.8.20.3 on Softpedia is still there) http://forum.notebookreview.com/threads/installing-updated-elan-track-pad-drivers-for-y510p.751866/ some (I am afraid rather indirect) evidence that - at least these Toshiba drivers - are XP compatible, but it is not at all clear (I don't think they can work as they have completely different hardware ID in the .inf, still the Toshiba touchpad has Major/Minor 4/0 and is .NET ) As I said it is a mess. jaclaz

That is part of what I find "queer", maybe it is simply a difference in your setup (with the driver and all the other files installed) and my test (without them). Here in Regmon, set to monitor only DellT*,* and excluding explorer.exe it looks like it accesses the Registry directly., or it is possble that the EDTctrl.exe running in the background (automatically started at boot) makes a difference. I am attaching a regmon.log of what I see here. (BTW for *some* reasons using the DellTpad.exe automatically, sometimes, changes the settings for the external USB mouse swapping buttons) Still what needs to be traced on your system is the actual ETD.SYS, to see if it accesses the Registry to "read" the settings. That surely looks like another promising path. BUT: 1) the driver is (CFF explorer) Major/Minor 6/1 2) in the ,inf the hardware ID's are different (not any ETD01xx) Maybe there is some driver *near* version still XP compatible AND with the right hardware ID, but it is really a huge mess. I don't know, however that ETD.sys driver is 10.0.0.20 (169.256 byte), maybe all this time we were talking of two different files? jaclaz RegmonDellTpad.log

Naah, don't worry, noone is accusing you of doing (or failing to do) anything . As said I understand how each and every suggestion here - expecially mines - are more *semi-random* thoughts than real, exact advice, and as such are difficult to follow. The only one I provided with some *exact* data/behaviour for *some reasons* didn't pass through or was botched by *something else*. I asked you to confirm the behaviour of a specific file, DellTpad.exe, and *for whatever reasons* you ended up runnning and tracing ETDctrl.exe (which again I doubt is the same file, misteriously renamed by the install). The key point - completely speculative BTW - is that the ASUS driver .inf file for laters systems uses the same entry/install for BOTH ETD0105 and ETD108, so logically an ELAN driver which "covers" ETD105 might also work for ETD108 while anyone without support for ETD105 is unlikely to support ETD108. jaclaz

That is actually the *only* thing that is clear enough IMHO: [ETD0105_Inst] Include=msmouse.inf Needs=PS2_Inst Even if I cannot do further testing, the DELL touchpad utility seemingly works here, meaning that it actually attempts to connect to the Registry, actually reads and saves settings in the "right" places, the file is called (and remains called) DellTpad.exe, in the given driver folder, it is 5.728.552 bytes in size and I cannot imagine that *any* install will rename it to ETDCtrl.exe (which also exist in that folder and that is 1.994.536 bytes in size). The point remains if/when the actual driver reads the Registry settings (and which ones) and this can only be determined - maybe - by tracing its behaviour with regmon or similar, and - even if it is hard to use this adverb in this context - logically this applies to the ETD.sys which is in the same driver package, i.e. version 10.0.0.20. jaclaz

I think you haven't (yet) done any of the checkings suggested, and possibly - or at least it seems so - your current installation is far too "botched" by the various installs that you cannot (seriously) state anything definitive about the status of the driver. At least - before giving up - you could try to: 1) go to device manager 2) find the actual hardware involved 3) try to update the driver (this one), possibly expand it to a new directory: using the modified .inf as per: https://msfn.org/board/topic/181362-xp-driver-for-amd-hd8180-graphics-and-elan-ps2-touchpad/?do=findComment&comment=1180077 directly from device manager, it should throw a fit/error or actually connect it to the ETD.SYS. If it does install *something else* find where it comes form, delete it and repeat. I understand how it is difficult to follow *vague* hints, but I think you tried (completely/exactly) more or less 1/3 of what was suggested (by me and other willing members), of course there are no problems if you feel it is time to give up, sad as it might be . jaclaz

>Kind regards, I hope I helped / conveyed an important message. I wonder what actual importance your message: has. Maybe a relevant anecdotal importance. ONly for the record LTSC is a version of windows (Enterprise ONLY) that is not normally available outside large corporations that have Volume License agreements with MS, and has - last time I checked - a non-trivial cost per license. On other news, my Aston Martin Vanquish handles much better than most Fiat Panda's I see around ... jaclaz

Yep, I guess that doing all these tests managed to leave behind some "cruft". It can also be that the ETD.sys is loaded but not "connected" to any hardware, try looking for it in device manager, or possibly try using devcon: https://www.robvanderwoude.com/devcon.php get it from here: It would be the case to thoroughly examine the system and uninstall/delete anything that may be connected with the touchpad or maye even better, and as it was already suggested earlier, to make a (temporary) new, fresh install of XP. jaclaz

Yes and no, meaning that is possible to use grub4dos to boot from a FAT12/16/32 image (that can reside on NTFS). Whether any of the NTFS drivers is "low-level" enough to then be able to boot 9x/Me, is another thing. jaclaz