jaclaz

I am not sure to follow you, the requisite AFAICU is the driver and a local NTFS (if you prefere this is these are the requisites to create locally a link or "mountpoint"), the "source" doesn't need the driver, and as long as the file is accessible can be *any * filesystem, is this what you are saying? "same system, other partition" actually means "same disk device, different volume", it is very possible that they also fail to work if "same local system BUT other disk device" But it is very possible that the specific program has it's own ways to access a file flatly bypassing the driver or using a Windows function that the driver does not "hook". jaclaz

... which you carefully avoid to reference but that probably are the ones referenced here: http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html The "generic" solution as you found out is most probably the Symbolic Links, most probably (depending on the specific application) there are alternate solutions, but I doubt there can be other "generic" ones. jaclaz

The issue seems like connected to a wrong Codepage (or a similar issue related to wrong mapping of characters). The "base" is a Greek version of XP and by itself works correctly, right? The only modification you make to it is to add/integrate the driverpacks, right? (or are you using *any* other tweak/removal/whatever in nlite?) And are you doing this in the "right" order, i.e. first nlite, then driverpacks, right? http://driverpacks.net/docs/beginners-guide-windows-xp jaclaz

Well, it depends if we are all together (as people) or if there is still the wall between us , usually when people on this side of the wall feel a bit sad they simply have a peek on the poor guys on the other side and *somehow* feel better and smile . Hey, I even had a "custom made" emoticon exactly for these occasions : jaclaz

I have been called names before but this must be an absolute first. Richard III (1:3): "That thou hadst called me all these bitter sweet names." jaclaz

Good , so I can ask Drugwash (still if he has nothing better to do, i.e. with a low-low priority) if he could try making an user program making use of the MSdelta.dll compression working in Win9x/Me WITHOUT any "special" provision for NT based systems but ALSO WITHOUT any intentional and artificially introduced incompatibility with them. jaclaz

I don't get it , the good MS guys that by default disabled in a standard install the execution of PowerShell scripts had in mind to protect your security, of course you cannot run PowerShell scripts if PowerShell scripts are disabled, it is like you want to connect to the internet but refuse to have an IP assigned by your local DHCP server and do not set it manually. jaclaz

Windows 2000 or your peculiar install of Windows 2000 with a zillion of mods, patches, modified kernels, wrappers and what not? I mean, the former has not given issues of any kind in several installs, some still running, in the last 10 (ten) years, of course with it's limits on hardware and programs on them, the second (which I understand may be need patching in order to run on more modern hardware and running originally non-compatible versions of programs) is obviously far less stable. jaclaz

@gunsmokingman http://www.tech-recipes.com/rx/2513/powershell_enable_script_support/ jaclaz

What do you mean by "bootmgr failed"? Which error are you having? You do have a bootable USB stick as in the 7-steps set of instructions Ntator posted, right? Let's take those 7 points as reference, what happens when you do each of them? (or where what happens appears different from what is expected to happen?) jaclaz

In my experience very poor people cannot afford more than 512 Mb of RAM anyway, so it looks to me like a non-problem. jaclaz

Maybe it is just about time to bring down the wall between the "we" and the "they" and consider everyone as being "ordinary" slaves under the MS "plaaned obsolence evil plan"? I mean, now that also 2K and XP are out of support, we could maybe manage to rebuild the wall only to keep the NT 6.x people outside? And yes, if we cannot get to it, remember how Win2K is waaaay better than WinMe and how Godzilla can make mincemeat out of King Kong ANYTIME! jaclaz

Yep and it seems like NOONE actually made a compression/decompression tool using MSDelta.dll , so if by any chance you have nothing better to do, a nice project would be using MSDelta AVOIDING the stupid .Net bloat: http://www.msfn.org/board/topic/173071-msdeltadll-usage-help/ jaclaz

I understand and exactly because of this: I asked, because if a driver is *somehow* modified/repacked/compressed/whatever BUT the result is not tested and verified working on the specific hardware it represents IMHO more "wishful thinking" than an useful solution, and you can compress it as much as you want/can, still it will take some space without being of any practical use... Before I forget, we have some news here (possibly useful): http://www.msfn.org/board/topic/171184-microsoft-ipd-intra-package-delta-compression-tool/ http://www.msfn.org/board/topic/171184-microsoft-ipd-intra-package-delta-compression-tool/?p=1091462 jaclaz

Yes and no. Meaning that it may be easier, but not necessarily "new" means "better" and sometimes it doesn't even mean "working", if the given, specific version of imagex.exe - as it has been specifically reported - works as expected in the specific environment/setup/scope there is NO reason to NOT use the specific version linked to and instead attempt using a later version (that may work fine as well or completely fail to). jaclaz

