jaclaz

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

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

As a matter of fact I tend to stay clear of each and every "ISO Editor" (except in very particular cases it is IMHO much better to extract contents and recreate the .iso from the content) but CDMAGE is a nice tool, not exactly an "easy", "good for everyone", "drag and drop" tool, but still a very nice tool, particularly very apt to converting images between various formats and to extract data from faulty CD's (besides the other more "normal" features). jaclaz

Yes , correct. I meant "raw" in the sense of "dd like", without anything added (no header, no footer, no fancy offsets, no separate index files, etc.). And this BTW brings us to good ol' CDMAGE (which is 9x/Me compatible): https://web.archive.org/web/20080914233949/http://cdmage.orconhosting.net.nz:80/main.html http://www.softpedia.com/get/CD-DVD-Tools/CD-DVD-Images-Utils/CD-Mage.shtml jaclaz

Well, this tells me nothing. Which drivers? Which BIOS? Etc. ..., it's not like I have handy the specs of a Intel D2700MUD (whatever it is) and certainly know nothing about how yours is set up. You can actually (if you can[1] of course) try installing the UNIATA: http://alter.org.ua/soft/win/uni_ata/ as dencorso suggested, that explicitly supports larger disks. jaclaz [1] meaning without disrupting your XP system or accepting that installing the UNIATA driver may corrupt it beyond repair (it shouldn't, but you never know).

Sure, and that (attempting to break them limits) is the right attitude! jaclaz

Sure and I would call you a very advanced user, doing very advanced things on your 9x systems , so it still doesn't seem to me irrational to say that 10 or 16 are "good enough" for *everyone* and 64 is already overkill. Just saying that there are maybe higher priority issues in maintaining/updating 9x/Me .... jaclaz

Well, the 512 to 4Kb conversion is another thing, a good example is here: http://www.overclockers.com/forums/showthread.php/687139-3TB-External-hard-drive-works-under-Windows-XP-out-of-the-box What we are working on is exclusively to debunk the 2.2Tb MBR addressing limit myth (which is more like almost 4.4 Tb) and till now we have it demostrated on Windows 7. There are as said n reports of people runnning XP on a 2.2 Tb partition on 3 Tb disks, in these cases the last part of the disk (the famous 746 Gb) are not partitioned/not partitionable, but the first 2.2 Tb can be partitioned just fine, exactly what happened to Tripredacus under Windows 7 and to the user on the referenced overclockers thread. Please take note how 349.31*8=2794,48 and 4096/512=8 jaclaz

Sure , but it is better to avoid introducing "third party" drivers in the experiment, a "normal" XP machine should normally work with 3 tb disks with the manufacturers' (or Microsoft's "standard") drivers. It is possible that 3 Tb support was added to the OS on some update/hotfix, but I doubt it. a plain SP3 should be fine, we have many reports of 3 Tb disks (512 bytes sectored) working just fine in XP (limited to a first parttion of 2.2 Tb or however up to the 2.2 Tb limit) and the internet is choking full of reports of both XP and 7 showing the 746 Gb issue, but with no real "fix" if not "try this other driver version, and reportedly the standard Microsoft drivers work. Tripredacus' machine may be "peculiar" (for one reason or the other). jaclaz

Sorry, but I have to ask. What is the actual *need* to ever open more than one, two, maybe three, at the very most four DOS Boxes on a 9x system? I mean, if the hardcoded limit was - instead of 64 - 10 or 16, would anyone (outside of intentionally testing the limits of the OS) ever had noticed it in real life use of the OS? jaclaz

Well, a RAID 1 mirror is a mirror. The disks - until they failed - had exactly the same contents. So the Office install was on BOTH drives. If - after the "repair" you performed the booting drive has no Office install, it only means that *somehow* the repair procedure removed it or some parts of it. You can well (from another OS) copy the "working" Registry from first drive to second one, but the result will most probably be two separately working fine disk drives, BOTH without Office. One of the two (very likely) will have a modified Disk Signature (automatically recreated by the Windows 7 booting with "separate" drives due to the conflict it will have found, as such one of the two disks won't have proper drive letter assignments (and as such won't boot properly until you fix/delete the DosDevices letter assignments). As I see it your only way out (not easy at all, mind you) is to remove from the system (disconnect) the disk drive that is now booting and troubleshoot/fix (manually) the non-working one. If all that is needed is the Office key, usually it can be retrieved by using some script ot little thrtdpart utility, however this may depend on the version of Office you had installed. jaclaz

