jaclaz

I see , you meant : ....which should be translated to : jaclaz

What I suspect (though having NO actual way to test/compare) and still related to the "missing CD/DVD" is the following: with firadisk: when chosing 32 bit wim firadisk (32 bit driver) maps BOTH the .iso at "boot time" and at "GUI install" since everything is 32 bit, everything works when chosing 64 bit wim firadisk maps the .iso at boot time but results in "a suffusion of yellow" at GUI install since for *whatever* reason (driver conflict or 32 driver partially or fully loaded) the iso is not mapped properly with IMDISK when chosing 32 bit wim IMDISK (32 bit) maps the .iso at GUI install and since everything is 32 bit, everything works when chosing 64 bit wim IMDISK (64 bit) maps the .iso at GUI install BUT for *whatever* reason (driver conflict or 32 driver partially or fully loaded) the result is "a suffusion of yellow" It is also possible that for *any* reason the IMDISK that is installed throught the method here: http://www.rmprepusb.com/tutorials/multiisoimdiskautounattend is the "wrong" version or that the version included (which is fairly old) has some issues together with your drivers. In order to troubleshoot, if I were you I would try using the initial more manual method sketched here: http://reboot.pro/9076/page__st__25#entry123384 https://sites.google.com/site/rmprepusb/tutorials/winiso jaclaz

...and some wise philosophy : jaclaz

