jaclaz

Just for the fun of it, I tried in Qemu Manager 6 (Qemu 0.10.2). Videocard set as VMware SVGA-II Using bearwindows drivers: http://bearwindows.boot-land.net/ http://bearwindows.boot-land.net/vbemp9x.zip (the vbe9x\uni version) tested up to 1280x1024 16/24/32 bit without problems (the 1600x1200 works, but it's to big) the 1152x864x16 bit seems just right to me. jaclaz

Most probably you need to use a "no more CATCH22" trick: http://www.911cd.net/forums//index.php?sho...20983&st=25 Copy the boot.ini file on your hard disk to (say) \Temp\BOOT.INI on your USB stick. You may need to change it's attrib settings: http://commandwindows.com/recovery.htm http://commandwindows.com/recovery-console-commands.htm in order to be able to copy it Open it in notepad on the system you are using to visit the board. Copy and paste. However from what you posted, you have both entry pointing to C:\Windows, that should mean that choosing either of the two you should have the SAME success or failure . Haven't you anything more "comfortable" than RC? Like a PE of some kind? http://www.msfn.org/board/install-xp-usb-a...sb-t121446.html Next step would be to change the Registry key that makes the system autoreboot on BSOD, in order to be able to read it's error message. http://www.theeldergeek.com/auto_reboot_on_system_crash.htm With RC only you need: to copy the file \WINDOWS\system32\config\system to the USB on another system load the system hive on your local registry and change the setting in ControlSet001 (CurrentControlSet is ONLY available on an online system) unload the hive copy back from RC from USB to \WINDOWS\system32\config\system jaclaz

Have you all the right drivers? Post a copy of the BOOT.INI on your hard disk. fixmbr has NOTHING to do with BOOT.INI, if you can get to the choices in BOOT.INI, your MBR and bootsector are allright, and you should leave them alone. Read this one: http://www.boot-land.net/forums/index.php?...ic=8758&hl= jaclaz

There may be some problems in accessing files in that stage, but the problem is that AFAIK grldr initial part tries to "find itself" and it looks in ROOT of any partition, even a hidden one, but not in folders. Some releases may behave differently. About the embedded menu.lst read here: http://diddy.boot-land.net/grub4dos/files/embedded.htm http://www.boot-land.net/forums/index.php?...c=6775&st=5 http://www.boot-land.net/forums/index.php?...=8634&st=13 But since we are into the realm of experimentation, you can also edit it to point to BOOT.INI itself . Try a BOOT.INI like this: title PLoP Boot Manager find --set-root /plpbt.bin kernel /plpbt.bin boot [boot loader] Timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect C:\grldr=grub4dos Before changing the "menu.lst" in the embedded to "boot.ini", simply go to command line in grub4dos and issue command: configfile /boot.ini What happens? The NTLDR parses BOOT.INI starting from the first "[", so you can add something before it: http://www.msfn.org/board/win-98-and-win-x...604-page-8.html Of course I am COMPLETELY in disagreement to the approach you chose. Both grub4dos and PLoP are in continuous development, and hard-coding them inside the .exe means putting on the HD a "static" version, unless you continuously update the app. BTW, your approach is an infringement of the GPL license of GRUB/grub4dos, you should add the COPYING license file and at least a minimal text explaining that your app contains GPL code. You do NOT actually "need" grub4dos to load PLoP: http://www.plop.at/en/bootmanager.html#runwin jaclaz

@Siginet But where would the "mini iso" be saved? I mean, all you need, apart the edit in boot.ini, is PLoP and a way to load it (and grub4dos seems just right). I.e. you add to root of the hard disk (temporarily): grldr menu.lst plpbt.bin BOOT.INI: C:\grub4dos:"Grub4dos" menu.lst: title PLoP Boot Manager find --set-root /plpbt.bin kernel /plpbt.bin You can even get rid of menu.lst by editing the embedded menu.lst of grldr. But all in all if the PC does not have USB booting capbilities, why not leaving this possibility even after the install? At this moment: grldr 220,921 bytes plpbt.bin 42,876 bytes I don't think the disk occupation to be a problem. jaclaz

