jaclaz

The point I was trying to make is that the Asus_UI.exe (which *somehow* runs on my XP, and that will surely run on your XP), MISSES a huge number of possible settings, among them - seemingly - the one you want to change (TapEnable). jaclaz

Good (meaning bad) so, since the Asus_UI_Win8.exe has not a provision (that I could see) to change the setting you want to change, you will need to edit the Registry. jaclaz

Maybe it is that small read thingy in the middle of the keyboard that you often find in IBM/Lenovo laptops? jaclaz

DO BEFORE THAT answer the question AND try the DellTouchpad.exe on this install. jaclaz

Good. Now - your choice - you can try directly installing this "as is" on XP (this is a shortcut, but if it works, it works). Before that, answer Question #1: AND try the DellTouchPad.exe (which is seemingly self standing AND surely works in XP) and see if it can make the changes AND if the changes are remembered/are effective in the touchpad behaviour. Sure it is, it is probably the last *all elantech* driver for ASUS hardware (ETD0108) before ASUS finished ruining the stupid software with their fork. See: https://www.asus.com/support/FAQ/1009643/ Now, please , STOP §@ç#ing calling things with their "screen name" (that noone but you can see), the "control panel" is EITHER ASUS_UI.exe/ASUS_UI_Win8.exe or SOME OTHER file, what matters is the actual file that is in use, not the "screen name". jaclaz

Ok, let's see if we can re-cap. The "main" three drivers are: Z11509 source: http://ftp.tekwind.co.jp/pub/asustw/nb/Drivers/Touchpad/Touchpad_Elantech_Win7_32_Z11509.zip Z11521 source: http://ftp.tekwind.co.jp/pub/asustw/nb/Drivers/Touchpad/Touchpad_Elantech_Win7_32_Z11521.zip Z115203-cab source: http://download.windowsupdate.com/d/msdownload/update/driver/drvs/2015/09/20755834_3604917b6f0540c8262602489fffab4fff64986a.cab In theory I can see no reason why the Z11509 or the Z11521 shouldn't install on 8.1, as they both have the ETD0108 as "ETD_STD_Inst" AND they have a NTx86.6.2 provision (that though aimed to Windows 8 should be good as well for 8.1 ), in practice they do not work in 8.1. Still in theory these two should also - at first sight - install on XP. The Z115203-cab on the other hand is the one (and only) driver of the "11" series that installed on 8.1 (but NOT on XP). As a matter of fact in this latter there are a number of .exe's and .dll's that have Major/Minor OS/Subsystem 6.0 (and not 5.1 as the two former ones). As always there is a chance that the 6.0 is "artificially" introduced by a new version of the compiler, i.e. the actual code can work in 5.1 but has been "tagged" 6.0 onwards by the default settings of the compiler. If this is the case, changing the OS/subsystem version to 5.1 may have them installed on XP, otherwise, it is again the case of attempting a new Frankendriver, replacing in the Z115203-cab the relevant files coming from Z11521. I do not know a fast/easy method to understand if these .dll's/.exe's make any call to post-XP functions in System .dll's. Check the attached spreadsheet. The First_compare is an incomplete initial attempt, ignore it. The Second_compare is a comparison of the actual "main files" (excluding .avi, .ttf, ,tx_, etc.), that is the relevant info. Proposed approach: a. change all the 6.0 in Z115203-cab to 5.1 via CFF explorer (of course make a copy, etc.) b. attempt installing the modified Z115203-cab on 8.1 <- the only sensible way is - I believe - via Device Manager "Have disk" forcing the install c. see if it works (it should) Questions: 1) what (the heck) is Sensepoint.exe? 2) what files are not actually used in the operation of the driver/touchpad (and that can thus be removed from the .inf, together with the .avi, the .ttf and the .tx_)? You need to trace in detail the behaviour of the driver, via Filemon, Regmon, Procmon, Dependency Walker, etc. Next step: d. uninstall (in 8.1) e. remove from the .inf the lines that are not connected to ETD0108 and the lines connected to the .avi, .ttf and tx_) and remove the corresponding files from the driver source folder f. attempt re-installing g. if it works, remove the .exe's and .dll's that are not *needed* from the .inf and from the source folder h. repeat, uninstall and reinstall until you have the least possible number of files in the source and the smaller possible .inf i. when you are convinced that you cannot shrink further the source, try installing on the XP. jaclaz

Oh, yes, you are right, the volume order may be different from partition order. jaclaz

No, keep for the moment all the files that you have downloaded they may come handy (or you may need to re-download them). jaclaz

