jaclaz

Well, now is just about time to try a transplant. Make three directories: 1) \Samsung10 2) \Frankendriver1011 3) \Asus11 Copy to \Samsung10\ the contents of \Touchpad_4.9.0.0.ZIP\Elan\X86\ Copy again to \Frankendriver1011\ the contents of \Touchpad_4.9.0.0.ZIP\Elan\X86\ Copy to \Asus11\ the contents of \20755834_3604917b6f0540c8262602489fffab4fff64986a.cab\ Now "merge" the contents of \Asus11\ to \Frankendriver1011\, i.e. copy to \Frankendriver1011\ all files in \Asus11\ that do not already exist in \Frankendriver1011\ (do not overwrite any file). Copy (overwriting) from \Asus11\ only the ETD.cat, ETD.sys and ETD.inf to \Frankendriver1011\. Try installing from \Frankendriver1011\ jaclaz

Who knows? I don't think it will, but a "transplant" of files between this and the Samsung seem more likely to be possible. I mean, the structure of files is very similar to the ones in the "Samsung 4.9.0.0" driver (same .exe's and .dll's) AND the .inf file is "correct" for your hardware. Besides - not that it is useful in any way - the AsusUI.exe does run in XP. Can you try extracting from the Samsung the ETDsimpleui.exe and the ETDsimpleUI_win8.exe and try running them while this driver is installed? And try the same with the DellTouchpad.exe seen earlier. jaclaz

And then your best bet is (back to the past) DMDE. Which can create a virtual filesystem and/or re-index specific filetypes, and unlike photorec, allows to copy/extract only a selection (but of course it will need to analyze the "whole drive"). https://dmde.com/manual/datarecovery.html Get the latest version: https://dmde.com/download.html jaclaz

Side note. One of the n drivers on MS windows update: http://download.windowsupdate.com/d/msdownload/update/driver/drvs/2015/09/20755834_3604917b6f0540c8262602489fffab4fff64986a.cab Is actually an "Asus" one AND it contains the hardware ID ETD0108 in the .inf (and provisions for Windows 8.1). Data in the .inf: DriverDate = "07/20/2015" DriverVersion = "11.5.20.3" The "structure" of the files is more similar to the one in the Samsung 4.9.0.0 than to the one in the "good" 15 version. Maybe it is worth a shot. jaclaz