Awergh posted about them two already. Well, with all due respect to both you and awergh , this: does look a bit "vague". QEMU, being NOT an emulator, will tendentially be slower than "pure" virtual machines, but latest versions are not that bad, mainly because real hardware has improved so much in speed. I mean, if we assume that a QEMU VM will run (very approximately) at 1/3 or 1/4 the speed of the hosting system, if you have a >2.8 Ghz processor, it is likely that the Win9x in it will run with the same feeling you would have on a 700÷900 Mhz machine. If you put the virtual disk on a ramdisk, file I/O will fly. Video won't work very fast though I haven't played at all with the different cards available in lates QEMU (0.10.x) or with alternative drivers like the bearwindows ones. jaclaz

Just for the record, latest version of Firadisk has also bettered noticeably it's speed: http://www.boot-land.net/forums/index.php?...8804&st=199 though cannot say if HDTACH results can be compared to Crystal Disk Mark ones jaclaz

Test write is traditionally a way to understand what "real life" maximum burning speed you can achieve on a given system. There are a lot of factors affecting these, and expecially with relatively slow buses and actual CD/DVD burners without a big cache or other form of overflow correction, it was quite normal to have a coaster as a result. The test is meant as a simultaion to measure actual data transfer speed available. In any case burning a bootCD at "maximum" speed is not a good idea, even today. For CD, lowest possible speed is advised. For DVD, medium speed seem to be better. jaclaz

Well, I am at the same time a fierce substainer and somewhat a detractor of Winbuilder. I personally think that the means are not at all important. I prefer batches, as I know a bit about them (vs. next to nothing about Winbuilder .scripts) I simply cannot read .scripts, too many commas, quotes and #$ for my mental parsing engine, but it works very well if you "get the hang of it". It is entirely up to you. jaclaz

Russian is unfortunately a bit hard (though better than Chinese ) to my western eyes. But I will wait with interest an English release of it, here or on boot-land. jaclaz

Why not 7-zip? http://www.7-zip.org/ 32-bit 7-Zip Command Line Version http://downloads.sourceforge.net/sevenzip/7za465.zip Why using EXTRAC32.EXE instead of EXTRACT.EXE? Both EXTRAC32.EXE and EXTRACT.EXE are normally in %Windir%\System32 on XP systems, i.e. in path. C:\WINDOWS\system32>extrac32 /? | more Microsoft ® Cabinet Extraction Tool - Version 5.1.2600.2180 Copyright © Microsoft Corporation. All rights reserved.. EXTRACT [/Y] [/A] [/D | /E] [/L dir] cabinet [filename ...] EXTRACT [/Y] source [newname] EXTRACT [/Y] /C source destination cabinet - Cabinet file (contains two or more files). filename - Name of the file to extract from the cabinet. Wild cards and multiple filenames (separated by blanks) may be used. source - Compressed file (a cabinet with only one file). newname - New filename to give the extracted file. If not supplied, the original name is used. /A Process ALL cabinets. Follows cabinet chain starting in first cabinet mentioned. /C Copy source file to destination (to copy from DMF disks). /D Display cabinet directory (use with filename to avoid extract). /E Extract (use instead of *.* to extract all files). /L dir Location to place extracted files (default is current directory). /Y Do not prompt before overwriting an existing file. C:\WINDOWS\system32>extract /? Microsoft ® Cabinet Extraction Tool - Version 5.1.2600.2180 Copyright © Microsoft Corporation. All rights reserved.. EXTRACT [/Y] [/A] [/D | /E] [/L dir] cabinet [filename ...] EXTRACT [/Y] source [newname] EXTRACT [/Y] /C source destination cabinet - Cabinet file (contains two or more files). filename - Name of the file to extract from the cabinet. Wild cards and multiple filenames (separated by blanks) may be used. source - Compressed file (a cabinet with only one file). newname - New filename to give the extracted file. If not supplied, the original name is used. /A Process ALL cabinets. Follows cabinet chain starting in first cabinet mentioned. /C Copy source file to destination (to copy from DMF disks). /D Display cabinet directory (use with filename to avoid extract). /E Extract (use instead of *.* to extract all files). /L dir Location to place extracted files (default is current directory). /Y Do not prompt before overwriting an existing file. But 7-zip can extract from .cab files allright. Also, I would suggest using a more "structured" approach. In BUILD_WIN98LIVE.cmd there are 371 lines with more or less the same content including a few COPY /L (most probably due to copy and paste ). Instead of (example): 115 PROJECT\TOOLS\EXTRAC32.EXE /Y /a PROJECT\SYSTEM\SYSPREP.CAB GETCLINF.DLL /L TARGET\WINDOWS\SYSTEM\ 242 PROJECT\TOOLS\EXTRAC32.EXE /Y /a PROJECT\SYSTEM\SYSPREP.CAB PSYDMSOS.DLL /L TARGET\WINDOWS\SYSTEM\ 243 PROJECT\TOOLS\EXTRAC32.EXE /Y /a PROJECT\SYSTEM\SYSPREP.CAB PSYDO957.DLL /L TARGET\WINDOWS\SYSTEM\ 244 PROJECT\TOOLS\EXTRAC32.EXE /Y /a PROJECT\SYSTEM\SYSPREP.CAB PSYSDUP2.EXE /L TARGET\WINDOWS\SYSTEM\ 264 PROJECT\TOOLS\EXTRAC32.EXE /Y /a PROJECT\SYSTEM\SYSPREP.CAB RUNONCE.EXE /L TARGET\WINDOWS\SYSTEM\ One could have a plain .txt file SYSPREP.LST: and in BUILD_WIN98LIVE.cmd something like: @ECHO OFF SET SOURCE_PATH=PROJECT\SYSTEM\ SET TARGET_PATH=TARGET\WINDOWS\ CALL :DO_EXTRACT SYSPREP ::... GOTO :EOF :DO_EXTRACT FOR /F "tokens=1,2" %%A IN ( %1.LST) DO ECHO EXTRACT.EXE /Y /a %SOURCE_PATH%%1.CAB %%A %TARGET_PATH%%%B GOTO :EOF I guess it would be easier to add/remove things in a further stage. @luluthefirst Because it would be a plain WAREZ release. jaclaz