I believe that the "ASUS Smart gesture" way is the "wrong" one, as it seems from all the evidence that the good ASUS guys took the already somehow botched code from the Elantech good guys and managed to worsen it (not very easy to do, I might say). I think that the "correct" (hopefully) start point should be the "ASUS" (but actually Elantech) driver: ASUS (in the .inf) 11.5.20.3 07/20/2015 actual.sys 11.165.5.11 from the MS update catalog. This one: https://msfn.org/board/topic/181362-xp-driver-for-amd-hd8180-graphics-and-elan-ps2-touchpad/?do=findComment&comment=1180923 Unless I lost something in the various attempts, this one works just fine in 8.1 but the .exe/.dll's have troubles on XP. The Frankendriver created with that and the "SAMSUNG" base, failed. Next would be another Frankendriver, still with the above .sys/.cat/inf but with the "11.5.09", this one: DriverDate = "07/29/2012" DriverVersion = "11.5.0.9" actual .sys 10.0.0.164 https://msfn.org/board/topic/181362-xp-driver-for-amd-hd8180-graphics-and-elan-ps2-touchpad/?do=findComment&comment=1180979 as "base", which should be the same as: http://ftp.tekwind.co.jp/pub/asustw/nb/Drivers/Touchpad/Touchpad_Elantech_Win7_32_Z11509.zip And we also have the "very near": http://ftp.tekwind.co.jp/pub/asustw/nb/Drivers/Touchpad/Touchpad_Elantech_Win7_32_Z11521.zip We need daniel_k's assistance on possible ways to actually track the installation (and behaviour once installed) in order to troubleshoot the likely problems and - hopefully - chack/review if the building of the Frankendriver needs some other tricks. Then this new Frankendriver should be tested on 8.1 first. And - no offence intended, Dave_H , but till now your reports have rarely gone beyond "it works" or "it doesn't work" + this or that side note, every time slightly different in contents. We need IMHO to establish a "protocol" for reports, in the form of a list of things to check and report, and in this daniel_k's assistance would also be useful. Additionally, and still IMHO, we need to remove *everything* that is not really-really needed from the former (ASUS (in the .inf) 11.5.20.3 07/20/2015 actual.sys 11.165.5.11) until it stops installing working in 8.1. Then restore to the last minimal configuration that installs in 8.1 and completely trace it. Then remove the corresponding items in the 11.5.0.9. And finally attempt creating the new Frankendriver, that at this point should as minimal as it can be. It is a lot of work and it will need some time (unless we - actually you - are exceptionally lucky). Besides that, by comparing the differences between two of the files found on the japanese ftp, namely: Touchpad_Elantech_UXseries_WinXP_32_Z10560.zip Touchpad_Elantech_Win7_32_Z10590.zip that are "very near" in versions we might understand what has changed from the "XP" and the "7" version. But we need a sort of spreadsheet to check hopefully at a glance what the changes are between the various versions. Give me some time and I will try and put together this base spreadsheet . jaclaz

Side note, and probably irrelevant, but unless you partiioned differently than usual on purpose, the volume order doesn't seem the normal one, it seems "reversed", usually first partition is "System", second is "Windows" and - if any - "Recovery" is last. https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions jaclaz

Interesting findings. jaclaz

No. The problem in the given thread is with Extended Partitons and Logical Volumes inside them, no matter the filesystem used. jaclaz

Yep , ideally a command (or script) requiring parameters if run without parameters or with insufficient/incorrect ones should print to screen some usage info and do nothing else (or "switch" to interactive mode). jaclaz

The first partition starts (normally) at 2048. Actually there are a set of Registry entries for that (in Vista and later): [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\vds\Alignment] @="Alignment Settings in Bytes" "Between4_8GB"=dword:00100000 "Between8_32GB"=dword:00100000 "GreaterThan32GB"=dword:00100000 "LessThan4GB"=dword:00010000 Where 100000 means 1,048.576. i.e. 1,048.576/512=2048 sectors , the "exception" is made for less than 4 GB sized media where 10000 means 65,536 and 65.536/512=128 sectors. When the partition is aligned to MB, DO NOT EVER use Disk manager from NT. 2K or XP to change ANYTHING on the disk, DO READ this thread http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/ jaclaz

You can do that basically in two ways. One (using a "flat" structure): https://superuser.com/questions/948450/can-you-make-a-windows-10-iso-with-both-pro-home-and-32-64-bit-flavors And the other (keeping the .iso's as they are and using a bootmanager such as GRUB2): https://superuser.com/questions/1055305/installing-windows-x64-on-32-bit-uefi-efi-ia32-via-grub For the first (casually ChrisPE/Win10PE is used) you can also peruse some of the info here (which is about making a dual boot USB drive): https://www.rmprepusb.com/tutorials/127-make-dual-32-64bit-pe and then still use oscdimg to create the .iso 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