jaclaz

A good idea would be to run a program *like* the good ol' SequoiaView to check what actually occupies the space: http://www.portablefreeware.com/?id=402 Also knowing the size of the disk and of the partition hosting your system would help. jaclaz

OK, let's clear some possibly wrong guesses. That message comes from the BIOS. (last character in the above is a full stop or period) It means that the BIOS cannot detect the hard disk at all. Possible causes of such message are: bad/unseated data cable <- more common than you might expect bad/unseated power cable <- quite rare bad (aged) PSU (i.e. simply not providing at boot time enough power on either the +5 V or +12 V rails <- also more common than you might expect failed soldering of the connectors (on either the motherboard or the disk drive PCB) <- rare, but it happens another bad (cold) soldering (on either the motherboard or the disk drive PCB) <- also rare another defect of *some kind* (on either the motherboard or the disk drive PCB) corruption of the BIOS <- very rare Other <- you never knowThe FIRST thing to try is: disconnect and reconnect the cables (both data and power) from the hard disk, and, in the case of the data connector also on the motherboard sideThe SECOND thing to try is: replace the data cable with another one surely workingThe THIRD thing to try is: disassemble the hard disk from that PC and - holding it in your hand while powering up the machine, feel if it's spinning up.The FOURTH thing to try is: try it in on another PC, either by directly connecting it to the internal connectors or using a USB adapter@Briansurvivedwindowsme Until you will have performed the above four tests and reported results, there is nothing that we can advise you. Please also post the EXACT make/model of the hard disk drive. jaclaz

Yes and No. The CRC32 hash of a .iso made with the -x switch is 0xFFFFFFFF, including BOTH (actually all 4 of them) the values of ExclCRC and AutoCRC. If you prefer the the CRC32 hash of the WHOLE iso is 0xFFFFFFFF. It is clear (or clear enough) that the 4 bytes of the AutoCRC value (last four bytes of the .iso) are an integral part of this calculation leading to 0XFFFFFFFF, and that this 4 bytes value is the - as defined above - *whatever needed to have "normal CRC32" of EVERYTHING before this value and included this value result in 0xFFFFFFFF*. The hackcrc32 app you mentioned is not seeemingly working in the same way, or it uses a different algorithm. If you actually try it (on a .iso stripped of the last 4 bytes) you will find out that it fails to produce a 4 byte value identical to the one that the -x produced, it instead produces an 8 byte value that, once appended to the .iso makes it having a value of "normal" CRC32 of 0xFFFFFFFF, but obviously this .iso results as CORRUPT in the MS CRC.EXE. The algorithm (whatever it is) that CRC.EXE uses is seemingly "better" than the one used in the hackcrc32 tool, in the sense that manages to provide always a 4 bytes value. The guess (which remains a guess) is that the algorithm used by the -x switch and by the CRC.EXE, *somehow* makes use of the 4 bytes value of ExclCRC and my guess (which is as good as anyone else) is that the actual "correction" to the "normal" CRC32 happens making use of both the 4 bytes value of ExclCRC and of the 4 bytes of the AutoCRC, as an example, let's say that the value in ExclCRC is the hash of all sectors (or bytes, or words, or whatever) up to a given address and that of AutoCRC is that of some other area(s) + the "complement" between this value and the final value of 0xFFFFFFFF. IF this is the case, the calculation of the actual value of AutoCRC is based NOT on the whole image, but rather on an area (or *whatever* ) "starting" from the value of ExclCRC. jaclaz

@bphlpt There are a number of people that - for whatever reason - think that it is "cool" to recreate an "original" .iso. Example: http://forums.mydigitallife.info/threads/54441-Restored-each-Windows-ME-version-files-to-ISO-by-CDIMAGE-2-39 Since the MD5 and SHA1 hashes of a number of original CD's/iso's have been published, these people attempt to re-build these images in such a way that they verify these hashing methods, besides the CRC32 one (which in the case of a number of .iso's is "corrected" by the use of the -x option, i.e. AutoCRC). This makes NO sense whatever under any practical point of view (as - as you correctly stated - a "collector" would want an original CD), i.e. the activity is totally futile, still it is well among what freedom allows , as no human being or living creature is actually hurt in the process of pursuing this (again, apparently senseless) goal. A more sensible goal is obviously, as I initially stated, to create a .iso capable of installing the OS (which is - or should be - the ONLY actual goal of an install CD/.iso). BUT, the sheer moment in which someone comes here, BTW slipping on a chocolate covered banana: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/put-down-the-chocolate-covered-banana.html and states something like: Because it is impossible to restore Windows 2000 (SP0 / SP1) without CDIMAGE 2.27. something must be done: http://www.imdb.com/title/tt0031971/quotes?item=qt0178026 in order to find out if the statement is accurate and if the (futile) goal is actually impossible to reach using another method or - as normally happens - it is perfectly possible. If you prefer, I am completely indifferent to the activity of recreating "original" CD's/.iso's, but sensible to the declared impossibility of the feat. jaclaz