I see , so the only use is to create the WIN98.IMG that is later used by grub4dos mapping: title Mini Windows 98 find --set-root /WIN98/WIN98.IMG map --mem /WIN98/WIN98.IMG (fd0) map --hook chainloader (fd0)+1 rootnoverify (fd0) In other words, the "result" is not "really-really" a bootable .iso, but rather a bootable .iso containing a bootable superfloppy image, this was the part that wasn't clear to me at first sight. I.e. the .iso is just a "container", you can copy the WIN98.IMG to (say) a USB stick booting grldr or grub.exe and add an entry for it in menu.lst and it will work just the same. About "removing" I meant "removing", I mean are the msn files redistributable? As well the use of rar.exe should be replaced by the use of freeware 7-zip or of any similar freeware command line archiver, IMNSHO. As an addition, I would suggest the use of Qemu for the test(s). There is a pre-packed solution: MobaliveCD: http://mobalivecd.mobatek.net/en/ that seems to me like ideal, and much easier than VMware and VirtualPC for people not already familiar with Qemu (or Qemu Manager). jaclaz

That is exactly the debatable part, you cannot recover that file, and depending on how the file was written to the device you may not have the original anymore. And additionally, yes, if a given manufacturer uses a wear-leveling algorithm it is possible that it goes "beserk" and you also lose something else. And, as mentioned there is the problem of data leakage from the cells, for which AFAIK, apart "generic" assumptions there are no reputable "field tests" confirming the actual data retention period on a "sound" stick, let alone on a "worn out" one. Problem is that apparently some wear-leveling algorithms do operate even when reading only: http://www.forensicfocus.com/index.php?nam...opic&t=3542 Yes and no. Not all USB controllers for USB stick have wear-leveling capbilities, and of course each of them uses it's own algorithm, all of them being rigorously UNpublicated. The theory is exactly like that, but we don't know (or we don't know specifically for "each" device) if the writing (and swapping) is done in "bursts" at a 512 byte sector "granularity", at filesystem cluster "granularity" or what. @dencorso JFYI: http://www.msfn.org/board/vxds-and-related...lp-t135527.html jaclaz

