jaclaz

Another happy bunny jaclaz

I see. Get latest grub4dos from here: http://code.google.com/p/grub4dos-chenall/downloads/list Expand with 7-zip two files: grldr menu.lst to root of your boot drive (usually C:\) Copy to root of the same drive the .iso (I will call it "acronis.iso") Add a line to boot.ini: C:\grldr="grub4dos" Edit menu.lst adding to it: title Acronis find --set-root /acronis.iso map /acronis.iso (hd32) map --hook chainloader (hd32) or title Acronis find --set-root /acronis.iso map /acronis.iso (0xFF) map --hook chainloader (0xFF) Try it. jaclaz

Can you better explain/describe what you want to do? (I cannot understand it from your post ). jaclaz

It is a possibility, only trying to find a reason for the mentioned "/A (default)", BTW DOS 7 comes AFTER NT and before 2K. jaclaz

Well, that seems to apply to MS-DOS 7. The MS resource seen before: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/copy.mspx?mfr=true is about XP. The one I cited seems like being NT4 and 2K "oriented": http://ss64.com/nt/copy.html (though as said it is possible that is alltogether "wrong", it does look similar to an actual output of a "COPY /?" ) Since it is not the first time that a "common" program syntax changes dramatically between one version of the OS and the other, it is still possible that NT4/2K behave differently. I have found another "hits" for " /A : ASCII text file (default)": http://www.bat-to-exe.com/batchcommands/copy.html that seem like not coming from the same SS64 source. @tomasz86 Why don't you simply try with a few files? jaclaz

Well, the most straightforward IMHO is Qemu (+Qemu Manager) stiil free: http://www.davereyn.co.uk/download.htm A Virtual Machine, besides being "Virtual" is a "Machine", sporting it's own (Virtual) hardware, so you need to have in the OS you are going to install (the XP in your case) the actual drivers for the Virtual Machine Hardware. Obviously all VM's have drivers for their hardware for XP, the advantage of Qemu is that it uses "standard" hardware for which the drivers are already inside the XP CD and you don't have to add anythng else. Please note how Qemu is/will be slower than more "optimized" VM's, like Virtualbox or Virtual PC, but in this specific case speed (or lack of it) won't be a problem, when compared to the simplified setup. The actual advantage of Virtualbox and other VM's is that it is easier with them to "exchange" data betwenn the VM and the "real" machine, as they provide some "extensions/apps" to that effect. Basically the idea is the following: you install Qemu (+Qemu Manager) you create a new virtual hard disk for it (it is a guided procedure) a size of 5 Gb should be adequate do use the RAW option as format for the virtual hard disk. you add the .iso of your XP CD as cd-rom device for the VM you select it as first boot device you start the VM and install XP in it "normally". you shut down the VM you mount the virtual hard disk through a hard disk image mounting program, IMDISK is advised for your case. you copy to the mounted disk image all you need, like nlite, the SP3 etc. you unmount the Virtual disk, start the VM and operate "normally" in it slipstreaming the SP3 and nliting whatever once you have created the .iso you test it in another VM until you are satisfied by the result Once virtual tests are OK, you burn the .iso and test it on the "real machine". jaclaz

Yes, the way the filter driver works is that one, more than the Registry device class, it would be interesting to know what happens with dd --list or Winobject. I.e. if the actual partition/drive gets something like \DeviceHardDiskVolumen or something like \Device\Harddiskm\DP(x)0-0+y Still it should mean that *somehow* the video drivers include a filter driver for mass storage. The behaviour you experienced, if I get it right, it is that of the reversedummy.sys, i.e. make an otherwise "fixed" USB hard disk become a "removable" device. Queer. jaclaz

Yep, I was not doubting it in the least , only re-marking that our good FreeDOS friends have not much "order" or "tidyness" in what they release. As soon as the good guys at reboot.pro will have finished playing with the board in order to make it "better" (please read as "ruining senselessly an otherways perfectly working setup to add some completely unneeded eye-candy" ) you will be able to have a look at what I needed to do in order to get a "right" SYS.COM. Here is a google cache: http://webcache.googleusercontent.com/search?q=cache:W6Y1ReYKsDsJ:reboot.pro/15123/ Fixed (seemingly): http://reboot.pro/15123/ After my little odissey (and probably somehow thanks to it ), the file was fixed, thanks to the good FreeDOS guy , and the current version (august 10, 2011): http://www.fdos.org/kernel/sys/ has also RX-DOS and DE (stoopid Dell RMK): About Volume track, sure , that key is useful to set it in "your own" Win9x/Me, I was trying to say that most people won't have it, and thus you can easily get an image (or bootsector) with "absurd" OEM field contents (and the original MS floppy image mixup is a proof of how common this can be, basically any "MS-DOS floppy" made on XP the "standard way" will have such a botched OEM). jaclaz