Yep , that one is another one containing only partial (and partially wrong ) info. The idea is to (hopefully) get complete and correct info INSTEAD. Points are: there is not a sector with the ExclCRC and AutoCRC values appended to the ISO file but TWO sectors, one "inserted" after the directory structure and one appended to the end of the .iso [1]the "scope" of the AutoCRC value is "clear" and surely represents *whatever needed to have "normal CRC32" of EVERYTHING before this value and included this value result in 0xFFFFFFFF* the "scope" of the ExclCRC can only be guessed as *area to exclude from the calculation* but there are no real "proofs" that this guess is correct how exactly the ExclCRC val is used and calculated is to be found the CRC.EXE changes it's behaviour and can provide THREE types of output, if a valid AutoCRC value is found as last four bytes of the file that value is printed and the file is considered VALID, if a non valid AutoCRC value is found as last four bytes of the file that value is printed and the file is considered CORRUPT, if NO AutoCRC "label" is found in the last few bytes of the file the "normal" CRC32 is printedjaclaz [1] I already verified that if the file is truncated after the inserted sector this initial part by itself will give a CRC32 of 0xFFFFFFFF

Sure it is not. "%%B" in that case would be only "grub" as you have delims set to [sPACE] and tokens set to 1 and 2. Try with tokens=1,* <- the idea of giving you a reference is that you study the syntax, so that you can make changes yourself, but not "random" ones. Also you need quotes on both sides, like IF /I "%%B"=="grub for dos" GOTO :out jaclaz

Because it is needed to have "local reference time" correct in sector 16, absolute offset 0x833D. http://alumnus.caltech.edu/~pje/iso9660.html No, this sets the files folders timestamp AND the Volume timestamp BUT NOT the timezone ("offset from Greenwich Mean Time" see above). You mean that you don't trust my word for it? There is NO "signature stuff" in a 2K CD AFAIK, only in the NT 4.x ones. (the referenced post on BetaArchive is about NT 4.00 and CDIMAGE 2.28). jaclaz

To finalize this thread, I checked. The additional sector is inserted at the end of the "file/directory records" and before the first actual file/directory contents. Still remains to be understood what the "ExclCRC" data refers to. I'll see if I can find an explanation. jaclaz

To finalize this thread, I had some time to make a few tests. As expected, it is perfectly possible to recreate one of those images. There are two things that were not mentioned here or in the references AFAIK/AFAICR. It seems like there is the need to: set the machine time zone to "Pacific Standard" with Daylight savings disableduse besides the "normal" -nt -o -x switches, also the additional switch -y6The latter one is "strange" as: So, besides the "queer" usage of an obsolete version of the tool, there is also the "strange" choice of the -y6 switch. In practice without it a file/directory entry is not written at the end of a sector if the record ends exactly on last byte of the sector and thus the entry is shifted to the beginning of the new sector. jaclaz

And, in case after all grub4dos will be used, this might come handy: http://reboot.pro/topic/18783-release-cateditg4b-script-to-write-hex-values/ as a reference. jaclaz

@submix8c JFYI, some reference: http://www.911cd.net/forums//index.php?showtopic=17504 gsar may be a valid replacement (it is GPL and redistributable): http://home.online.no/~tjaberg/ and as well hexalter: http://kuwanger.net/misc/hexalter.shtml if the addresses are known. But these are still "third party" . jaclaz