Sure, that (the version 15) does not include the ETD0108 hardware ID, AND - besides the .inf - there are also in the package: 1) SETUP.EXE in the "top level" 2) SETUP.EXE (different) in \x86\ 3) \x86\ETDSetup.ini (that may or may not be used by EITHER the SETUP.EXE in the "top level" OR by the SETUP.EXE in \x86\ (or by both) that contains a number of hardware ID's 4) \x86\Setup.ini that contains: [Setup_Config] CheckHWID=1 ResetPreviousRegistry=1 that as well may be used by the one, or the other or by both or by none. On the other hand, the 4.9.0.0 contains: 1) SETUP.EXE in \Elan\ folder 2) SETUP.EXE in \Elan\x86 3) NO \x86\ETDSetup.ini 4) \x86\Setupini with contents: [Setup_Config] CheckHWID=0 CheckMode=1 String1= String2= String3= String4= String5= String6= String7= String8= String9= String10= String11= String12= String13= String14= String15= String16= String17= String18= String19= String20= String21= String22= String23= String24= String25= ResetPreviousRegistry=1 It is possible that the CheckHWID value and/or the CheckMode value (or neither, or both) changes the way the one (or the other) SETUP.EXE behave. And the ETDSetup.ini may (or may not) bypass or change the behaviour no matter the contents of the ETD.inf file. If - from a "clean" system, the installation is successful ONLY from device manager "have disk" then it may be OK, but if a "prerequisite" is to run either of the setup.exe, then *something* happens when the setup.exe is run that you haven't noticed. jaclaz

What you report does not seem in any way connected to encryption. It looks more like a filesystem or disk driver issue (of unknown origin). The SSD is SATA, right? Are you using it in IDE compatibility mode or do you have a SATA driver? How are partitions aligned? jaclaz

In your specific case (32 bit system, internet browsing with a memory hungry browser) you have IMHO nothing (or very little) to loose even with the PAE patch, but as said AFAIK it is a hit and miss, it is possible that it will work just fine (and no, I have no idea on which of the three or four versions floating around is "better", most probably you will need to just try them) and as well it is possible it will result in a highly unstable system (BSOD daily or more often), no way that I know to tell what will happen in advance. As well, again in your specific usage case, making a Ramdisk in the "inaccessible" memory area and putting a pagefile on it (fixed size, please) might not be a bad idea, even if (compare with): https://sourceforge.net/p/imdisk-toolkit/discussion/general/thread/2aa6a11a/ it won't run as fast as "real" available RAM, it will still be better than your current situation and it is "stable". The "least intrusive" I was referring to using simply the available "excess" memory through the ramdisk to have (fastish) "volatile" storage for temporary files, this is a tested and reliable setup, but of course it doesn't make much sense to have roughly 5 GB (out of the 8 GB) of such storage, it may be good with a total of 4 GB where you would have some 500-800 MB available for this use. If I were you, I would try first the Gavotte ramdisk (with a fixed size pagefile and oprionally temp files on it) with the "whole" 8 GB, and - only if you find the result not satisfying, then - and only then - go for the PAE patch. jaclaz

That is the whole point. There is (seemingly) no reason why the ETD.sys shouldn't work on XP, but what your experiments evidenced is that the "driver" is a more complex subsystem of the .sys + a number of .exe's (at the very least, but not only, the ETDctrl.exe running in the background + a number of supported .dll's. Now, the .exe's and .dll's in the Samsung 4.9.0.0 file are already marked 5/1 so they are surely XP compatible whilst most of the later versions are targeted to either 6/0 or 6/1. So the problem is now about can the XP compatible files "talk" to the "good" version 15 of ETD.sys? And/or can some of the files in the "good" 15 version of the driver be modified to run under XP? BUT there are still a number of IMHO "preliminary" unresolved questions. I can see no reasons why the "good", "working" version 15 driver cannot be modified to install "normally" on 8.1 (if not via TouchpadSetup.exe which may include an hardcoded list of hardware ID's) at least via the setup in the Elan folder. (something is clearly escaping us in the .inf modifying), still if *somehow* the driver can be installed via "device manager - have disk" it might be enough. Then which files are actually *needed*? It is likely that a number of files (as an example those connected with the control panel) are not *strictly needed* if there is an alternative way to change the settings (say the simpleUI.exe or the DellTiuchpad.exe) or even if only changes directly made to the Registry are "taken" by the driver. So - not that I have some good, practical, advice - in theory the steps are: 1) find (if possible) a suitable and repeatable procedure to uninstall completely the driver 2) find (if possible) a more "normal" way to install the driver (though as said if it is confirmed that "forcing it via device manager it works it might be enough) 3) find whether some of the files can be alltogether taken out of the driver install (or if you prefer, what other files except ETD.inf, ETD.cat, ETD.sys and ETDctrl.exe are actually *needed*) 4) once (if) we can reduce the number of involved files to the sheer minimum, then the test would be either replacing them with an earlier version or - if possible - have them run under XP via major/minor OS/Subsystem modifications (or other, maybe changing a .dll call, using a kernel extension, etc.). jaclaz

Well, transplanting the .exe without the corresponding .dll's is anyway very, very unlikely to work. Each .exe needs to be traced, and see if it calls some function in this or that .dll, that actually exist in the specific .dll, etc. jaclaz

Only for the record, generally speaking putting the pagefile in a ram disk makes little or no sense whatever. Actual link to Mark Russinovich's take on the matter: http://www.overclock.net/t/1193401/why-it-is-bad-to-store-the-page-file-on-a-ram-disk The usage of otherwise inaccessible RAM is a particular case where it may make some sense, but it remains (IMHO) not particularly valid, as the pagefile with a 3 or 3.2 GB of normally accessible RAM is rarely enough hit in normal operation. The least intrusive approach is using Gavotte's Ramdisk for *temp* directories, and similar (but I believe you can put a pagefile on it if you really-really want to). About a) it is not really a good idea due to the instability that may well come from it [1]. The good MS guys disabled PAE in XP while they kept it in Server 2003 and the reason was that they found a number of third party drivers that had issues, whilst - again according to them - hardware used on 2003 Server tended to be bettr wuality and have better drivers. The reported experiences (with this or that patch) is often a reduced stability of the system, though there are reports that signal no issues whatsoever, my personal opinion is that it greatly (entirely) depends on the actual hardware involved (and the related drivers), so it is a matter of "luck" more than anything else. jaclaz [1] if reliability is an issue, I mean, if - say - you largely use the PC to browse internet with one of the basilisk releases (that tend to use a lot of RAM) you won't have any inconvenience if - say - once a week you get a BSOD.

