jaclaz

For NO apparent reason : I wonder WHICH could be next MS product hosted in the "lower world".... jaclaz

No, maybe there is a misunderstanding, my bad . The page: http://msdn.microsoft.com/en-us/library/windows/apps/hh464942(v=vs.85).aspx has ALREADY had it's contents removed, but it still titled "Dev Center - Metro style apps > Docs", I said "quickly" because they could remove it (without the link to the following *anytime*). What I find interesting is that the above page is linked on the mentioned: http://winrt.codeplex.com/ as a hyperlink titled "Windows Runtime" Since I presume, that apart form the folly of using something called "Visual Studio 11 Ultimate" the good Raffaele Rialdi knows what he writes, I found queer that there is not any mention of "WinRT" or "windows Runtime" on the new pages: http://msdn.microsoft.com/en-us/library/windows/apps/br211386.aspx http://msdn.microsoft.com/en-us/library/windows/apps/hh974576.aspx if not in the latter as: I would also like to highlight the BIG NEWS (still on this latter page): "Apps can talk to each other", I mean WOW, it's not like DOS anymore! Please note how the above page is "in theory" targeted to "developers", I wonder about the "qualifications" that actual developers must have to actually *need* such a technical explanation as "You don’t need to know anything about the target app other than its declared support for the target contract – it just works." It must be a joke of some kind , though I completely fail to get which part is the funny one jaclaz

Good This is strange. Unless the disks are somehow listed in BIOS as 0/2/1. I mean the menu.lst I made for you is: Can you try the following? Choose "commandline" (or press "c") Then issue the commands: root (hd0,0) [ENTER] chainloader /bootm [TAB] It should autocomplete to "chainloader /bootmgr". Try again with the other two disks first partition, i.e. repeat the sequence changing just the number of the disk root (hd1,0) and root (hd2,0) Yes. Yes, but you will need to edit the menu.lst file to remove all entries but the one you found working. To clarify (and for the record): Right now what you are doing (to boot Windows XP) is the "normal" way for XP, i.e.: NTLDR->BOOT.INI->Windows XP what you are doing (to boot Windows 7) is: NTLDR->BOOT.INI->grub4dos->menu.lst->BOOTMGR->\boot\BCD->Windows 7 This is NOT what we initially hypothized that was: For Windows 7: BOOTMGR->\boot\BCD->Windows 7 For XP: BOOTMGR->\boot\BCD->NTLDR->BOOT.INI->Windows XP If you prefer, what was planned was to have BOOTMGR as primary bootmanager (and direct bootloader for Windows 7) and NTLDR as bootloader for XP, what you are having now is instead having NTLDR as primary bootmanager (and direct bootloader for XP), grub4dos as secondary bootmanager and BOOTMGR as bootloader (for Windows 7). Of course, since it is working, you can "stay as you are" . jaclaz

A PE is a Pre-install Environment, as a matter of fact BOTH the Win7 install DVD and the "recovery CD" are a form of PE, to be exact a PE 3.x: PE 1.x <-based on XP/2003 sources PE 2.x <-based on Vista /2008 sources PE 3.x<- based on Windows 7/2008 R2 sources I don't know how exactly a Windows 7 "recovery CD" would behave. I like to give personalities to CD's. These are the 2 current possibilities, as I see it. The Windows XP install CD is a sort of good, well meaning guy, possibly a bit clumsy, like: ok, let's see what I have to do I see, I'll format this partition Ok, now I am copying to it the install files Ok, now I'll make a brand new BOOT.INI with an entry to boot the XP once installed Temporarily I will add an entry to boot the install at reboot Ok, now I change the bootsector (I don't really like doing this but MS makes me do it ) Ok, now i'll set everything for next reboot Hmm, let's see if I everything is OK ooops , I seemingly did *something* I should have not done, let me delete the install files and revert the BOOT.INI removing the install entry The Windows 7 recovery cd is more like an angry, nasty little supponent bastard: Ok, let's see what the heck this moron did to an otherwise innocent Windows 7 install Ha!, the demented guy somehow rewrote the bootsector, let me fix it Not only he did this but he also has an aborted installation of XP (that old scum) Let me delete any trace of that install and do *something* that will prevent it running again I wonder how the good MS guys didn't gave me an arm and a hand, I would have liked so much to slap the id*** user in the face, hard So, yes, next step is to add to the current BOOT.INI the line: c:\grldr="grub4dos" and add grldr in ROOT of the C: drive. Then try installing again. At reboot, choose the grub4dos entry. at the: grub> prompt type: chainloader /bootm and press [TAB] key, it should autocomplete to: chainloader /bootmgr press [ENTER] then type: boot press [ENTER] and you should be back to Windows 7. This way you can examine the system after the XP install failed but WITHOUT having run the "recovery CD", i.e. understand if the install files/directories are deleted by the XP install itself or by the following "recovery CD" boot. jaclaz