Good. So, summing it up, the six points are only five, and since the first one is always [0,0] they are actually only four (and one of them set at [40,568] makes no sense and can be placed at (say) [5,n] allright. I have some issues with this : We have 11 Levels in the CP app cursor. But we have at least 20 values in Mouse Sensitivity in Registry (from 1 to 20 or possibly from 0 to 20). Since the good MS guys invented the "mickey" and more generally used units of measure in a very "vague" way, I feel authorized to introduce THREE elements: MSCPL=Mouse Sensitivity in the Control Panel Levels RMSV=Registry Mouse Sensitivity Values ASOY=A Suffusion Of Yellow The "conversion table is the following: Using the control panel cursor you can only have these values in the MouseSensitivity key in the Registry, but all intermediate values are valid. So you have a reversed table: The formula: gives only a point (65536) of the diagram of conversion between MSCPL and actual MouseSensitivity Factor. It would be logical that the "scalar set" to generate the family of curves is linear, i.e. that, using the "reduced" set of MSCPL you have: MSF@MSCPL6=10*65536/10=65536 and: MSF@MSCPL1=1*65536/10=6553 MSF@MSCPL2=2*65536/10=13107 MSF@MSCPL3=4*65536/10=26214 MSF@MSCPL4=6*65536/10=39321 MSF@MSCPL5=8*65536/10=52428 MSF@MSCPL6=10*65536/10=65536 MSF@MSCPL7=12*65536/10=78643 MSF@MSCPL8=14*65536/10=91750 MSF@MSCPL9=16*65536/10=104857 MSF@MSCPL10=18*65536/10=117964 MSF@MSCPL11=20*65536/10=131072 The results of a quick experiment lead me to think that this "scalar set" is non linear, and can be approximated with a quadratic expression. Due to the obvious lack of precision of this early experiment and to the limited time I spent in half-@§§edly doing it, it is possible that the actual values are inaccurate, but the difference between a linear set and a function one is so evident that I have some serious doubts . I am attaching a small spreadsheet with the results of the experiment, definitely - due to the half-@ssed testing procedure - I have lost important precision in the "lower levels", but "higher levels" should be "accurate enough", and more than that the "general shape" if not the actual scale/parameters should be also "accurate enough". I tried to manually rebuild a more "logical" diagram of the "family of curves", measuring the image in the MS article, and the "linear formula" seemingly does not fit . jaclaz linearorcurve.zip

... and possibly im many more as simple ways. XXCOPY is also IMHO an exceptionally goot tool, but it is not the only option, just as an example Xclone would most probably do : ftp://ftp.sunet.se/pub/simtelnet/win95/diskutl/xclone13.zip I don't see the actual connection , in that case I gave you a report about a tool found to be a MUCH faster way (and JFYI "not-really-equivalent" as hdderase will also wipe a few sectors not normally accessible by external software, so also "better"), I may well be wrong, but I don't think that there are great speed differences when using XXCOPY vs XCOPY vs. XFILE vs. XClone vs. *whatever*, in the sense that any "file based" tool will take more or less the same time. XXCOPY Author confirms how the program is not particularly tuned towards "speed" (at least no for a "bulk copy" as the one we were talking about: http://www.xxcopy.com/xarc/msg/msg00189.htm but the context of that thread: Was that what was actually needed was maybe to wipe the first handful of sectors and instead it was suggested to wipe the whole disk and suggested a slowish tool to do this completely unneeded thing . jaclaz

Exclusion made: for the XP Home in member's profile for this: You should make your sentences more complete, like : jaclaz

Could you share your understanding (since besides bphlpt I am confused at well)? Right now I simply have no meaningful data to think about, I guess unless you try describing EXACTLY your setup, and the EXACT error and EXACTLY when it happens, I doubt that - besides me - anyone can really suggest you something of use. Maybe it would be useful if you provided such details this time. There are SEVERAL ways in which you may have used either Firadisk or IMDISK, several ways in which you could have edited the BCD and most probably n other factors that I am completely forgetting . So, the mere fact that I extorted from you that you used firadisk and your subsequent report that you also tried IMDISK are of no actual relevance. It is possible that if you DETAIL as much as possible your attempts someone can (hopefully ) spot where the issue lies. Right now it seems to me that this thread till now is about people giving maybe 1/10 to 1/5 of the needed informations and other people giving "vague" guesses in such a way that they can be ambiguously interpreted. Compare with: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/problem-report-standard-litany.html jaclaz

Yep , once I tried to use my long-time-trusted hammer to drive a nail into a wooden plank and the little bastard got one of my fingers instead . The moral being: jaclaz

Heck, it is a VERY gruesome practice! Anyway, you may have better luck looking for "seppuku", here is a (rigorously copyrighted ) nice T-shirt design that has NO blood in it: http://everyjoe.com/play/how-to-commit-seppuku-t-shirt/ but I guess clay is allright jaclaz

Something like this: http://retired.beyondlogic.org/dddtools/dddtools.htm (go to the bottom of the page "Device Driver Remover for Windows 95 & Windows 98") only with command line interface, should be what is needed, or, if noone finds it, possibly it can be "automated" via AutoHotKey or similar... Or, maybe something similar to the FTDI CDM uninstaller (BUT Win9x oriented): http://www.ftdichip.com/Support/Utilities.htm but one needs anyway to parse the Registry to get the Vid/Pid... It is very likely that the "Complex UNinstall Method" described here: http://ww1.microchip.com/downloads/en/devicedoc/51417b.pdf can be automated via batch or similar... jaclaz

Just wanted to share this nice thingy, I am not alone in thinking that the paradigm shift is towards more "passive" use of the technoology, Scott Adams (Author of the Dilbert strips) has put it down way more nicely than I did (obviously): http://www.dilbert.com/blog/entry/the_amazingness_of_instant/ jaclaz

42 (at least). How many roads must a man walk down before .....? Approximately the same number of times one must say RTFM and ground ALL equipment used to unbrick the 7200.110s JFYI: etc., etc. I guess 50% of my posts in the related thread ONLY provide these three directions: Read the read-me-first FIRST do EXACTLY what is in it and in the advised guide ground ALL items (and loop to #1) BUT specifically, and if I may , there should be a way to add in the installer/whatever *something* that automatically removes anything that needs to be removed prior of the installtion of NUSB it would be a "quantum leap" for a next version.... jaclaz

Yep , I had guessed that (since you completely failed to mention firadisk, as well as any actual detail on how you have currently setup your iso ), the suggestion was to try using IMDISK instead (as it comes in 64 bit version and signed) but the not-so-hidden attached strings was YMMV . jaclaz

Well, you asked for it, so, yes you are WRONG. The original issue is about a firmware bug that simply "bricks" the driver when a log reaches a certain entry number 320*n+256, more details are here: IF the disk is affected EXCLUSIVELY by the mentioned bug, it will brick every 3 to 9 months on average and can be re-unbricked all the times. BUT the "bricking" may be due to OTHER reasons. AND the "unbricking" procedure may temporarily provide "relief" to this other condition (just enough to hopefully get the data back). @Hazor The "garbage" is connected normally with missing or badly implemented GROUNDING. Check, re-check and triple check that proper grounding is effective. Read attentively the read-me-first, particularly point #7: jaclaz

Why not getting it from the "mouth of the wolf", for the exact OS you have, updated to the exact SP level you need and create out of it a .iso? Here: http://reboot.pro/2254/ http://support.microsoft.com/default.aspx?scid=kb;en-us;Q310994 and no, the good MS guys didn't make a SP3 version, AFAIK. jaclaz

I totally missed the reference to "six" points! There are obviously only 5. The sentence is particularly ambiguous. It can be read as if there are 5 "explicit" points (or if you prefer 5 values in the Registry key) and a sixth (implied) one set by design to 0. I.e. it is possible that the curve is actually: [0,0] (0,0) (0,430007935.1,369995117) (1,25,5,300003052) (3.86000061,24.0000305) (40,568) What happens if we set first "explicit" point to something different from (0,0)? Like, as an example, to (0,0.215)? jaclaz

A lot of years have passed since the last time I had to do this, but - just for the record - I remember that it is perfectly possibly (on 9x/Me systems) to use "plain" Xcopy/Xcopy32, the good ol': of course target must be partitioned/formatted/SYSed, cannot remember if I used some additional tools/steps, exception made for temporarily disabling pagefile (no pagefile) and running in safe mode, original source: http://www.duxcw.com/digest/Howto/hd/cpyhd/cpyhd2.htm The directory dates are usually of no relevance (keeping 'em or having them changed won't make a difference in normal operation). jaclaz

No need whatever to re-partition, but if you have not the patience (and abilities) needed, you can well re-install, this time using a migrate.inf file and have the letters assigned the way you want them to be. jaclaz

Which "signature"? You mean volume serial number? I.e. the data that is @27h in a FAT16 and @43h in a FAT32 PBR ? jaclaz

Oww, comeon , in love, war and MS computing there are NO rules , or if you prefer: jaclaz

Very interesting info in your post . I will try and digest them. There is a point in this: that I can clarify immediately. (as said the proposed curves need to be "scaled" , as the intention was to render the "shape" of the curve, so the reason for the initial 2:1 was that of attempting to emulate as good as possible the Win2k for the "most used" part within the 4 segment limit). One of the really "queer" things in the "XP ballistics" article (among many - if not plainly wrong - definitely incorrect or deceiving info) is the actual numbers of points (and conversely segments): http://msdn.microsoft.com/en-us/library/windows/hardware/gg463319.aspx Now, even a single handed guy can count up to six (by touching his nose ) so HOW THE HECK they managed to wriite down such inconsistent info? Another thing, if really-really the graph and data are expressed in inch/s (something that I am starting to doubt GREATLY) and IF the "extrapolation limit" is set at 4-inch (should be 4 inch/s), all points up to n-1 should have X values below 4 (and this happens with the default curve) and any curve where the n-1 point is greater than 4 should have a n-1 to n segment that is ignored And of course having the n point on 40 is pure nonsense, n could be fixed at (say) 5 and n-1 fixed to slightly less than 4 (and the original curve is around 3,86). jaclaz

Actually one should go through the respective drive manufacturer diagnostics, BEFORE that . And possibly re-test with a tool like Victoria or mhdd.... Then flip a coin, and whatever is the result , change that drive, and the new one will crash in two months time. Seriously, very few things in my experience are so aleatory as the "expected lifetime" of a disk. Once upon a time (many, many years ago) I saved some data from a Samsung HD (a 4.3 Gb one, so you understand how much time has passed). The drive suffered from a rather "heavy" head crash which made several HUNDREDS clusters not only unreadable any more but even not formattable (and in theory there should be magnetic debris all over the disk, likely to ruin quickly the whole surface). Once I got the data (luckily the actual "important" data was fully recovered) and having installed a new hard disk, I had this "relic" around. After a few tests with zeroing out, formatting, wiping, etc. with no result, I set it aside. Being (notoriously) cheap a few years later I decided to make an experiment (I needed a small hard disk for a headless "controller like" machine, of course not in mission critical use). I simply determined by experiment where the bad clusters were ( a biggish almost contiguous zone around 1/3 of the disk) and simply partitioned the disk in such a way that that zone was left untouched (one partition before and one after the bad zone). As per today, that machine (and the disk) is still working allright (and has it worked 24/7 for the last - cannot remember exactly - 8 or 9 years). What gives? jaclaz

To be more specific, the grub4dos (and Firadisk and Winvblock) capabilities, are a "side effect". A "static" .vhd is nothing but a plain "dd-like" disk image with a 512 byte footer added. These tool DO NOT "support" specifically .vhd's, they are intended for and do support "dd-like" images. By pure chance (MS would call this "by design" ) a static .vhd - in the "eyes" of the mentioned tools - is the same thing (only it has one "unused" sector at the end). (and yes the format is actually the old Connectix one) Also, to put things in their historical perspective, in february/march 2009 neither of Firadisk or Winvblock were available (let alone vmlite). Some list/history: http://reboot.pro/1507/ Winvblock: http://reboot.pro/8168/ Firadisk: http://reboot.pro/8804/ jaclaz

See if you can find anything in here (this one actually needs duplicate .iso's - which you do not want): http://reboot.pro/9076/ http://www.rmprepusb.com/tutorials/multiisoimdiskautounattend http://www.rmprepusb.com/tutorials/firawiniso but since it was born to remove the "required CD/DVD" issue, it may contain the solution to this issue. First one uses IMDISK second one Firadisk, possibly the first one could be more suitable, even if slightly more complex to setup. jaclaz

Well, then I managed to just do something impossible. jaclaz