No, it's ok (meaning it isn't ). The disk partitions are intact as confirmed by the successful re-test on the windows 7 machine, the issue you are having is only the "generic" 764 Gb instead of 3 Tb seen that is connected with this (or that) XP driver and it is most probably not connected with the second partition. The check with Tiny Hexer would be only useful to understand if it actually can see/access the disk MBR (first sector of the physical drive) or if the 746 Gb (as I suspect) are just the result of some "queer" wrap around. To definitely check you can 0x00 the second partition table entry and try again, but I doubt that it will change anything, In any case the issue is solvable only if you can find and install fully working drivers (that may or may not exist for your specific board), or maybe - cannot say - it is some BIOS incompatibility, There is (or was) a DDO of sorts for Seagate drives, but using it would of course be another thing (and I believe it is hardcoded at the 2.2 Tb mark): http://knowledge.seagate.com/articles/en_US/FAQ/218619en? Easier would be - to see if you have any other motherboard (and XP install) that can see the full 3 Tb. jaclaz

Hmmm. Allow me to completely and utterly disagree. That is not how cases are closed, this is how cases are opened and later ignored, without investigating them. (possibly because of lazyness by the investigator ) jaclaz

That is exactly the thing that makes little sense (to me), it would be only an "added feature" to WinNTSetup without any particular advantage (saving one reboot maybe), I mean, cannot the autounattend.xml be created (and/or modified if needed) before and besides using WinNTSetup? jaclaz

@Atari800XL I am still perplexed/unsure. When does autounattend.xml run? After "apply" AND after "first reboot", right? And you want to try to change the name BEFORE that, i,e. after "apply" and before "first reboot", is this correct? So you can try, on a PE with the WMIC enabled if this can be done. And if yes, then try to replicate it manually without needing the WMI environment, by either mounting the offline registry and applying a .REG or by using the offline registry library. jaclaz

Well, it sounds just "normal" to me. At the time nlite was tested by n people and Nuhi did change nlite to be compatible with SP3, afterwards nlite devlopment was discontinued and it is to be expected that this or that glitch with unoffical SP4 happen. There is a Harkaz's Unofficial SP4 theead on MSFN also (just for the record): http://www.msfn.org/board/topic/171171-introducing-unofficial-windows-xp-sp4/ The Unofficial SP4 can be also integrated via nlite, maybe this makes a difference? jaclaz

Well, it is a "queer" question IMHO. You just asked to have this done by WinNTSetup, i.e. before the first reboot. If this is possible, it is possible, if it isn't the problem cannot be solved by WinNTSetup anyway. I mean, when does the autounatted,xml run? The doubt is (or should be) more about the potential need of changing some other keys (and/or setting a flag of some kind) besides changing the relevant keys values. If you prefer, does the WMIC command "WMIC ComputerSystem where Name="currentname" call Rename Name=newname" only chnage those four name instances or does it do *anything else*? In any case (for experimenting), there is normally no issue to add the WMI environment to a PE, I don't think that later PE's have changed since PE 2.x/3.x: http://www.msfn.org/board/topic/143622-how-to-install-wmic-in-winpe/ jaclaz

Computer name is (or should be) in 4 keys (on the running system): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Hostname HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\NV Hostname HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName\ComputerName HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerName\ComputerName Most probably you can change them while in the PE using the Offline Registry library (and tool). http://reboot.pro/topic/11212-offline-registry-library/ http://reboot.pro/topic/11312-offline-registry/ If you are doing it manually or with other tolls/methods, make sure to get the right "ControlSet". jaclaz

Also, check the actual SATA/IDE controller drivers on the XP, there are many reports of issues with drivers, often INTEL RST, causing that problem, it can happen also on Windows 7 machines, examples: https://www.servethehome.com/fix-746gb-3tb-hard-drive-issue/ https://www.chrisnewland.com/solved-3tb-hard-drive-only-shows-74652gb-in-windows-7-389 You can also try (since you are anyway in IDE mode) the "Standard Dual PCI IDE Controller": http://www.aomeitech.com/forum/discussion/682/what-to-do-when-new-3tb-hard-drive-only-showing-746-gb/p1 jaclaz

