jaclaz

Naah, Wikipedia is the very basic info, mostly for kids . Real developers (besides drinking COKE) : http://uranus.chrysocome.net/coke.htm Talk in some kind of jargon that it will take you a few years to understand, you want an example of developers talk, you should peek on some mailing list, or github examples: https://github.com/tmm1/perftools.rb/pull/24 http://gcc.gnu.org/ml/gcc/2010-03/msg00222.html (and these are the easy to understand ones ) jaclaz

WHY guessing? Wouldn't researching be more reliable? POSIX is a Windows NT subsystem: http://en.wikipedia.org/wiki/POSIX http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows http://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem This is the "new version" of it: http://en.wikipedia.org/wiki/Windows_Services_for_UNIX (I have NO idea if this latter is 2038 compatible) PERL normally runs in the POSIX subsystem so it tests it (and not the actual NT). Well, actually I have worked on ANY Windows version, starting from 1.0, but NOT in the sense you seem to think the "developer" label has been given to me on MSFN, but I am NOT a developer, at the most I put a couple of lines of batch together (and PUSH "real" developers to do their work ) You must be joking. I am a dinosaur, one of the most advanced videogames I ever played has been (very recently) this one : jaclaz

Owww, come on : jaclaz

I don't get it. That article says that the QIC 40 is supported in Windows 95 (no more, no less). AFAICR the actual Colorado tapes were supported by both Win95 and 98 BUT the actual issue is specific to the QIC 40 model, see here: http://www.cwdixon.com/support/win98_support/backup.htm http://support.microsoft.com/kb/182624/en-us (right info, wrong reference ) in their usual simplicity the good MS guys made the .qic format change a bit between different versions of MSbackup: http://www.fpns.net/willy/msbackup.htm and later the 2K/XP version was completely different. http://support.microsoft.com/kb/305381/en-us So, your best option IMHO is to install a real Windows 95. OR try with a DOS program instead. (I presume some can still be found around) Some ideas may probably be got from this only seemingly unrelated document: http://h20000.www2.hp.com/bc/docs/support/SupportManual/lpg28247/lpg28247.pdf AFAIK the Linux FTAPE program is compatible. http://tldp.org/HOWTO/Ftape-HOWTO-6.html At the time "real" professional tape drives were SCSI, and for them we do still have an excellent proggy: http://www.datman.com/ is your SCSI or the "poorman's" floppy connected one? If this is the case you can try with a DOS program instead. (some can still be found around), like: http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=US&swItem=co156en&prodTypeId=12169&prodSeriesId=63951 jaclaz

Most probably it won't even actually crash, it will simply create/display/print/whatever "silly" dates, or, if dates are used for internal calculations, show/etc. "silly" results. jaclaz

Maybe is the same strange approach the WINFLP has/had? Something half-way between Longhorn and XP rather than between XP and Vista (with a touch or two of "XP Embedded") I vaguely remember having setup a couple of them, and they actually used if I recall correctly - in addition to F6 - a .XML file to add specific drivers. I am pretty sure that "basic" "no-dependencies" command line apps should be able to run in the booted Environment, just like they do with a Shift+F10 command prompt on a normal XP setup. All in all, to diagnose all that is needed is a set of copies of the MBR, though it is possible that to take them it is needed to interrupt setup. Something like: would do nicely. jaclaz

Well this confirms my guess that it was completely unlike "normal" (or maybe "Normal" just for you) and adds none of the info that I asked about. It's not really difficult. IF at any time during your "normal" procedure Disk Management is used, there are simply two cases (normally ): It will see that the last two bytes of the MBR are 0000 and will prompt you to initialize the disk, etc., etc. (see above post) It will see that the last two bytes of the MBR are 55AA and will do NOTHING. jaclaz