But it's on the Wayback Machine alright: https://web.archive.org/web/20110601035232/http://emergency.cdc.gov/socialmedia/zombies_blog.asp BTW, proof that bureaucracy is very important even in case of zombie apocalypse: http://www.fema.gov/blog/2011-05-19/cdc-preparedness-101-zombie-apocalypse Zombie traffic police patrols are reknown to be very strict about driving without a driving license or failing to carry proof of identity . jaclaz

Normally (i.e. if the cause of the BSY is the original problem) all data remains accessible "as before". IF the cause of the BSY is another, the data recoverable may vary. But the answer to your question is "something else", what happens when you issue that command through terminal is that "user partition (data) is regenerated", i.e. the part of the disk that is accessible to the user is reset to "usable". That "partition" is at a completely different level (much lower) than the "partition" you see in (say) Disk Manager, it is the partitioning of the disk between "Seagate's Data" and "User Data". If you prefer, usually (say 95% or more of cases ) after the disk has been unbricked, it will appear exactly as it was before, though in some instances it happened that partition based recovery was needed (and was rather easily accomplished ), example: http://www.msfn.org/board/topic/145574-seagate-750gb-one-partition-is-raw-after-bsy-fix/ in an even minor number of cases, partition recovery was not possible or only partially possible , examples: http://www.msfn.org/board/topic/157671-need-help-with-data-recovery-on-hdd/ http://www.msfn.org/board/topic/157688-still-no-partition-on-seagate-after-successful-unbrick/ http://www.msfn.org/board/topic/170881-seagate-720011-malediction/ There is no real way to know in advance as we don't have a way to diagnose the actual cause of the problem. jaclaz

I was not trying to put anyone off , simply pointing out how I would approach the same problem. There is a degree of uncertainty in: and in the replies that may be provided by helping members , such as: I believe that if someone is going to put together a customized XP installation disk, he/she would also need to test it (several times) in a VM, so that making before an additional VM with the "unmodified" installation to have a quick and accurate comparison is a simple way, besides answering those questions, to troubleshoot issues (if any) with the modded installation by comparing it with the non-modded one. I reserve the right to fail to understand something and saying it, however. jaclaz

I really don't understand. Set up a VM (*any* will do). Get a XP "Gold" (SP0) or SP1a or SP2 source or SP3 source. Slipstream to it SP3 (if not already at SP3). Install it to the VM. Check the version of anything. I mean, besides whether the replies that you will get may or may not be accurate, what if you forget one app (or you cannot get a reply for it)? Having such a described VM install handy will allow you to quickly boot it up and check whenever you have a doubt. jaclaz

There is no way (with native commands) to modify a binary file if not using DEBUG. Something that I would not advise to my worst enemy. Anyway: http://thestarman.pcministry.com/asm/debug/debug2.htm Since you will be doing a multiboot CD/DVD, IF I would decide to not use one of the many suitable command line third party tools I personally would use grub4dos as bootmanager and use it also to patch SETUPLDR.BIN, but it would add yet another layer of complexity (if the complexity of the *whatever* you are putting together would not have been enough ). Or go back to the tradition and use BCDW, that if I recall correctly has a specific function for patching the setupldr.bin on-the-fly. jaclaz

...as well as the identity of the scumbag who took that photo of the police officer beating up the homeless guy, or of the government minister taking an envelope from a drug kingpin at a fancy restaurant... --JorgeA As often happens, unfortunately, the peep that wrote the title has not understood anything of the actual paper, which is essentially non-news. It is years (and pre-dates the advent of digital photograph) that in most cases you can link an image to the camera that took it. The concept is very simple, every camera has slightly different "signatures". In the case of film, the rolling mechanism scratched the film with a recognizable pattern or the lens had a scratch or a tiny optical defect that often allowed the match. With digital images, what is used is the pattern of "malfunctioning" or "errors/noise" of the sensor, this concept is as old as digital photography. What the paper proposes: is simply to use this known technique on public photos on the internet's social network accounts. Something that may well be "news" in the academic world, but that not represents in itself anything but a "way of use" of a known technology. The usually lower quality of images published on the internet+the various manipulations done either by the user before publishing or by the site (to resize/strip metadata/etc.) give to this technique a very low rate of certainty, and as such - as the authors correctly state - can be used at the most as a triage method: additionally (IMHO) the test image sets represent a scenario that is limited to a rather narrow hypothesis. The testing was made largely with a "many-to-many" comparison - as an example #3 is Flickr (93), Google + (70) - i.e. analyzing 93 images it was possible - still with a rather low confidence - to connect them to an account by finding the similar patterns on 70 "directly attributable" images. If either of the two sets is smaller (i.e. you fall in the few-to-many or one-to-many comparison) the accuracy lowers much. All in all an interesting use of known methods , but little more than that. jaclaz