Let's see if I can sum it up. The issue here seems to be with the first partition, besides and before the second. When you were on 7 you had (initially): 1st partition: 1852.69 Gb Unused: 195.31 Unused (AND inaccessible in Disk Manager because past the 2.2 Tb) : 746.52 Later you had: 1st partition: 1852.69 Gb Unused: 195.31 2nd partition; 600 Gb Unused (and inaccessible in Disk Manager): 146.52 Now (on XP) you have only one partition (not formatted with a valid filesystem) with the same size of the extents beyond the 2.2 Tb. Queer, really queer. Can you check the actual contents of the MBR partition table? On XP you can use (say) TinyHexer with my MBR or PTN template: http://reboot.pro/topic/8734-tiny-hexer-scripts/ or any other suitable disk editor or MBR utility. Or simply reconnect the disk to the Windows 7 system and see what it finds now. It is well possible that Disk Manager mingled something (not unlike what it does on non cylinder aligned logical volumes inside extended): http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/ http://www.dcr.net/~w-clayton/Vista/DisappearingPartitions/DisappearingPartitions.htm but in that case some user action, besides merely opening the disk manager was needed, namely changing the active status of a primary partition. jaclaz

No, that wouldn't make any difference the extents are "reserved" to a partition/volume, no matter if it is filled up or not, that is the whole point about partitioning . Once the OS can access the volume, it doesn't matter, all the volume structures are relative to first sector, the NTFS filesystem has 64 bit fields, and - in any case - the "units addressed" in the filesystem are LCN (Logical Cluster Number) that is normally 8 kb in size, so it won't ever reach the 32 bit limit within a volume whose size in sectors, i.e. 512 bytes units, is below that. The potential issue is only if anything sums the LBA address and LBA size expressed in sectors. Booting would be probably tricky, not because of the NTFS or anything else connected to the volume, but only because of (maybe) some limitations in NTLDR (and/or NTDETECT.COM). There is/was a known issues with SETUPLDR.BIN on DVD's where if the (CDFS) LBA was too high it would not boot, I would be not surprised if something similar happened with NTLDR. But in any case there is no real *need* to boot from this "added" volume even in single disk systems, as the bootable volume can anyway be the "first" one (or however any volume entirely contained within the first 2.2 Tb. So, yes, attaching the disk as secondary on an XP system would be more than adequate for the test. jaclaz

Some files can be retrieved via Wayback Machine using their "office update" link: Sr1off97.exe http://officeupdate.microsoft.com/downloadDetails/sr1off97detail.htm Fm2paste.exe http://officeupdate.microsoft.com/downloadDetails/fm2paste.htm O97dtfix.exe http://officeupdate.microsoft.com/downloadDetails/o97dtfix.htm O97attch.exe http://officeupdate.microsoft.com/downloadDetails/O97attch.htm Sr2bof97.exe http://officeupdate.microsoft.com/downloadDetails/sr2off97detail.htm Jetcopkg.exe http://officeupdate.microsoft.com/downloadDetails/excel97odbc.htm And more generally: https://web.archive.org/web/*/http://officeupdate.microsoft.com:80/downloadDetails/* jaclaz

Try via Wayback Machine: https://archive.org/ Ideally, you could test each and every file, making a new post with the links working and another one with those not working. (so that someone can assist you with finding the missing ones). A lot of files won't be retrievable because of the "interstitial" pages but you can find often the filenames and then look for them, An issue may be with "localized" versions, most available files are only en-us or another specific language, it is rare to find "all" of them on the same mirror site, example: ftp://ftp.uni-rostock.de/pub/tools/microsoft/ServicePacks/Office8/us/ jaclaz

Good. The volume, even if it is partially "beyond the border" is to all effects a "normal" volume, the NTFS filesystem is exactly the same on MBR or GPT partitions/volumes, its size is well within NTFS capabilities (and actually it can be - at the very most and on 4 Tb disk - anyway smaller than the first volume which can be at the very most almost 2.2 Tb). The possible issues are only connected to testing if any of the various tools that are "normal use" may have an hiccup with the volume location, technically the issue is with *anything* that may treat the "volume" as a "partition" AND have "artificial" checks/limitation (be them either intentional or not), but not with "normal" operations at the volume level. I have very little doubts that Windows 7 may have any issues, since anyway it has GPT (and thus volume placed at large addresses) support. I would be more suspicious of NT/2K/XP. jaclaz

And AGAIN, there is NO PATCH whatever in Usher's method. IT DOES NOT INVOLVE ANY PATCH, only some minor modifications to SYSTEM.CB (only useful in Safe Mode). jaclaz