Tripredacus Posted August 31, 2017 Share Posted August 31, 2017 Ok for this one, I followed the instruction to update the VIA SATA RAID controller device in Device manager and browsed to the folder that only has uataxp.inf in it. It did not change the VIA device but instead put a flagged device into Other devices. I then installed the driver for that, and now under System there is a UATA Virtual Communication Device. That driver is in the root of the Release folder of the driver download. The instructions do not mention having to install this device. This particular computer does have the IDE controller also, but the only thing connected to it is a DVD drive. Now having rebooted with this UATA driver installed, it doesn't seem to make any difference. It still shows the inaccessible drive (now E) in My Computer, and the same "healthy" extent sized volume in Disk Management. Link to comment Share on other sites More sharing options...
jaclaz Posted August 31, 2017 Share Posted August 31, 2017 WHICH folder? There is a folder \XP\ containing readme_xp.txt, uata_xp.inf, uata_xph.inf in my copy. Check device manager. Devices By Connection view. jaclaz Link to comment Share on other sites More sharing options...
Tripredacus Posted September 1, 2017 Share Posted September 1, 2017 Yes I had moved the INFs to different folders because it specifically says to use one vs the other depending on the controller. So I moved the H to a different folder so Windows could only pick the INF I wanted. Quote 10. enter path to .INF file for new driver If this is usual onboard IDE controller, use C:\temp\uniata\Release_Dist\uata_xph.inf If this is IDE RAID controller or additional PCI IDE controller, use C:\temp\uniata\Release_Dist\uata_xp.inf So since this is a "VIA SATA RAID" controller, I didn't want Windows to try to use the uata_xph.inf so I took it out of the folder. direct link: http://i.imgur.com/IQoS5Wkl.jpg FWIW, I did also try to use the xph driver on there, but it added about 6 flagged devices and all of them had the "not enough free resources" message in device properties. Link to comment Share on other sites More sharing options...
jaclaz Posted September 1, 2017 Share Posted September 1, 2017 (edited) I don' t know, but clearly the installation didn't go through correctly, the UNIATA replaces the VIA RAID controiller, it is not a "child" of it. There is no need to move the .inf, only you need to select the "right" one. But you can try installing differently. Try following this (seemingly completely unrelated) and remame the uniata driver: [redacted] Or remove the VIA driver, force the install of the plain MS one (I presume it is compatible anyway) and start again from there. jaclaz Edited September 5, 2017 by Tripredacus Link to comment Share on other sites More sharing options...
rloew Posted October 9, 2017 Share Posted October 9, 2017 At a minimum, XP will require UNIATA, or equivalent, as the standard ATAPI.SYS Driver only writes 32 Bits of the Sector Number to the Hardware. This gave me access through the ASPI Interface but not through the PHYSICALDRIVE Interface. Link to comment Share on other sites More sharing options...
jaclaz Posted October 9, 2017 Share Posted October 9, 2017 2 hours ago, rloew said: At a minimum, XP will require UNIATA, or equivalent, as the standard ATAPI.SYS Driver only writes 32 Bits of the Sector Number to the Hardware. This gave me access through the ASPI Interface but not through the PHYSICALDRIVE Interface. Yep, in theory Uniata should allow the same result as Tripredacus demonstrated for Windows 7 32-bit, i.e. that the good MS guys lied to us in their attempt to push UEFI/GPT. But maybe there is some additional (intentional or not) roadblock in XP. It seems like Windows Server 2003 SP1 (both 32 and 64 bit) have "native" GPT support, so - likely - that would be the first OS to support this scheme - like 7 - without needing further mods. The key should be : http://alter.org.ua/soft/win/uni_ata/ large drives above 2Tb support (SCSI READ16, WRITE16) jaclaz Link to comment Share on other sites More sharing options...
rloew Posted October 9, 2017 Share Posted October 9, 2017 In addition to the problem I saw, the FileSystem or Partition Drivers may not do the 64-Bit Math needed. In Windows 9x, I had to patch the FileSystem as well as the Disk Driver to support 64-Bit Math. Link to comment Share on other sites More sharing options...
jaclaz Posted October 9, 2017 Share Posted October 9, 2017 38 minutes ago, rloew said: In addition to the problem I saw, the FileSystem or Partition Drivers may not do the 64-Bit Math needed. In Windows 9x, I had to patch the FileSystem as well as the Disk Driver to support 64-Bit Math. Yes, but there is no need (in the proposed scheme) to use 64 bit math at all. All values are within the 32 bit limit since, once the volume is addressed, all addresses are relative and the 0 offset is from the PBR. jaclaz Link to comment Share on other sites More sharing options...
rloew Posted October 10, 2017 Share Posted October 10, 2017 The 64-Bit Math is required when the PBR relative Address is combined with the Partition Offset to create the absolute Address. In Windows 9x, this is done by VFAT.VXD so I was able to implement 64-Bit Math. I already had upgraded ESDI_506.PDR. IOS apparently always supported 64-Bit Math. I was unable to locate the necessary code in FASTFAT.SYS. I do not know if the code is there or if it is somewhere else such as the Partition Manager. I tried UNIATA with an Overlapping FAT32 Partition. It still doesn't work. Link to comment Share on other sites More sharing options...
jaclaz Posted October 10, 2017 Share Posted October 10, 2017 16 hours ago, rloew said: The 64-Bit Math is required when the PBR relative Address is combined with the Partition Offset to create the absolute Address. In Windows 9x, this is done by VFAT.VXD so I was able to implement 64-Bit Math. I already had upgraded ESDI_506.PDR. IOS apparently always supported 64-Bit Math. I was unable to locate the necessary code in FASTFAT.SYS. I do not know if the code is there or if it is somewhere else such as the Partition Manager. I tried UNIATA with an Overlapping FAT32 Partition. It still doesn't work. Maybe the DOS/Windows 9x/Me way to access volumes is different, cannot say. The Paragon driver (which does support GPT and thus more than 2.2 Tb addresses) is after all two drivers, but the fastfat.sys remains AFAICR the "default one" (and as well the NTFS.SYS, etc.). If you prefer (AFAIK/AFAICR) there are no original files patched or substituted in that solution, so I would exclude that the partition management and related files need any patch, I still beleive (but I may well be wrong) that all volume access is done using relative addresing only and on the other hand - unlike the FAT32 - the NTFS has 64 bit addresses since day 0, long before XP came out, so I would guess that the 64 bit math, if neeeded, is already correct. (but of course until some proper experiment confirms of denies it there is no way to know for sure). jaclaz Link to comment Share on other sites More sharing options...
rloew Posted October 11, 2017 Share Posted October 11, 2017 I don't have the Paragon Driver, so I don't know what two files are affected, but that would suggest that FASTFAT and NTFS only see the relative address. DISK.SYS manages the Partition Table so I assume it is replaced to support GPT. It and PARTMGR.SYS are the most likely Drivers to be the Filters that compute the Absolute Address. Link to comment Share on other sites More sharing options...
jaclaz Posted October 11, 2017 Share Posted October 11, 2017 2 hours ago, rloew said: I don't have the Paragon Driver, so I don't know what two files are affected, but that would suggest that FASTFAT and NTFS only see the relative address. DISK.SYS manages the Partition Table so I assume it is replaced to support GPT. It and PARTMGR.SYS are the most likely Drivers to be the Filters that compute the Absolute Address. I have it (for a limited time it was a "free" download), but I have no system with it installed, nor any "spare" large sized disk, so cannot make any real test, but I can provide you with some info. There are two drivers in the package: 1) hotcore3.sys 2) gpt_loader.sys At a quick look the two main/meaningful Registry entries are: HKLM, "SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}", "UpperFilters", 0x00010008, gpt_loader HKLM, "SYSTEM\CurrentControlSet\Control\Class\{71a27cdd-812a-11d0-bec7-08002be2092f}", "UpperFilters", 0x00010008, hotcore3 So gpt_loader "hooks" to "Disk Drive": https://msdn.microsoft.com/en-us/library/windows/hardware/ff553426(v=vs.85).aspx Quote Disk Drives Class = DiskDrive ClassGuid = {4d36e967-e325-11ce-bfc1-08002be10318} This class includes hard disk drives. See also the HDC and SCSIAdapter classes. and hotcore3 to "storage volume" Quote Storage Volumes Class = Volume ClassGuid = {71a27cdd-812a-11d0-bec7-08002be2092f} This class includes storage volumes as defined by the system-supplied logical volume manager and class drivers that create device objects to represent storage volumes, such as the system disk class driver. both are set as "Upper Filters", which should mean that they are "Filter Drivers", and given the GUIDs, they seemingly "hook" over - as you guessed - to the PartMgr.sys ({4d36e967-e325-11ce-bfc1-08002be10318}) but the other one (the {71a27cdd-812a-11d0-bec7-08002be2092f}) seems related to VolSnap.sys jaclaz Link to comment Share on other sites More sharing options...
rloew Posted October 11, 2017 Share Posted October 11, 2017 VOLSNAP is the layer above PARTMGR.SYS. It seemed a bit removed from the level where Partitions are enumerated in the Device Tree. It also does not call the Partition Table management functions. Unfortunately, providing GPT support does not guarantee that the entire Driver stack is 64-Bit compatible. The other solutions I have seen, emulate multiple 2TiB Drives. Only the lowest level Driver would use 64-Bit Math. Link to comment Share on other sites More sharing options...
jaclaz Posted October 11, 2017 Share Posted October 11, 2017 4 hours ago, rloew said: Unfortunately, providing GPT support does not guarantee that the entire Driver stack is 64-Bit compatible. Well, these drivers provide to "normal" XP BOTH GPT support AND access to bigger than 2.2 Tb (512 bytes sectored) disk drives, that is the whole point, and, compare with this: http://download.paragon-software.com/doc/GPTLoader_RG_081111.pdf at least they allow (of course in GPT style) a "monolithic" partition/volume of 3 Tb. It may be the case that the "GPT" part of the driver is the only thing 64-bit needed and then NTFS.SYS takes care of the "monolithic" partition/volume (that anyway begins at a normal offset of 63 or 2048 sectors, like any other "first partition"), but if this is the case it would be a really "ugly" workaround. jaclaz Link to comment Share on other sites More sharing options...
rloew Posted October 11, 2017 Share Posted October 11, 2017 It is possible that GPT_LOADER.SYS replaces PARTMGR.SYS and the lower Drivers with a Monolithic Driver. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now