jaclaz

JFYI, you can use a F6 floppy without a floppy drive by using a floppy image and grub4dos (or syslinux) when booting. https://msfn.org/board/topic/179566-getting-sata-mode-to-work-during-and-after-xp-install/ Please try again and report the EXACT error you get, it may come from either the BIOS or from the MBR or PBR on disk (I am assuming that it is white on black background, not a BSOD white on blue background). jaclaz

Not that I know of, unfortunately. The problem AFAICU with such an editor isn't in the editor itself (after all you can already edit on-the-fly menu.lst entries, even inserting or deleting lines) but rather with saving it as file. The good news are that grub4dos in itself doesn't "lock" volumes, while - say - VirtualBox does lock it, BUT IF before starting VirtualBox you mount a floppy image in IMDISK, the floppy won't be "locked" by IMDISK, so you can have the floppy mounted (by IMDISK) to a drive letter in the "external" Windows that is also inserted as media in the VirtualBox VM. I.e. you can edit a given .g4b on the floppy image with - say - Notepad in Windows and saves are (instantly) taken in the running VM and can be executed by grub4dos without rebooting. About the extension, though it is easy to add the extension to the command, remember that grub4dos has [TAB] autocompletion, thus typing: /<a couple of initial letters of the batch filename>[TAB] is very handy. jaclaz

It is a complex matter. SSD's usually have a Physical sector size of 4096 bytes, a page size that can be anything between 4096, 8192, 16384 bytes or more and normally expose 512 bytes logical size sectors (otherwise they wouldn't be bootable in a number of OS with BIOS/MBR). In theory having a non-aligned to 4096 bytes partiton should make no difference (if not an unnoticeable slower access, particularly on write operations) but it is usually used a larger number of unused sectors, typically 2048, and many tools call this "MB alignment" or similar as 2048*512=1.048576 bytes or 1 MB, this has also the advantage to be surely a multiple of the page size, even if it is huge (and this tends - together with the correct alignment - to reduce the wear on the device, besides allowing faster operations). In practice there may be issues with oldish Operating Systems or their drivers. The first sector of any device is ALWAYS LBA0. The first sector of the partitioned space is (was) normally 63 up to XP and - since Vista - normally 2048 is used. The 64 offset is a rare case that was used on some hard disks by the manufacturer tools, there were even hard disks that had a physical switch to make sector 63 bneing actually mapped to sector 64 for compatibility reasons with XP and earlier. There are tools by the manufacturer for SSD's that offer encryption that allow it to be activated, I don't know of any commercial, user level SSD that is encrypted in factory. The 4096 bytes cluster size is fine, particularly on NTFS, where the volume contents offset is 0 with respect to the partition (in NTFS *everything* is a file). WIth FAT16/32/exFAT, it is preferrable - though not *needed* to make special attention with the filesystem, making it so that - besides the partition - the actual volume contents (past reserved sectors and FAT's) is actually also aligned, on SSD like on any other flash/chip based storage device. jaclaz

And: jaclaz

Bummer! In the meantime I found the Dragon's Lair in a japanese FTP site which - hopefully - might allow another (different) Frankendriver mishmash. I will throw these on the table (and quickly hide my hand behind my back ), around 140/150 MB each They are very, very near to each other, and "surely" the actual .exe's and .dll's in the first two "must be" XP compatible. Additionally, they include a batch that runs the setup.exe with a .log, which may be of use. But let's first try the original Frankendriver experiment. jaclaz

Yep, only FYI: http://reboot.pro/topic/18644-grub4dos-batch-file-extension/ particularly: http://reboot.pro/topic/18644-grub4dos-batch-file-extension/?p=178627 i.e., if I recall correctly, both /copyFF.bat or copyFF.g4b should work, as the initial !BAT is parsed and means "executable batch", while if the command --set-ext is set properly, also /copyFF and copyFF will work jaclaz

The ETDCtrlHelper.exe is 5/1, so - in theory - it should run in XP, it is possible that the error you have is due to the attempt to run it manually, cannot say. Someone more familiar with XP dll's may be able to confirm or deny, and maybe it does exist a "user33.dll" with that function added. You should try this "11.5.0.9" on the 8.1, in order to be able to compare (maybe it works there, maybe it doesn't even there). Try the other approach (Frankendriver1011). jaclaz

Then *any* will do. You can have a motherboard with support to a CPU that "includes" a GPU (a graphic processor unit), this is what is common, or have a motherboard which includes an embedded graphic card with a separate GPU, not unlike a video card, only soldered to the motherboard (these tend to be rare nowadays). As a matter of fact, if you don' t need particular speed of the CPU (it depends on your use), you could get away with an "embedded CPU" (and fanless) motherboard, saving quite a bit of money when compared to buying the motherboard+ the CPU + heatsink/fan, only as examples: https://www.asrock.com/mb/Intel/Q1900M/ https://www.gigabyte.com/Motherboard/GA-IMB1900N-rev-10/sp#sp jaclaz

New post as I have (maybe) *BREAKING NEWS* Till now we had: SAMSUNG (in the .inf) 11.7.5.5 10/08/2012 actual.sys 10.0.0.197 ASUS (in the .inf) 11.5.20.3 07/20/2015 actual.sys 11.165.5.11 Here is one driver: https://drivers.softpedia.com/get/KEYBOARD-and-MOUSE/Elantech/ASUS-Elantech-Touchpad-Driver-11509.shtml That is very similar to the "Samsung" driver, as it has: DriverDate = "07/29/2012" DriverVersion = "11.5.0.9" actual .sys 10.0.0.164 AND that has the ETD0108 among the compatible hardware in the .inf: AND has the ETDctrl.exe with 5/1 BUT that is also very similar to the "Asus" one, as it has both the AsusUI.exe and the AsusUI_win8.exe (but not the AsusUI_win10.exe) As such - in theory - it should install BOTH under 8/8.1 and XP. jaclaz

Very good news, In the comments to the original copyff.bat Steve mentioned that there were issues with "huge" number of files, it is very possible that you found how to avoid it. Indirectly, that report provides however a valid "test", if your modified copying batch can copy the XP CD's /I386 folder in an XP ISO, you have solved a long standing issue , (though it is also possible that at the time the limitation was another one linked to the grub4dos version, but I doubt it). 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