Since you have the original XP CD and it's key, advised is to temporarily install it on any VM (for some reasons I use Qemu+Qemu Manager, but any of Virtual PC, VmWare, Virtualbox, etc. will do nicely as well) and do all slipstreaming and nlite operation in the VM. (you don't actually need to have SP3 installed to the VM, your plainSP2 will do nicely). Then, test the the result in the VM first. jaclaz

Yes/No. I just tested, see here: http://reboot.pro/15123/ the FreeDOS and it has another OEM name, FRDOS4.1. You can call the 2nd sector whatever you want , but if the theme is "making a filesystem from scratch" you will have to create the 2nd sector too. About the OEM field being part or not (it is not) of the BPB (already cited): http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/volume-boot-block-oem-name-field.html the issues are TWO as I see it: some boot code will check it nonetheless the stoopid volume tracker of WIn9x/Me writes "crazy" OEM names a good example of the latter is the DOS 8.0/WinME floppy embedded in XP/2003's diskcopy.dll: http://www.911cd.net/forums//index.php?showtopic=16745 I have no idea if it can happen that it creates non-batch compatible string (like one containing ! or & or <>, etc.) Stiil trying to get an agreement: Size in sectors (small-16) Size in sectors (large-32) or Number of sectors (small-16) Number of sectors (large-32) (just to be homogenous with other field names, you don't have "Total FAT(s)" or "Total Heads" ....) jaclaz

Do you mean that *somehow* on that machine the video drivers change the way a mass storage filter driver works ? I am presuming you are using one of cfadisk.sys or dummydisk.sys) Maybe they are not "just" video drivers? jaclaz

Yep. Most probably you will also need some other drivers integrated. DriverPacks: http://driverpacks.net/ provide a "wide range" of drivers (but of course size of install media will grow). Or you can use nlite to integrate the single drivers that you need for your laptop. About SP3, I would integrate/slipstream it manually before adding the drivers. Remember that Rule #1 of nlite is: NEVER run nlite using as source the result of a previous nlite session, always start from an "untouched-by-nlite" source and do everything in one "pass". jaclaz