What happens with the ETDSimpleUI.exe ETDSimpleUI_Win8.exe they should be the tool to change settings, aren't they? jaclaz

On second thought. You could set aside WinsetupfromUSB and try this approach: A good winvblock image was provided by Ilko: The difference is that (normally) the USB (boot disk) becomes (hd0) and shifts the internal disk to (hd1), hence the need in menu.lt to exchange/remap them, Since in your case the usb --init should result already as (hd1) there is no need for that. So it should become: title 1 Start Windows XP setup usb --init pause find --set-root --devices=h /winvblock.ima root pause map /winvblock.ima (fd0) map /winvblock.ima (fd1) map /Inst/XPpSP3.ISO (0xff) map --hook chainloader (0xff) title 2 Continue Windows XP setup usb --init pause find --set-root --devices=h /winvblock.ima root pause map /winvblock.ima (fd0) map /winvblock.ima (fd1) map /Inst/XPpSP3.ISO (0xff) map --hook chainloader (hd0)+1 jaclaz

Wait a minute. I was talking of this situation: That is seemingly partitoned (partially) as a ZIP drive: Only one entry in the 4th slot, covering the whole device. This one is another device (and partitoned "normally" with the partition in first slot): As long as it boots from it, it is fine, but it is not the same thing we were talking about before and it doesn't look as a ZIP at all. Anyway, this is OK: Now, when you run (WITHOUT mapping (fd0) to (hd1)) usb --init it should produce (hd1) (or drive 0x81) and go on as before, it should do the same as before but with (hd1): Only this time, the multi(0)disk(0)rdisk(1)partition(1) should be correct. From then on, the issues seem to be in the actual Windows XP setup jaclaz

That is a problem. As I see it, it means that the modification to the .inf is not correct (or that the touchpadsetup.exe has those ETDB00x device ID's hardcoded somewhere else). This makes little sense. it may mean again that the .inf "is wrong" or that it is missing something. But is the driver actually loaded ETD.SYS? Is the ETDCtrl.exe running? etc. I mean, it is well possible that the driver (the actual .sys) is running (as it is when you install the working (15.14.4.1) version untouched) BUT that all the rest (ETDctrl.exe, etc. ) do not communicate with it (as it happened when you installed the "samsung" driver "as is") , but what you are reporting now is that all the rest is now not installed at all. Try again, removing the semicolon in front of (two instances): ;%SamsungDeviceDesc% = ETD0B00_Inst_Win8, *PNP0F13,*PNP0F0E,*PNP0F03,*PNP0F12,*PNP0F0B jacla

Yep, the modifications seem fine to me. But the test would be, now that the inf is modified, if the driver installs "normally" via TouchpadSetup.exe. (or maybe - no idea - the mod in the .inf is enough to trigger some other error). Next attempt is: 1) copy the ETD.SYS and ETD.CAT from the version that works (15.14.4.1) to the directory where you have the (11.7.5.5) i.e. the Samsung 4.9.0.0, overwriting the existing files 2) try again reinstalling, via TouchpadSetup.exe and/or from the setup in the Elan folder. 3) try again "forcing" the driver from "have disk" of the device. 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