It seems to me like a really nice project. I haven't tested it by running, only peeked a bit inside the .cmd's to get the general idea. Are you ready for questions/suggestions/critics? I can see IMDISK called in five occasions, two to "mount" and three to "dismount": Of course the only part that actually runs (if one follows the instructions) is the one in rar.cmd, and the "just to make sure" dismount command in BUILD_WIN98LIVE.cmd. And here is where I am lost. What is the use of the WIN98.IMG? I see great potentialities in your approach, but I would like to better understand it, so that I can (should you allow it, of course ) to give you a few suggestions I have in mind. Why there is an uumerge.exe and an uumerge2.exe? They seem identical to me. About MSN messenger, I would remove it (besides from your project from the whole world ). jaclaz

Well, AFAIK the "\tinybit\" repository is somehow a (temporary) "fork" from "main" to experiment some new things. I wouldn't use it if not for experiments ONLY, as we don't know if it will be "merged back" to main. yes. From what I can understand, the () is interpreted slightly differently by the various commands. Of course geometry ONLY uses the actual device part, i.e. if on a multi-partitioned disk you run: geometry (hd0,0) geometry (hd0,1) geometry (hd0,2) you get exactly the same result, as you would have with both: geometry (hd0) geometry () if current root is ANY of the partitions on the disk. In this case is the geometry command that "trims away" the unneded partition specification. If you try this: root (hd0) you get an error 17: cannot mount selected partition If you try: rootnoverify (hd0) root () you get an error 17: cannot mount selected partition which is expected. In this, the [TAB] autocompletion helps, if you boot from floppy and issue: root (hd0 [TAB] the autocompletion adds a comma "," and not the closing brackets, waiting for you to choose a partition on the drive. On the other hand if you run: root (hd0,0) map () (hd1,0) map --hook cat --hex --length=512 (hd0)+1 cat --hex --length=512 (hd1)+1 cat --hex --length=512 (hd0,0)+1 cat --hex --length=512 (hd1,0)+1 you get the SAME results as: root (hd0,0) map () (hd1) map --hook cat --hex --length=512 (hd0)+1 cat --hex --length=512 (hd1)+1 cat --hex --length=512 (hd0,0)+1 cat --hex --length=512 (hd1,0)+1 which means that also map command "trims away" unneeded partition specification, thus, if root is (hd0,0), ANY of these: actually mean: map (hd0) (hd1) jaclaz

This is debatable. Actually you only "know" that a fleash has worn out when you try writing on it. It is NOT a "binary switch" ON/OFF, there is a progressive degradation, it is very likely that a number of cells will not take the new info, while some will, and the result would be a mix-up of old and new information. @LoneCrusader Remember, you asked for it : You are WRONG. Ext2 is NOT journaled: http://en.wikipedia.org/wiki/Ext2 Ext3 can be read as "journaled Ext2": http://en.wikipedia.org/wiki/Ext3 jaclaz

Well, no. The 16/63 geometry is rather common, the 32/63 is far less common, but BOTH can be found on very small capacity sticks, I have never seen any of them on a "large" stick, this one is a 16 Gb one! Usually whatever goes above the CHS limits for a given geometry uses NOT the "smaller" geometry: http://www.boot-land.net/forums/index.php?...=9776&st=56 The CHS limit at 32/63 is obviously: 32/63->1024*32*63*512=1,056,964,608 >- as said very unusual in my experience Again, NO. Read the related thread here: http://www.msfn.org/board/ntfs-support-win...14-page-44.html At least in Europe, there would be NO problems in writing an exFAT driver from a legal standpoint, for interchange use, and most probably the same would apply to the "fair use" provisions of the US Law. The "licensing fee" is for devices using the filesystem, not for programs capable of reading/writing it. jaclaz

An interesting source, focused on data retention and durability of DATA records: http://preservationmatters.blogspot.com/ jaclaz