May I ask a question? WHY it is *needed* to "to unpack with any number of available unpackers, change the inf and repack"? I mean would it not make more sense to make the actual drivers be available "as they are" and provide a tool or a set of detailed instructions (or, better, both) to allow the "final user" to modify the drivers (when/where possible) himself/herself (asking nicely to provide back the modified and TESTED driver)? I doubt that a "one-size-fits-all" approach on a huge mass of drivers may lead to anything more than a handful (maybe) of working ones and a large majority of useless crap (additionally modified). jaclaz

Hmmm, little by little we are managing, through applying some (light) torture , to extract from you the actual goal, which now seems to me more *like* "How can I change each and every PATH reference in the Registry to a set of new values?". You should be aware of the generic risk of slipping on chocolate covered bananas, JFYI: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/put-down-the-chocolate-covered-banana.html Now, the next question is: Are you doing these modifications on an "online" Registry or are you doing it on a set of offline hives temporarily mounted in the online Registry? I mean, this may be of use: http://reboot.pro/topic/11212-offline-registry-library/ http://reboot.pro/topic/11312-offline-registry/ Or, depending on the actual use of the thingy, you may be able to afford paying a few bucks for a Shareware program, like (examples only, not necessarily a valid solution): http://www.funduc.com/registry_toolkit.htm I would also explore/experiment to see how much it is still functional the REGFIND from good ol' W2K Resource Kit: http://www.petri.com/download_free_reskit_tools.htm jaclaz

I see. That file is an update (actually an hotfix) for imagex.exe. It is a self-extracting executable, so you should just download it and then run it, and it should replace your current imagex.exe. If - for any reason - it doesn't work - you can open the 430546_intl_x64_zip.exe in 7-zip, then open inside it the Windows6.1-KB2525084-v2-x64.cab and from it extract the imagex.exe, replacing (overwriting) your current imagex.exe. The full KB insttructions are here: http://support.microsoft.com/kb/2525084/en-us jaclaz

Possibly a line needs to be drawn between "antivirus" and "antivirus with a a real time scanner", just for the record: http://www.clamwin.com/ of course one needs to know what he/she is doing if no real-time antivirus is running. jaclaz

WHICH error? Or same as WHAT? jaclaz

Or if you want to remain strictly inside batch you can use WizApp, the Wizard Apprentice: http://wizapp.sourceforge.net/ jaclaz

Besides the very high probability of being essentially FUD, this has the usual issue: http://www.pcpro.co.uk/operating-systems/1000045/the-moral-mire-of-not-patching-windows-xp? In order to lose "moral high grounds" one needs to have them, as I see it. jaclaz