That's an easy one , between April 27, 1997 and November 16, 1997: http://en.wikipedia.org/wiki/Area_code_425 as there was a transition period: ... but you know how the good MS guys may have privileged access to some information jaclaz

Sure, I know. The point I was trying to make is that the info in the above link is "partial". The ExclCRC and AutoCRC are not only inside an added sector at the end, there are TWO instances of them, one in a sector appended and one in a sector "inserted" at a variable address inside the .iso. If you prefer, UNlike what would have been "logical" the difference between a same .iso created with or without the -x switch is not just an appended sector. Just another case of the good MS guys using the secret 7 on the dice : http://homepage.ntlworld.com./jonathan.deboynepollard/Humour/microsoft-monopoly.html jaclaz

Possibly one of the hugest bumps in the history of msfn.org, but just checked, and the file is available through Wayback Machine: https://web.archive.org/web/20060915000000*/http://tacobell.iexbeta.com/longhorn/crc.exe Just for information, the output of CRC.EXE (version 3.0) on a valid .iso image created with cdimage.exe -x switch is: CRC Verification Utility, Version 3.00Copyright (C) Microsoft, 1992-1996100% completeAutoCRC signature for file TEST.ISO is 0x003D685EAutoCRC indicates the file TEST.ISO is VALIDit's output for the SAME .iso created without the -x switch (and that is 2 sectors, i.e. 4096 bytes, smaller) is: CRC Verification Utility, Version 3.00Copyright (C) Microsoft, 1992-1996100% completeCRC of file TEST.ISO is 0x8EE79268"Normal" CRC32 of the first is FFFFFFFF, whilst the one of the second is 8EE79268. In my test there is an inserted sector @Sector 321 and one appended at the end of the image. 322 sectors x 2048= 659.456 which in hex is 0xA1000. In other tests this "inserted sector" is in other places, like 0x6D000, or 0x29800 (I did only a few "random" tests to get the "feeling" of it). It would be interesting to understand how exactly this "inserted sector position is calculated/implemented, as at first sight it seems a "queer" behaviour, but of course the relevance of this piece of info for all practical uses amounts to 0 (zero). jaclaz

@vicvan Ok, just for the fun of it, I had a look at the matter. If you go here: http://www.betaarchive.com/forum/viewtopic.php?t=21823 AND read ATTENTIVELY the post by johnye_pt about hex-editing CDIMAGE 2.39 AND know that: AND know that 2K disks have not the "SIGNATURE" as the NT 4.00 have You have ALL the needed info to go ahead in your (futile) plan. After all it is not "impossible" at all (and not particularly difficult IMHO). jaclaz P.S.: some additional and only seemingly unrelated info posted here: http://www.msfn.org/board/topic/128122-crc-verifycation-utility-version-300/

You are welcome . jaclaz

With reference to this: http://www.microsoft.com/en-us/download/details.aspx?id=42774 which is related to this kb: http://support.microsoft.com/kb/2932079 it is IMHO not a patch for a vulnerability, it is a patch for generic stupidity. jaclaz

No. Yes. Learn about FOR /F with tokens and delims: http://www.robvanderwoude.com/ntfor.php http://www.robvanderwoude.com/ntfortokens.php You don't really need a temporary file. Namely: @ECHO OFFSETLOCAL ENABLEEXTENSIONSFOR /F "tokens=1,2 delims= " %%A IN ('bcdedit /enum all /v') DO (IF %%A.==identifier. SET %%A=%%BIF %%A.==description. SET %%A=%%BIF /I %%B.==grub4dos. GOTO :out):outSET identifierSET descriptionPAUSEIf you really want to create the text file, replace the FOR line with: bcdedit /enum all /v>C:\List.txtFOR /F "tokens=1,2 delims= " %%A IN (C:\List.txt) DO (jaclaz

JFYI: http://www.techtangerine.com/2009/06/02/ten-reasons-why-cloud-computing-is-a-bad-idea/ jaclaz