USB sticks (or more generally FLASH based devices) do have a finite amount of write cycles. They are NOT suited as permanent/safe storage as they also have a limited data retention threshold - actually unknown for sure - but estimated in 10 years: http://www.allmemorycards.com/glossary/reliability.htm Check these: http://www.freescale.com/files/microcontro...letin/EB618.pdf http://www.atmel.com/dyn/resources/prod_do...nts/doc2546.pdf About defragmenting, it is NOT a good idea. During a typical defragmenting operation, data is usually moved back and forth several times. An "offline" defragmentation", like creating an image of the stick, defragmentng the image and then restore the defragmented image is better suited. But again, and just as it is perfectly unneeded in a number of times on normal hard disks, do not overdo it: http://www.msfn.org/board/does-frequent-fo...dd-t134982.html Also read these, about the opportunity of NOT using NTFS (or other semi-journaled or journaled filesystem on Flash devices): http://www.msfn.org/board/help-remove-file...84-page-17.html http://www.msfn.org/board/usb-stick-dead-t137512-page-6.html SSD, like used in netbooks use a different kind of Flash: http://en.wikipedia.org/wiki/Flash_memory#...for_hard_drives which has presumably a much greater life expectancy, BUT read these too: http://www.boot-land.net/forums/index.php?showtopic=8757 http://www.boot-land.net/forums/index.php?showtopic=9615 jaclaz

Are you sure that winntbbu.dll is actually in ROOT of C: ? I.e. that a file C:\winntbbu.dll exists? jaclaz

Only to happy to have contributed into making another happy bunny : http://www.msfn.org/board/cant-access-repa...27-page-10.html jaclaz

Yep. That's an offline "syspart" install. As you pointed out it will only work on a device that is seen as "Fixed", i.e. a USB Hard Disk or a USB pendrive/stick that has had the "Removable" bit "flipped". I don't think there are reports of using this method with the dummydisk.sys driver. The main drawback of it is that the device is "dedicated" to the Windows install, unlike the other solutions in the dedicated sub-forum. And of course I lied : jaclaz

Just in case: http://www.boot-land.net/forums/index.php?...c=9916&st=6 There are a number of "strange things in the partitioning/formatting of that stick: Partition type is 1B (hidden FAT32 CHS Mapped) as dencorso pointed out: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html The geometry is "queer", being HS 32/63 - which is unusual though the data in the MBR and bootsector are matching. The CHS values are UNbalanced with the LBA ones: CHS: (140+1)x(31+1)x63=284,256 sectors x512=145,539,072 bytes <- LBA 31,249,953+63=31,250,016 sectors x512=16,000,008,192 bytes <- which sounds like "right" The LBA is correctly aligned to Cylinder boundary, but the "virtual geometry" is: (15500+1)x(31+1)x63=31,250,016 which corresponds to a "real" CHS data of: 0/1/1/1023/31/63 "Something" must have changed the data. I would try first thing to set the partition as visible: 1B->0B Then I would try changing the partition type to a LBA one: 0B->0C Then again I would change the CHS end Cylinder: 140->1023 Finally, I would scratch the whole thing and re-partition/re-format it with the "usual" HS geometry of 255/63, using one of the tools listed here: http://www.boot-land.net/forums/index.php?showtopic=9460 To do the changes manually, I suggest you the use of either beeblebrox (as it runs on BOTH 9x and NT based systems): (site down) available through Wayback Machine: http://web.archive.org/web/20080320075013/...byu.edu/~codyb/ http://web.archive.org/web/20080320075013/...byu.edu/~codyb/ http://web.archive.org/web/20060223003038/...brox9xsetup.zip http://web.archive.org/web/20060223003044/...broxntsetup.zip Or use tinyhexer, possibly using my Structure Viewers as help/guidelines: http://www.boot-land.net/forums/index.php?showtopic=8734 jaclaz

If it's "philosophically" different from this: http://www.msfn.org/board/2-t121446.html in practice: boot a PE of some kind from USB run winnt32.exe It would be interesting, as well if you found something not already found/documented. Let's make a deal: you post a report of what you did and how you did it And I promise I will refrain from telling you: even if it is. jaclaz

You may be luckier on a Russian site : http://flashboot.ru/index.php?name=iflash JFYI, the good thing about Chipgenius is that it has a database with links to topics on the (Chinese) Forum: http://www.boot-land.net/forums/index.php?showtopic=4661 but of course... it's Chinese jaclaz