Of course I am gonna approach it from the side you did consider but then swiftly discarded. The problem can be "generalized", as I see it, it amounts to two three questions: How can I get a .reg file containing the export of a SINGLE key with binary data?How can I convert such a .reg file representing a SINGLE key with binary data into a "bastardized" format that I find useful for search and replace?How can I convert back, once I have performed the needed search and replace, the data from this "no separator" format into a .reg file, ready to be re-imported in the Registry?Answers:#1 Use REG.EXE export [ROOT\]RegKey FileName.reg <- and this is pretty much all you can do with "built-in tools" For #2 and #3 external tools are needed, and some pretty much complex fiddling I have jumped over the "once I have performed the needed search and replace" and tried putting together two small batches, one is intended to convert the .reg file to the specified "RAW" format, and the other one is intended to recreate the .reg file from it. I have used what I had handy (and that I often use), i.e. gsar and SFK (SwissFileKnife): http://stahlworks.com/dev/swiss-file-knife.html These batches have NOT the ambition of being well written or "good", they are as usually half-@§§ed, quickly put together, batches with very little (if not none) "error control", making use of a stupid amount of temporary files and not even cleaning the mess after having been run, but maybe they could be of inspiration to make something "better". regtoraw.cmd: @ECHO OFFSETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSIONSET SourceReg=testbinary.regSET /A Counter=0IF EXIST RegHeader.txt del RegHeader.txtFOR /F "tokens=1 delims=:" %%A IN ('TYPE %SourceReg%') DO (SET /A Counter+=1SET Line=%%AIF "!Line:~-3,3!"=="hex" SET Line=!Line!:&ECHO !Line!>FirstLine.txt&GOTO :Out_of_ForECHO !Line!>>RegHeader.txtIF "!Line:~-4,4!"=="5.00" ECHO.>>RegHeader.txt):Out_of_ForIF EXIST myraw.txt DEL myraw.txtFOR /F "skip=3 tokens=1,2 delims=: " %%A IN ('TYPE %SourceReg%') DO (SET Line=%%AIF "!Line:~-3,3!"=="hex" (ECHO %%B>>myraw.txt) ELSE (ECHO %%A>>myraw.txt))gsar -s:x5C:x0D:x0A -r -o myraw.txtgsar -s:x2C -r -o myraw.txtrawtoreg.cmd @ECHO OFFSETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSIONgsar -s:x0D:x0A -r -o FirstLine.txtCALL :get_size FirstLine.txtSET /A offlen=%FirstLine.txt%-2SET /A offset=%FirstLine.txt%-2sfk filter myraw.txt +hextobin myraw2.txtsfk hexdump -hexsrc -recsize 25 -nofile -offlen 0 %offlen% myraw2.txt>myraw3.txtsfk hexdump -hexsrc -recsize 25 -nofile -offset %offset% myraw2.txt>>myraw3.txtgsar -s0x -r -o myraw3.txtgsar -s:x0D:x0A -r:x5C:x0D:x0A:x20:x20 -o myraw3.txtsfk replace -case myraw3.txt "/A/a/" "/B/b/" "/C/c/" "/D/d/" "/E/e/" "/F/f/" -yesCOPY RegHeader.txt + FirstLine.txt + myraw3.txt mytempreg.txtsfk partcopy mytempreg.txt -fromto 0 -7 myreg.txt -yesECHO.>Unicode_myreg.txtCOPY myreg.txt + Unicode_myreg.txt + Unicode_myreg.txt myreg.txtgsar -s:x0D:x0A -r:xFF:xFE -o Unicode_myreg.txtCMD /U /C Type myreg.txt >> Unicode_myreg.txtGOTO :EOF:get_sizeSET %1=%~z1GOTO :EOFSFK is a very comprehensive tool and I know only part of it's usage, so it is very likely that there are "better" ways using it or that "more suited" tools exist.I used gsar only because I am more familiar with it for the simple replacement, most probably it is not *needed* at all and everything can be done within SFK. Most of the complication is in re-creating a file identical to the original source, very likely the REG.EXE IMPORT will not be so "picky" on line length of the comma separated values, or with the CaSe of the letters corresponding to hex values. Have a Merry Christmas. jaclaz

Well, anything beyond any of the two mentioned "limits" (roughly 4 Gb ad 8 Gb) are very likely to be mis-recognized or *whatever*. Which SP do you have integrated in the NT 4.00? You should try to integrate SP6a: http://reboot.pro/topic/2383-windows-nt-service-pack-integration-slipstreaming-toolkit/ the mscab is still available through Wayback Machine: https://web.archive.org/web/20071220062213/http://mateusz.free.fr/mscab/ What is queer is that the C:\ and D:\ (i.e. first primary and first volume inside extended) are as well problematic. It is possible that *somehow* the "later" partitioning affects also the recognition of the first two, but it is "strange", particularly it is strange that the first primary (the C:\ drive) is considered Unformatted or damaged, it is likely that you fell into one of the little "traps" we haven't mentioned: http://support.microsoft.com/kb/151414/en-us Are you sure-sure that the partitioning and formatting was done correctly? Check the Partition ID's. The FAT volumes C:\ and D:\ should have a partition ID of 06 (and NOT of 0E) And possibly the Extended Partition should have - at least temporarily - a partition ID of 05 (and NOT of 0F). It is also possible that you will need to make a smaller Extended partition (in order to get the 05 ID) and later "expand" it to the final size. Can you run Partinfo (from the working 98) and post it's output? jaclaz

Well, to be fair, the SATA connector has been designed for 50 connections/reconnections http://www.wdc.com/en/products/resources/drivecompatibility/ In real life the connectors should last much longer than what the specs allow, still it is not a good idea to insert/remove frequently the SATA connector. The "right angle" ones (WITH clips) are said to be more reliable, but cannot really say, but whenever possible I would use the "latching" ones, straight or right angle. It is now a rather common issue, or at least it happened to me more than once (when you move, or send a PC through a courier, etc.) that on destination the PC doesn't boot up and on inspection the issue is the SATA connector on the cable, usually on the hard disk end, has come loose, and i have seen more than a few "mail-ordered OEM" PC's arriving with a bit of "hot glue" or "silicon" over the connector on the hard disk to keep it steady or even with an elastic band to prevent them from getting loose. As always having the contacts (on the hard disk and motherboard/card ) cleaned possibly using a specific product helps as I believe that such issues are due to the actual "springy effect" in the (cable side) connector losing some strength. jaclaz