FAT32 has actually three of them sectors, but I thought we were (at the moment) inside the FAT12/16 realm. With FAT32 we additionally have the "third" sector being in "variable places", namely, for the ones I remember: MS_DOS sector 2 NT sector 12 ReactOS 14 Summed up here: (I presume - but haven't checked - that FreeDOS is similar to MS-DOS) Using an MD5 or even a simpler algorithm is OK, I don't think we will ever have enough samples to have even a minimal possibility of a collision. Personally I think that zeroing out a number of initial bytes in the sectors is not the "right" approach. Why not simply have: the original bootsector(s) copy. apply to it a .ini with all the values we will change, exception made for: Jump_Bytes OEM_String System_ID Magic_bytes set to 00's? jaclaz

You really should fix your google http://gsmartcontrol.berlios.de/home/index.php/en/Home http://gsmartcontrol.berlios.de/home/index.php/en/Screenshots jaclaz

Yes, it is "innatural". Both "Start_Sector" and "Sector_Offset" are both better, the "Sectors_before" comes from the same comparison about different "partition related tools": http://jaclaz.altervista.org/Projects/USB/USBstick.html SectBefore StartSector Sectors Before Relative Sectors Starting I find it a plain English way (without entering in the detail tha LBA sectors are numbered from 0) to describe what the field should contain, still in the "hard disk" world, the LBA start address is the number of "sectors before" and: TotSectors NumSectors Sectors Total Sectors is the number of sectors in the partition, corresponding to either of the two fields "Small_Type_Sectors" and "Large_Sectors", where also as seen before there is not yet an univocal agreement: @dencorso The idea of the .ini has several "goals" have a "standard" way to exchange "complete" information about such images/formats. As we have seen in this an similar threads it is easy to forget "passing" a parameter (like the number of "ROOT" entries) and often sources you can find miss this or that detail a .ini file (besides being parsable by *anything*, including batches ) can be posted "as is" on the board or inside an e-mail, or whatever using a .ini the spreadsheet could output such a .ini and one could use a "generic" batch or program to simply load the .ini settings, being it "plain text" it could be easily modified/tweaked without any spreadsheet app and without actually changing values in the batch, everyone could write his/her own little program to read the "common format" .ini and produce the image, adding also features like "full", "truncated" and "sparse" (this could be "cross-platform") another operation that could be done through an "extension" of the app could be replacing what bootpart does (with a number of limitations) and/or correcting the "Sectors Before" to make logical volumes inside extended bootable, the use of the .ini would be a way to put down all data needed when performing this "kind" of operation and then each program may take from it only what is needed and there could be an app that dreates the .ini from an existing volume or image additionally, in situations like the "flashing cursor" or "j in top left of the screen" the user asking for help may run a little app to create the .ini and post it, and it would be a breeze to troubleshoot the issue... the thing I find more needed is the actual image naming convention (the actual "section" of the .ini) as I often (please read as "always") find myself with a bunch of images with a name that give no hints of their contents, if we could devise a way of naming that would give a hint of the way the image was made, it's size and "contents" (in the sense of boot code in it) it would solve or mitigate this problem, and I am pretty sure I am not the only one having it jaclaz

Well, the idea was to give you the hints, not doing your tests.... What happens with: FOR /F %%I IN ('^>nul DIR/A-D/B HFMER 2^>^&1') DO ( jaclaz

I am actually not asking for "considerations", I am only asking for two (actually three) names we can all agree upon and that are understandable by users, and that make sense BOTH when we are talking of a superfloppy image and when we are talking of a hard disk volume, and I am not "insisting" in anything, only explaining my wrong (in the sense of simplified ) way to describe things in the given context, as you may know the graphical and mechanical representations are completely meaningless on any modern (meaning what, last 15 years? ) hard disk, so that maybe was CHS. We have THREE fields that I temporarily (and mistakenly) named: Sectors_per_Head Number_of_Heads Sectors_Before How should they be named? Sectors_per_Track Number_of_Heads Hidden_Sectors Is that OK? This only affects the actual variable names, I reserve the right to call them (as I understand them the wrong way) in the "textual part": Sectors per Track (Sectors per Head) Number of Heads Hidden Sectors (Sectors Before) I also asked, PLEASE for additional corrections to the two added sheets in the Workbook, and to verify and FILL the missing data. Can I have them? Or everything is already "perfect" (I doubt it, but I may have been lucky) jaclaz

Broken google? http://sourceforge.net/projects/smartmontools/ http://smartmontools.sourceforge.net/smartmontools_scsi.html jaclaz

Sure, sorry , I missed the "final" "*Number_of_Cylinders" (that is not a "field" in the bootsector) in the case of hard disk and "*Number_of_Tracks" ( or number of "whatever") (that is also not a "field" in the bootsector) in the case of floppy. Let's take the example of a "super-floppy" of 9,437,184 bytes, 512 bytes/sector. That makes 18432 sectors. Let's say that we have an "extended" ED disk drive , thus m/2/36 It has 256 "whatever #1"<-this is NOT a field in the bootsector it has 2 "whatever #2" (Sides?, Heads? Tracks?) <-this is a field in the bootsector It has 36 "whatever#3" (Sectors_per_Track? Sector per Head?) <-this is a field in the bootsector 9,437,184 is given by: Bytes_per_Sector*whatever#3*whatever #2*whatever #1 512*36*2*256=9,437,184 A partition/volume on hard disk 18432 sectors, 512 bytes each, totaling 9,437,184 bytes in size on a hard disk with a nx64x32 CHS geometry will have (let's assume that it is a very small second partition and that we do respect cylinder/head boundaries), first partition being: CHS 0/1/1-19/63/32 LBA 32/40928 will have: CHS 20/0/1-28/63/32 LBA 40960/18432 9,437,184 is given by: Bytes_per_Sector*whatever#3*whatever #2*whatever #1 512*32*(63-0+1)*(28-20+1)=9,437,184 The differences between the two bootsectors should be: whatever#3 (temporarily named "Sectors_per_Head") 36 vs 32 whatever #2 (temporarily named "Number_of_Heads ") 2 vs 64 "Sectors_Before" (or "Hidden Sectors") 0 vs. 40960 "Media_Type" (this should be OK ) 240 vs 248 How can the two "whatever" be named so that they are "self-explaining" in both cases? jaclaz

Can you expand (pardon me the pun ) on this? Which source do you have (in .SWM files)? This is usually OEM.... and AFAIK there is no explicit provision for .SWM files in the WinsetupFromUSBWithGUI (which I presume is what you tested, and - still presume - in the newest 1.0 beta7 version), it is likely that is the actual .SWM mechanism that somehow checks the install media. Easiest would be to procure yourself a stick for which there is a "flipping removable bit" tool (or verify if there is one for your current stick) and flip the bit. jaclaz

Are you joking or what? http://www.embeddedmarket.com/products/USB-to-TTL-Converter-Module/ http://www.embeddedmarket.com/Products/RS232-to-TTL-Converter/ Do you want me to draw a map for you? jaclaz

OK, I'll try again. In a typical hard disk with a CHS geometry of nx255x63 in the MBR there are two fields that are normally called (see also my old page here): http://jaclaz.altervista.org/Projects/USB/USBstick.html bHead BHd Starting Head Starting Head Starting Head and eHead EHd Ending Head Ending Head Ending Head in populated entries, and with the "old" alignment standard, in the "BHd" field there is normally 1 (in first partition, because of the hidden first Track ) or 0, whilst in the "EHd" one there is 254 (as heads are numbered in CHS starting from 0). In the corresponding bootsector, the field "Number of Tracks" or "Number of Heads" is 255. And two called: bSect BSec Starting Sector Starting Sector Starting Sect and: eSect ESec Ending Sector Ending Sector Ending Sect in populated entries, and with the "old" alignment standard, in the "BSec" field there is normally 1, whilst in the "ESec" one there is 63 (as sectors are numbered in CHS starting from 1). In the corresponding bootsector, the field "Sectors per Track" or "Sector per Head" is 63. To me in this context of bullding volumes that can be either a volume on Hard disk or represent a "superfloppy", a Head or a Track are exactly the same thing, for which two different names are used, one for floppies and one for Hard Disks. The size of the volume in bytes is given by: Bytes_per_Sector*Sectors_per_Head*Number_of_Heads or: Bytes_per_Sector*Sectors_per_TracK*Number_of_Heads No problem whatsoever in naming the field "Sectors_per_ Track" , but then also the "Number_of_Heads" should become "Number_of_Tracks", thus losing any logical connection with the MBR. Sure , dencorso already posted the algorithm used and the little spreadsheet I was talking about was a reversing of that algorithm to check if the Volume serial had been tampered with, by detecting possible dates/times that may have generated the serial and verify if they were within a possible timeframe. This applies to DOS but NOT to NT systems, for which the algorithm is not AFAIK known. Here are some details: http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=2134 jaclaz

You didn't read them "hard enough". FORGET about your current project. Create a new batch file with ONLY these commands, as CLEARLY stated on the given page: http://www.robvanderwoude.com/battech_redirection.php @ECHO OFF ECHO This text goes to Standard Output ECHO This text goes to Standard Error 1>&2 ECHO This text goes to the Console>CON and test it as explained there. Then try with: @ECHO OFF FOR /F %%I IN ('DIR/A-D/B HFMER') DO ( ECHO Copying %%I ECHO No redirection: MOVE HFMER\%%I %SP6%\sp6 ECHO. ECHO Redirection of DEFAULT "Standard output" to NUL: MOVE HFMER\%%I %SP6%\sp6 >NUL ECHO. ECHO EXPLICIT redirection of "Standard output" to NUL: MOVE HFMER\%%I %SP6%\sp6 1>NUL ECHO. ECHO EXPLICIT redirection of "Standard Error" to NUL: MOVE HFMER\%%I %SP6%\sp6 2>NUL ECHO. ECHO EXPLICIT redirection of BOTH "Standard output" "Standard Error" to NUL: MOVE HFMER\%%I %SP6%\sp6 2>&1>NUL ) jaclaz

Learn about "Standard Output" and "Standard Error" and their redirection: http://www.robvanderwoude.com/redirection.php (already given to you) AND: http://www.robvanderwoude.com/battech_redirection.php jaclaz

Well WIN TO FLUSH is probably WINTOFLASH. But athough I don't see why you haven't asked for help on their Forum , the issue is most probably (please read as definitely) in the way you formatted the USB stick. Use RMPREPUSB (and nothing else) to partition and format the USB stick: http://sites.google.com/site/rmprepusb/ Preferrably (but of course not at all mandatory ) use our own app to create the Windows 7 base for install: http://www.msfn.org/board/forum/157-install-windows-from-usb/ (BTW it already includes RMPREPUSB) jaclaz