Yes and no. The partition table is made of 4 (four) entries, each 16 bytes long. So if you do not want to change the first partition, you need to leave alone the first 16 bytes, I fail to understand the reference to 11 BUT, the PTtable is THEORETICAL ONLY in the CHS part, IF you exceed the CHS limit. The max value that you can sencefully express in a MBR Cilynder entry is 1,023. Since you are beyond the CHS limit: becomes (when you write to a MBR Patrtition Table entry: If you check the PT_Entry_#0 and PT_Entry_#1 sheets, you will easily understand WHY this happens . Newer OS will write the above as: Either should do. In layman terms, you are writing values that mak the OS understand that the CHS addressing is m00t and that it has to use the LBA addresses only, should - for any reason - the partition ID be overlooked. jaclaz

Allow me to disagree (partially) with this: Making use of more powerful hardware is what SHOULD have been done, NOT what HAS been done (particularly by Adobe, they have used this powerful hardware to add more and more bloat to their apps INSTEAD of having them work faster/better). Get Adobe PDF Reader: http://get.adobe.com/it/reader/ (36,94 MB) 10.1.0 <- not even the fatter one, the Adobe Reader X 10.1.3 is a whopping 51.95 MB (+an optional 22 Mb of Google Chrome) and compare it (honestly) against: http://www.foxitsoftware.com/Secure_PDF_Reader/ (14 mb) They USED to make a "lean" thingy, see: http://www.oldapps.com/foxit_reader.php see the same "progresses" made by Adobe: http://www.oldapps.com/adobe_reader.php and compare with: http://blog.kowalczyk.info/software/sumatrapdf/free-pdf-reader.html (2,4 Mb) And of course the nice Krzysztof Kowalczyk is on the same trend: http://blog.kowalczyk.info/software/sumatrapdf/news.html (almost anything since version 1.2 is "added features" that are mostly unneeded or "forced upon" by the changes in usage of the "main" tools) jaclaz

Are you positive that you used bootpart correctly? Can you post the output of the boopart command (run without parameters)? It's strange, it should have worked Sure it did not, NTLDR cannot boot a Windows Vista or 7. Well, this of course makes no difference. Another way . Download the attachment. decompress the files grldr and menu.lst in root of first disk.first partition (the XP volume) add to the BOOT.INI the line: C:\grldr="grub4dos" reboot and choose that entry. At the grub4dos menu try all the entries. Whilst first one may fail, the other two should both work jaclaz g4d_for_Roffen.zip

This is strange. It is possible that you are falling into a queer issue that was found about DIsk Management differences (between the Windows XP and the 7 one, connected to cylinder boundaries) but it's "queer", such a problem should have surfaced also the first time. Are you positive (same size/label) that it is actually the same volume? But yes, this is normal, since there is not "yet" a Registry (for the XP, nor a migrate.inf), the drives are assigned letters with the default scheme, which is, if I recall correctly: assign C: to first primary partition of first disk assign later letters to any first primary partition on later disks assign later letters to logical volumes inside extended on first disk assign later letters to logical volumes inside extended on later disks assign later letter to other primary partitions on first disk assign later letters to other primary partitions on later disks So the partitions that you see under Windows 7 as C/H/F/D should become in XP setup C/D/E/F It seems like *somehow* the setup assumes that first stage has already been run. But when you actually run the text mode part of the setup, can you see on the blue screen (at the bootom) the copying of files? Can you try describing in your words what happens during the text mode part? Well, starting from post #17 You should have had that setting disabled. Please do so and leave it disabled, or anyway set the windows 7 to have it's pagefile ONLY on the C:\ drive. That is an idea alternative to the answer (that I am still missing) to this question: If I get it right after the failed attempt you repair the 7 with it's install DVD to be able to boot again, and I wonder if this latter procedure *somehow* is connected to the issue. jaclaz

Oww, comeon . Get the spreadsheet. Open the sheet PTtables. Enter in cells F4:H4 the CHS geometry of your card: Enter in cell D10 the partition ID (optional) Enter in cell E10 the Active status (optional) Enter in cells F10:H10 the Beginning of the partition in CHS (0/1/1) Enter in cells I10:K10 the end of the partition in CHS (1022/15/63) Enter in cells P16:Q16 the LBA start and end addresses (which you can read in cells P10:Q10 Enter in cells M22:N22 the Start sector ad the Num sectors (ehich you can read in cells M10:N10 or in cells M16:N16) Now go to sheet PT_to_MBR and enter in the cells in row 30 the values you have tested and verified in sheet. Now, compare the cells in the upper part of the sheet with a view of the MBR of your CF card. I took the liberty to make the above, so please attach a file named CHS_LBA_v2_D_CF_16Gb_SFE.xls. In case you wonder the naming convetntion is : CHS_LBA_v2 <-name of the base file D<- Doveman CF_16Gb <. CF card 16 Gb SFE <- Spoon Feed Edition jaclaz CHS_LBA_v2_D_CF_16Gb_SFE.zip

Well, there shouldn't be any other issue. I mean, the CHS geometry has relevance only for "booting", once this has happened (AFAIK) anything in a Windows XP or 7 is "LBA". The idea of getting you familiar with my little spreadsheet was actually that of giving you a (valid ) tool to design yourself your experiments. With it and a disk editor (I like and use Tiny Hexer) and possibly using my Structure viewer scripts: http://reboot.pro/8734/ you have no actual need for MBRbatch/mkimg and you can carry your experiments directly on the CF card ... jaclaz

You might want to rephrase the question, as is it might imply that they actually know what they are doing . So I wouldn't focus on what the intend to do, but rather on what they are actually doing (mindlessly) which yes, it is the depauperating of the Win32 codebase, IF "third party developers" are demented enough to follow this lead. Any developer in his right mind won't even touch something called "Visual Studio 11 Ultimate", example: http://winrt.codeplex.com/ Yes, even words have their weight, and "ultimate" is a marketing adjective that is suitable to a game, or maybe to a graphic card, not to a developing environment..... Now, go QUICKLY, before they change iot again here: http://msdn.microsoft.com/en-us/library/windows/apps/hh464942(v=vs.85).aspx and then go where you are redirected: http://msdn.microsoft.com/en-us/library/windows/apps/br211386.aspx then go to the "What's a Metro style app?": http://msdn.microsoft.com/en-us/library/windows/apps/hh974576.aspx Now, go and find on all the huge MS knowledge base a basic illustrative article that also suggests you how you should sell your app. Then try making 1+1. As I see it, it is - as always - about world domination and stuff like that, they want to get some fee for marketing your product.... jaclaz

NO. You must set settings so that you see both hidden and system files. You want to have "Hide protected operating system files (Recommended)" UNchecked. You should also have normally in root (additionally): pagefile.sys (the page file) $Recycle.bin (the Recycling Bin) System Volume Information (another system/hidden folder) and probably quite a few other files that do not show in your screenshot. OR try doing another thing. Open a command prompt and in it issue: CD /D C:\ [ENTER] DIR /AS [ENTER] and DIR /AH [ENTER] (the above list System files and Hidden ones, respectively) jaclaz

I don't think that there is any particular issue with VDK under Windows 7 (excapt usaul UAC and stoopid driver signing) , but MKIMG/MBRBATCH (the "standard version I wrote) won't work anyway because they use a little .COM executable (and support for .COM files have been removed, if I get that right). You coud see if the "updated" version by Lancelot works (it should): http://reboot.pro/5000/ http://reboot.pro/5000/#entry45422 jaclaz

Maybe (and modestly) if you open the first sector of the \\PhysicalDriven with Tiny Hexer and apply to it my viewers, it might be easier to understand the contents. OR get HdHacker, save a copy of first sector of \\PhysicalDriven, compress it to a .zip and attach it and I'll have a look at it. jaclaz

I am simply trying to put your system in the EXACT SAME situation it was when you succeeded installing XP. The Setup process, on a "completely" clean system works like this (simplified): the partition is formatted. The NTLDR and NTDETECT.COM are copied to ROOT the install files are copied to $WIN_NT$.~BT and $WIN_NT$.~LS a copy of the bootsector is made in $WIN_NT$.~BT (invoking the SETUPLDR.BIN INSTEAD of NTLDR) a BOOT.INI is written pointing to this latter copy of the bootsector c:\$win_nt$.~bt\bootsect.dat="Windows XP Installation/Upgrade" end of firs phase and reboot At reboot, the SETUP is booted NOT anymore from the install media but form the internal disk, then the setup does it's job, deletes the $WIN_NT$.~BT and $WIN_NT$.~LS and writes to BOOT.INI the "normal" XP loading string, in your case multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Windows XP Professional" /fastdetect On a "second" install, the behaviour is exactly the same, but step #5 above has to deal with a pre-existing BOOT.INI. Since you reported that after a failed reboot after the first stage the contents of the BOOT.INI are: multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Windows XP Professional" /fastdetect AND NOT: c:\$win_nt$.~bt\bootsect.dat="Windows XP Installation/Upgrade" I am suspecting that *something* is preventing the SETUP from editing the pre-existing BOOT.INI. Since you originally had not any BOOT.INI and it worked, and now that you have one it doesn't work anymore, the obvious step is trying again without any BOOT.INI. BUT, still something is not right. The setup (first stage) does create the $WIN_NT$.~BT and $WIN_NT$.~LS folders. Have you also checked on the "H:\ drive "? (or, better on "all" drives?) the location where these directories are made is - if I recall correctly - "automagically" determined by the Setup. These files are deleted after the second (GUI) phase, so if you never get to it, they should remain there (and possibly cause issues). Which means (like a PE of some kind) have you available when you, after having completed the first phase and you cannot boot anymore because of the error, you need to re-access the disk? Alternatively to the above, and provided that you stil have currently the grldr in root of C:\ and that your BOOT.INI is still: and you try again to install XP, at reboot after first stage you should be able, by QUICLY press the arrow down key, to access the BOOT.INI choices and chiise the grldr one. The result should be a command prompt like: grub> can you confirm this? jaclaz

Yes, AFAIK -+- (+ in the middle) was the only availability of the package, it was designed originally to avoid possible polarity exchange when assembling the board. jaclaz

Let's see if we can clear the "math" aspects. The partition table in the MBR says that you have two partitions. #0 07 00 0 32 33 12 223 19 2048 204800 #1 07 80 12 223 20 1023 254 63 206848 976564224 The above data is expressed in sectors (i.e. you multiply them by 512 to have bytes). So you have: 2,048 "unused" sectors 204,800 sectors used by first partition 976,564,224 sectors used by second partition 2,048+204,800+976,564,224=976,771,072 sectors x 512 = 500,106,788,864 bytes <-this is the theoretical size of the whole disk (and of the image) Addresses in the MBR are expressed in sectors and relative to the beginning of the disk. Addresses in the PBR or bootsector are expressed in clusters and relative to the beginning of Volume (in your case, like in, say, 99.99% of cases, your filesystesm uses clusters 4,096 bytes in size). This means that a cluster is 8 sectors. On your volume "range of size" the NTFS by default will place the $MFT at cluster #786,432. 786,432 x 8 = sector #6,291,456 but since the volume starts @ (2,048+204,800)=206,848 when you access the whole disk or the image, it will be on sector (206,848+6,291,456)=6,498,304 Still by default, the $MFT Mirror is placed at 1/2 (one half) of the Volume. So - seemingly- @ 976,564,224/2=488,282,112 which corresponds, when you open the whole disk or image to 206,848+488,282,112=488,488,960 But the above is "wrong", because there are two things I omitted: since it is an address inside the volume, it has to be accessed in clusters there is always one sector after the volume but inside the space reserved for it dedicated to the backup of the bootsector In reality, the volume can be at the most 976,564,224-1= 976,564,223 sectors, which, in clusters means 976,564,223/8=122,070,527.9 clusters So, if you do 122,070,527/2=cluster 61,035,263,5, and in bytes 61,035,263 x 8 = 488,282,104 bytes. Consequently the %MFT mirror should be @ 206,848+488,282,104=488,488,952, or, more simply, one cluster before what you would expect by doing the simplified calculation. I hope the above explains it all . I'll check the new file extracted and let you know. Edit: quickly checked, I now see where the problem is . You are continuing to "mix" between the "sectors" and "bytes" fields of the datarescuedd tool. I asked you the SAME range you had already posted that in bytes was (the datarescuedd uses bytes in filenames): [3326976000-3332096000], but what you now posted is: [170341171200-170603315200] You evidently had issues of some kind with datarescuedd. You have a PARTIAL image. We are doing a "Clone", so if the original is 976,768,065 sectors or 500,105,249,280 bytes, the copy, strangely enough, has to be the EXACT same size. Go back to square #7: and this time READ the post and the given links. In explorer the size of the image MUST be (Properties) EXACTLY 500,105,249,280 bytes. Or if you need to do partial images, the re-assembled file MUST have the same exact size.... Still there is an inconsistency with the theoretical size as calculated from the MBR data, but that could be irrelevant or caused by some miscaòculation/corruption, all the other data seems like "consistent". jaclaz

Well , it is entirely up to you, but I would guess that your brain has got to 80 + years in perfect working order EXACTLY BECAUSE you have used it intensively before . Come on, giving up is NEVER an option! You can do it! Go, Roffen, Go! *\O/* | / \ But there is something that does not sound "right". You should have in ROOT (i.e. C:\) : C:\BOOTMGR <- this is a file, possibly around 380 Kb in size C:\boot\ <- this is a folder, containing a file called BCD and other directories/files (local languages) Compare with this: They might be "hidden" files, and you have to set explorer to show them. jaclaz

NO. Please re-read my previous posts. The Windows 7 uses the BOOTMGR/\boot\BCD (that you have now only on the WIndows 7 disk) The XP uses the NTLDR/BOOT.INI that you have now only on the Windows XP disk. Your next step should be to have both disks visible, with the XP boot disk first in boot sequence, boot the XP and from it copy from "drive 1" to "drive 0" (the XP drive is now "C:\" and the Windows 7 will get another drive letter): BOOTMGR <- this is a file \boot\ <-this is a directory containing several files, including one named simply "BCD" Now we need to make an "intermediate" step (to make sure we have a way out if needed ).. Get bootpart from here: http://www.winimage.com/bootpart.htm unzip in a directory like "C:\bootpart", open a command prompt, navigate to it and run just "bootpart" with no arguments. You will get an output similar to this: C:\BOOTPART>BOOTPART Boot Partition 2.60 for WinNT/2K/XP (c)1995-2002 G. Vollant (info@winimage.com) WEB : http://www.winimage.com and http://www.winimage.com/bootpart.htm Add partition in the Windows NT/2000/XP Multi-boot loader Run "bootpart /?" for more information 0 : C:* type=6 (BIGDOS Fat16), size = 1044193 KB 1 : C: type=a (OS/2 Boot Manag.), size = 8032 KB 2 : C: type=5 (Extended), size = 8032 KB 3 : C: type=7 (HPFS/NTFS), size = 8001 KB 4 : D: type=6 (BIGDOS Fat16), size = 261104 KB 5 : D: type=5 (Extended), size = 769024 KB 6 : D: type=7 (HPFS/NTFS), size = 102384 KB 7 : D: type=5 (Extended), size = 369664 KB 8 : D: type=7 (HPFS/NTFS), size = 369648 KB 9 : D: type=83 (Linux native), size = 296944 KB The XP disk will be the one with the asterisk, and the Windows 7 disk will probably be "D: " and the partition something like "D: type=7 (HPFS/NTFS), size = <the size you made it> KB" Jolt down the number on first column correspondent to the volume on which 7 is installed, let's say that this number is 5. Now run bootpart as follows: bootpart 5 C:\Windows7.bin "Windows 7 disk" It should do two things: create a 512 byte file C:\Windows7.bin add in BOOT.INI an entry like "C:\Windows7.bin="Windows 7 disk" Now, if you reboot, you should be able to choose the Windows 7 entry and boot the Windows 7. Please try and report. jaclaz

Doesn't seem the author thought he had succeeded. Yep , but the conclusion is NOT that one, that is a "final question", actually just some poking at the good Linux guys on reboot.pro . The conclusion is ABOVE that. And it says: Curious indeed. The device is needed to zero out any output file of dd. But the simple fact that it's needed to include it makes the executable more complex, and also shows the shortcoming. How about /dev/random? Yes, NT supports piping, and a Windows port of dd likely also. But the ecosystem mainly doesn't. So where can I pipe from/to? A mayor strength of dd (and most commandline tools) in *nix is that it can be piped with many other tools, adding amazingly much functionality. Want to fill a disk with 0xFF?cat /dev/zero | tr "\000" "\377" | dd of=/dev/sdaIt's all just available. About zero and random, see here : http://www.ltr-data.se/opencode.html/#ZeroDrv You can pipe dd to gzip under NT allright, that is what you originally posted . And if you read attentively the thread, you wll also see how I advocate the need of a NT version of mkfifo... Now , this is not intended as a NT vs. Linux debate, rest assured that - limited to dd-like and connected operations, I know enough of both "worlds", and know which environment is "better" or "more convenient " to carry on the small tasks I normally need to do, and use the one or the other as I see fit.. jaclaz

NO nagging at all , I overlooked your previous few replies, so it's a good thing that you bumped this. Let's see waht happens with the 16 Gb card, you said: This may be a piece of relevant info (the different way the card is seen by the BIOS). OT, but not much, years ago there was a tool to change the status of CF cards (at least of some types of it), this is JFYI, do not even THINK of trying that tool (ATCFWCHG.COM): http://www.thinkwiki.org/wiki/Compact_Flash_boot_drive This may well be caused by that "removable" setting (in combination with that pesky BIOS: Now, on the 16 Gb one: But also: 31227840 sectors in grub4dos. 31227840*512/1024/1024=15247,96 31227840*512/1000/1000=15988,65 <- the BIOS is seemingly using x1000 for Kilo and Mega. The fact that the BIOS sees an actual LBA geometry is a good thing, though I would anyway try first with a "wholly inside" first CHS partition at first. A good number could be 1024*16*63=1032192 sectors x 512 = 528482304 <- this is the size of the file to be given to MBRBATCH/MKIMG. Use a FAT 16 (06) type at first, then try 0E (by only changing the relevant byte in the partition table) with a hex/disk editor. Rest of procedure is the same. You may want to get my little spreadsheet here (get the "newish" version attache dto post #10): http://reboot.pro/2959/ and play a little bit with it.... jaclaz

A resource for the good ol' times lovers : http://www.minuszerodegrees.net/ Specifically: http://www.minuszerodegrees.net/images3/floppy_crossover_cable_wiring.jpg jaclaz

To avoid having the filter/driver? NO. To avoid downlaoding 1 Gb to actually a bunch of needed bytes? Yes. Looky here : and another way to do the same: http://reboot.pro/13049/ jaclaz

And this is what is currently escaping me , the sequence of actions that you reported - once reversed - should have no consequences in re-installing the XP (that is if it worked first time). (attempting to do so on the unformatted drive AND with it holding the Windows 7 pageflile may) Yes, we are. What actually happens is that a couple of directories, namely: $WIN_NT$.~BT - the boot folder $WIN_NT$.~LS - installation files folder are created (normally on the Active partition, i.e. C:\) these folders contain the actual installation files. The BOOT.INI file is changed during the installation to boot (for second part) from these folders, a line similar to this is added (and made default). c:\$win_nt$.~bt\bootsect.dat="Windows XP Installation/Upgrade" Now, having formatted (BTW right now you have formatted it from the booted Windows 7, did you do this the first time or from within the XP setup?) nothing in the logical volume may have become "sticky" (and thus change the behaviour of the XP setup). So it must be something on the C:\ partitiion. Either the BOOT.INI or the two folders created by the previous install. Check that you have no $WIN_NT$.~BT nor $WIN_NT$.~LS folder. Delete the BOOT.INI. Try again installing. The fact that you reported having the multi(0)disk(0)rdisk(0)partition(4)\WINDOWS line might mean exactly this. The BOOT.INI was changed to it's "final" version by the initially successful install and for *any* reason, it does not the needed change during subsequent attempts to install, possibly a NTFS permission issue... No, actually it is the newest version among the "release ones", and NOT the latest-latest which is ALPHA. jaclaz

Well, the referenced thread contains links (and also personal opinions ) on several ports of dd for windows, including a few ones MUCH "simpler" (and "smaller") than the CYGWIN version, so, not only it is perfectly possible but it has already been done, by several people, including - curiously a version that includes a /dev/zero device and of course piping is perfectly posible on NT systems. I am clearly missing your point. jaclaz