Tripredacus, IMHO you are failing to test or report correctly. (as you did on the linked thread). As soon as a DIsk (I mean completely 00ed disk) is opened in Disk Management, the Disk Management should ask you to "Initialize" the disk. When you click YES, this normally results in three DIFFERENT sets of writes to the disk first sector: the MBR CODE the Disk Signature the "magic bytes" signature 55AA Then when you create a partition on the disk, (let's for the sake of simplicity that you create a Primary partition) a single entry is written to the disk first sector: a partition table entry (or if you prefer MBR data) Then when you set the partition as "Active" or "Bootable", a single byte is written to the first byte of the partition table entry: 80 (still part of the MBR data) In other words, if before trying doing other things/different tests, you would simply 00 out frst sector of the disk and repeat the same exact steps you did here: possibly better describing them in more detail AND making a copy of said first sector after each subsequent "stage" of that procedure, we may have something to work on. Particularly if you could better describe the actual install procedure you are doing: AFAIK there is NOTHING like a "normal" Setup, what you are probably doing is to boot a PE of some kind (possibly a 2.x or a 3.x) and from it install the actual PosReady from it's .iso. (but this are mainly my guesses ) jaclaz

This seem to me "good enough": http://www.f2ko.de/programs.php?lang=en&pid=b2e But we also have an IDE for batch files : http://sourceforge.net/projects/batchcompiler/ And also a new thingy , Visualbatch : http://visualbatch.sourceforge.net/ The good ol' way: http://www.ericphelps.com/batch/samples/obfuscating.txt jaclaz

I'd expect (presuming Microsoft was telling the truth) that I'd still be using Windows 8 x128 by 2038. Only because the "idea" of having a PC with an exabyte of RAM is such a mind-boggling yet fascinating idea. And to add in the fact that it would likely take me 25 years to save up enough money to buy that much RAM... Or at least a motherboard with 1 billion RAM slots on it. Well, let's see what could happen in 27 years applying Moore Law and/or one of the similar related ones : http://en.wikipedia.org/wiki/Moore's_law http://users.hal-pc.org/~slcweb2/0MonthlyPresent/0403MooreLaw/0MooreLaw.html BUT take into account also Wirht's Law : http://en.wikipedia.org/wiki/Wirth's_law And Jevons' Paradox: http://en.wikipedia.org/wiki/Jevons_paradox Basically you will need to run a small nuclear plant to get the power needed for the PC on which you will write lousy posts on MSFN or the occasional e-.mail to your grand grandsons. jaclaz

WHY? You should as said check WHICH one will become CurrentControlSet and change ONLY that one (or use the given alternate app that will allow you to use the CurrentControlSet and resolve internally/automatically the addressing to the right ControlSetxyz) The whole idea of having two ControlSets is to have one that is (supposedly) failsafe. If by mistake you "botch" BOTH sets, you will have quite a bit of problems in fixing the issue you provoked yourself (i.e. otherwise a non-issue) jaclaz

You probably misunderstood. I know that in year 2038 - if still alive - I will most probably be still using 2K (or in the worst case XP). I was asking about you. And @Tripredacus , most probably we will be using Qemu 217.2 on an Ubuntu 408.25 "Wild Worry-free Wooing Wombat" with kernel 118.4.10 in order to run it on the AMINTEL i4886 1024bit processor. And of course should not skynet gain self-awareness in the meantime. jaclaz

CurrentControlSet does NOT actually "exist". When the Registry is ONLINE a LINK is made to EITHER of ControlSet001 or ControlSet002 (normally, but there may be many more ControlSets) depending on contents of the Select (Current) key: HKEY_LOCAL_MACHINE\SYSTEM\Select You can also use this app: http://reboot.pro/11212/ http://reboot.pro/11312/ that automatically does the "detection". jaclaz

Well, in the next 27 years this should become clear enough. But are you sure that in 2038 you will use a NTFS filesystem and/or a NT based system released some 30 years before? (Please raise your hand you peeps that run on a daily basis a CP/M machine.) The issue is known: http://en.wikipedia.org/wiki/Year_2038_problem it mainly affects Unix based OS (and conversely POSIX times) There are a couple places dedicated to this issue: http://www.deepsky.com/~merovech/2038.html http://www.codeproject.com/KB/bugs/The-Year-2038-Bug.aspx http://www.exit109.com/~ghealton/y2k/yrexamples.html In non-critical apps/OS/systems, in 2038 we will be able to use SETBACK approach: http://www.exit109.com/~ghealton/y2k/yrexamples.html#_OtherBad.WorkAround And "proper" NT is immune: http://www.exit109.com/~ghealton/y2k/yrexamples.html#_Native.Microsoft.Epochs 1601 Microsoft NT/2000 (Win32) n/a 100nsec ticks since 1601-January-01 for a range of about 29,200 years until roughly year 30,800 http://www.exit109.com/~ghealton/y2k/yrexamples.html#_Native.Microsoft.Ticks though "bad" programs may still behave "wrongly". jaclaz

WinsetupfromUSB is NOT "the ultimate solution to all of your problems". You have a specific problem (outside the scope of WinsetrupfromUSB) with a specific .iso. If you prefer WinSetupfromUSB provides an easy opton to add .iso's ALREADY KNOWN to be working with "default" or "standard" grub4dos )0xFF) or (hd32) mapping. It is not aimed to become the "ultimate multi-boot solution on USB sticks". READ (to get the idea of the issues that may be involved): http://reboot.pro/8944/ http://reboot.pro/5041/ Then: http://reboot.pro/14178/ http://reboot.pro/9570/ If you *need* grub4dos booting the HPStartSmart .iso start a new thread here: http://reboot.pro/forum/66/ It may be possible or it may be not, as per above. There is a report about version 8.3: http://reboot.pro/7868/ but cannot say if it will work with your version (and/or if the report was accurate) jaclaz

....and make it longer than 12 characters and make sure you insert "strange" non alpha-numeric characters and not a-z/A-Z ones. Examples: h1_1_@m_@_|33t_p@§§vv0rd ÿ00_vv0n*t_cr@ç#-m3 BTW, IcemanND's nice batch may be "bettered" (assuming you are on a 2K/XP or later NT based system): @ECHO OFF SETLOCAL ENABLEEXTENSIONS IF NOT "%1"=="" FOR /F %%A in ('type %~nx0 ^|FIND ":%1" ^| FIND /V "FIND"') DO GOTO :%1 Echo A suffusion of yellow ... GOTO :EOF :sorry Echo Sorry! GOTO :EOF :welcome echo welcome OR (to follow your original post): @ECHO OFF SETLOCAL ENABLEEXTENSIONS IF NOT "%1"=="" FOR /F %%A in ('type %~nx0 ^|FIND ":%1" ^| FIND /V "FIND"') DO GOTO :%1 Echo Sorry! GOTO :EOF :welcome echo welcome OR: @ECHO OFF SETLOCAL IF /I "%1"=="welcome" GOTO :%1 Echo Sorry! GOTO :EOF :welcome echo welcome jaclaz

Sure it's fine. BUT the scope of the exercise is NOT to clone a disk, it is to IMAGE it. So we need more space than source to allow for the "host" filesystem (which will necessarily be NTFS) structures (and have some slack space to concatenate partial image chunks if such an approach is needed). Since NTFS normally dedicates 12.5% space for it's structures: http://www.ntfs.com/ntfs_optimization.htm 500x1.125=562.5 represents the bare minimum, and 640 Gb is the next near "common size", allowing to manage one excess 50 Gb chunk, like in 562.5+50=612.5<640 (but normally on a modern system one has at least a couple of such 50 Gb "slots" free on some other disk, so we have enough space to manage "issues", should that arise) A 750 GB is "better" and a 1 Tb is even better for imaging a 500 Gb. Just for your interest, as long as there is not a geometry conflict (quite rare if not impossible today, as *all* disks use a 255/63 geometry) it is a perrfectly normal and possible to clone a disk to a bigger one, what you read was probably the atttempts of dozens of people that had no idea WHAT they were doing or were adviced by the same peeps that suggested saman0suke updating the firmware or putting the disk in the freezer. There *may* be issues when using one of those "newish" 4 Kb sector HD's, but I have not yet needed to do a "clone to bigger" on one of those. jaclaz

I would rewrite your above sentence as following: This way it should become clear to you what the issue most probably is. OEM's in some cases modify the actual XP install CD to adapt (or target specifically) to a given hardware they produce. Such XP install discs may NOT be anymore "generic" and won't be able (without further modification/fixes) to install on anything but the original hardware. BTW, the essence of an OEM license is that it accompanies the hardware and is licensed to be used EXCLUSIVELY on that hardware. jaclaz

A coin flip is anything that will give you (on average) 50% (or very near to 50 %) of probabilities: http://www.facade.com/coin_flip/ http://www.codingthewheel.com/archives/the-coin-flip-a-fundamentally-unfair-proposition S.M.A.R.T. or SMART: http://en.wikipedia.org/wiki/S.M.A.R.T. Play on words on normal meaning: http://www.thefreedictionary.com/smart http://www.synonyms.net/synonym/dumb See also : http://en.wikipedia.org/wiki/Flipism jaclaz

There is NONE (actually none that has ANY kind of reliability). The only meaningful data we have is from a (now getting a bit dated) google paper: http://labs.google.com/papers/disk_failures.pdf that proved beyond any possible doubt that the only tool you have, which is the S.M.A.R.T. technology (one that I personally call "D.U.M.B."), is substantially m00t and has NO actual capability of forecasting a drive failure reliably. The only things you can do are: keep them drives as cool as possible (this is the MAIN thing) power them with a "good" power supply unit reduce as much as you can the number of power on / power off cycles do a CHKDSK periodically (say once every month or so) after the CHKDSK, check SMART data , if Realloc counters have grown sensibly, change the disk drive, every nine months or so, flip a coin, if it's head, replace the drive, if it's tails, keep it until next coin flip (please note that on average and on a sufficiently big number of drives this approach will not produce results substantially different from a dedicated hardware parameters monitoring program and/or SMART based prediction) SMART readings are "mostly useless" in the sense that whilst a drive that starts increasing some of the few meaningful SMART parameters should be replaced as soon as possible (INDEPENDENTLY from the result of the coin flip), the amount of drives "simply failing" without any SMART error in advance is so big that the coin flip is a good enough approximation. There is no actual difference in the different tools/utilities, to write a given number of bytes the drive spin motor needs to do a given number of turns and the set of heads needs to travel back and forth a given amount of time. The only thing is of course whether your copying strategies do provoke a heating in the disk drive (intensive disk activity, like as an examle cloning a drive as RAW may increase slightly the temperature), but since you have a good cooling solution for them (#1 above: keep 'em cool) this is UNlikely to change anything. jaclaz

Naah, unless you freeze it, or shake it too much there is no chance that the "new" hard drive will ever be damaged in the procedures. The worst case is that your currently inaccessible hard disk will remain inaccessible, or if you prefer not any real worse situation than the one you are currenlty in, only you will have spent a few bucks for the "new" drive and actually "have" a "new" drive, entropy should not be much increased by this. jaclaz

I seem (vaguely) to remember that on first EVER execution of a WMI (or WMIC) query/command on a system the WBEM (whatever it is) is *somehow* "initialized". Maybe this is the case. http://ss64.com/nt/wmic.html Or maybe it is an Administrator/UAC/permission issue? Anyway, now that it works, run it like this: wmic path Win32_networkadapterconfiguration get /format:csv>C:\test\test.csv and open/import the resulting .csv file in *any* spreadsheet program. This way you will see easily all the info that is coming from the command and see which conditions you can use in the query and which fields are to be retrieved. Generic query syntax is: wmic path <wmi path> where <condition> get <comma separated fields you want to retrieve> jaclaz

Well, the freezer trick (if done properly) should NOT make things worse (or MUCH worse ). It simply WON'T do ANYTHING. It is mostly a myth, though it can work in a very limited amount of cases, it is NOT something that you should normally even THINK to do. But it is pretty much harmless. If there is a "botched" hard drive a NT system (that actually by default tries automatically to access/mount it) will be always slower/more sluggish when loading. This is also "normal". Together with the freezer trick there are various version of the other myth (that again as always happens does have some true basis) more generically (i.e. not necessarily related to hard disks) it goes under the name of "percussive maintenance": http://en.wikipedia.org/wiki/Percussive_maintenance http://www.urbandictionary.com/define.php?term=Percussive%20Maintenance I have not a Maxtor or Seagate drive of a similar type handy, and even if I had it I won't "shake" it to see if it does have something loose inside, but it is very possible that the head moves when the disk drive is shaken in a given direction, but please STOP shaking that poor disk anyway. If you have an exactly the same size disk (500 Gb tend to have the same exact size): http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=7552 you may want to try a "direct" (disk-to-disk) dd-like image, but cannot say which kind of issues may arise if you actually find a "really bad" bunch of "bad sectors" if this is the case a recommended app is this one: http://alter.org.ua/en/soft/win/bb_recover/ (still cannot say about it's functionality under 7) but since you probably can use a 640 Gb disk anyway and I presume that you value your (currently lost) data more that the difference between the cost of a brand new 640 Gb and the money you can get by selling it as used if it comes out as a non-feasible recovery, it's a bet that if I were you I would take. @allen2 Just for the record jaclaz does not use any particular "magic" , only a set of tools used in a proper manner. along the lines of proper procedures The nearest thing to "magic" that jaclaz happens to touch is his crystal ball, the one that is perennial foggy or out of tune and that he uses when torture fails to get proper info from people. jaclaz

Seagate peeps are very often in denial mode. http://www.essortment.com/5-stages-grief-16816.html It is also possible that the CAUSE of your problem was not the "usual" firmware problem but *something else* that by pure chance the "general reset" that this procedure implements healed. This is the idea of last sentence in point #1 of read-me-first: Set apart the original firmware issue it is evident by the number of posts from people that have "not affected" firmware, that the BSY or LBA0 situation may happen for a number of different causes, and seemingly this procedure fixes a number of these cases of "unwanted effects" even if the cause is not the same. jaclaz

Then there is no reason why it shouldn't work. Each and every keyword: corresponds to an available "format", i.e. a valid parameter of the /format:<keyword>. Can you try with some other of the keywords? Example of my output with RAWXML: C:\test>wmic path Win32_networkadapterconfiguration where "IPENABLED=TRUE" get Caption,SettingID /format:rawxml <COMMAND SEQUENCENUM="1" ISSUEDFROM="CINQUE" STARTTIME="08-30-2011T16:44:44" EVE RYCOUNT="0"><REQUEST><COMMANDLINE> path Win32_networkadapterconfiguration where "IPENABLED=TRUE" get Caption,SettingID /format:rawxml</COMMANDLINE> <COMMANDLINECOMPONENTS><NODELIST><NODE>CINQUE</NODE> </NODELIST> </COMMANDLINECOMPONENTS> <CONTEXT><NAMESPACE>root\cimv2</NAMESPACE> <ROLE>root\cli</ROLE> <IMPLEVEL>IMPERSONATE</IMPLEVEL> <AUTHLEVEL>PKTPRIVACY</AUTHLEVEL> <LOCALE>ms_410</LOCALE> <PRIVILEGES>ENABLE</PRIVILEGES> <TRACE>OFF</TRACE> <RECORD>N/A</RECORD> <INTERACTIVE>OFF</INTERACTIVE> <FAILFAST>OFF</FAILFAST> <OUTPUT>STDOUT</OUTPUT> <APPEND>STDOUT</APPEND> <USER>N/A</USER> <AGGREGATE>ON</AGGREGATE> </CONTEXT> </REQUEST> <RESULTS NODE="CINQUE"><CIM><INSTANCE CLASSNAME="Win32_NetworkAdapterConfigurati on"><PROPERTY NAME="Caption" TYPE="string"><VALUE>[00000008] Atheros L1 Gigabit Ethernet 10/100/1000Base-T Controller</VALUE> </PROPERTY> <PROPERTY NAME="SettingID" TYPE="string"><VALUE>{4E1252DC-1884-4B8E-BFF4-B016E79 0CCF4}</VALUE> </PROPERTY> </INSTANCE> </CIM> </RESULTS> </COMMAND> I have no idea why the CSV option is not working for you. Try checking contents of file %WINDIR%\system32\wbem\xsl-mappings.xml (if any): http://technet.microsoft.com/en-us/library/cc778755(WS.10).aspx http://technet.microsoft.com/en-us/library/cc784974(WS.10).aspx And if you have a %WINDIR%\system32\wbem\csv.xsl file. And if you have %WINDIR%\system32\wbem\ in path. (or try navigating to %WINDIR%\system32\wbem\ and run WMIC in it) jaclaz