jaclaz

Sure they do not, as the DOS and Windows we are currently using were all made AFTER the "invention" of types 04, 06 and 0C 0E, this is IMHO the same "side effect" as the "large Sectors vs. Small Sectors". If you try: DOS <3.3 DOS 3.3 DOS 4.0 DOS <=6.22 DOS >= 7.0 on a set of 01/04/06/0C0E partitions, your mileage should (and will) vary I think that in common language we could consider: FAT12 an ancestor of FAT16 FAT16 04 a sub-set of FAT 06 FAT 16 06 a sub-set of FAT 0C 0E Then draw a line around 1995 and say that everything coded after is accessing *any* of the above in the same way (which allows for some of the tricks we are discussing). As I see it, trying dencorso'S image in DOS 3.3 should fail, as that version of Dos should know nothing about "Large sectors". jaclaz

As long as you comply with my Careware License , yes, of course : http://jaclaz.altervista.org/Projects/careware.html but - as said - at the moment we are very little beyond the "proof of concept" stage. Can you assemble together a "fake" update .inf file with all the lines that you find needing manual correction (i.e. the ones that result as "different" in the re-joined file? This way I can have all in one source the "problematic parts" and test the batches more easily.... IN other words, if you could manually assemble a fake "difficult" file, it will be faster for me. jaclaz

Exactly I may be wrong, but the actual fun in using batches to automate things is to actually automate them. Actually it simply "dedupes" the index of sections, so that each "split" file is only processed once. I'll check. Checked, they are stoopid [TAB]'s. Will add. Yes: ::Final adjustments to be run ONLY once ::run Once ::Replace "==" with a dummy string "§#§" CALL :run_gsar :x3d:x3d :xa7:x23:xa7 jaclaz

Well, you can dedupe the [1ndex] by processing it with FEDIT. Try the attached join_dedupe_inf.cmd instead of join_inf.cmd, I modified it a little bit to create (hopefully) a deduped [1NDEX] fie (actually called [2NDEX] ): ::BEGIN MODIFIED ECHO [DUMMY_SECTION]>%Split_dir%[2NDEX]%Source% FOR /F "skip=2 tokens=1 delims= " %%A IN ('FIND "[" %Split_dir%[1NDEX]%Source%') DO ( SET string=%%A SET string=!string:[=! SET string=!string:]=! ECHO Processing %%A.... Fedit -f %Split_dir%[2NDEX]%Source% -add -once -create -l "dummy" -s "!string!" Fedit -f %Split_dir%[2NDEX]%Source% -rem -l "dummy" -s "!string!" ) Fedit -f %Split_dir%[2NDEX]%Source% -rem -l "[DUMMY_SECTION]" ECHO. ECHO. ECHO TYPE %Split_dir%[2NDEX]%Source% ECHO. TYPE %Split_dir%[2NDEX]%Source% ECHO. FOR /F %%A in (%Split_dir%[2NDEX]%Source%) DO ( ECHO COPY /B %Work%+%Split_dir%%%A%Source% %Work% COPY /B %Work%+%Split_dir%%%A%Source% %Work% ) ::END MODIFIED But the problem I see in "real life" is the order in which you copy together the single .inf files. Wouldn't it be possible that a newer update line is overwritten by an older one (if by chnace a file is copied in the "wrong" order)? I will add the <= and >= provision. jaclaz join_dedupe_inf.zip

@dencorso As often happens, yes and no. Remember the CHS/LBA issues on 2K/XP bootsectors? I guess we are simply LUCKY that it doesn't applies to FAT16 bootesector code. On a side note, VDK without a .pln file descriptor will default to 64/32 anyway, and 2K/XP will use LBA data anyway. @multibooter Those two difference are OK and *somehow* "logical". The one at offset 0x1C is sectors before (or "reserved sectors"), in your snippet it has a value of 0x00000000 and 0x00000020, i.e. 32. The one at offset 0x24 represents "drive number" and is 0x00 in floppy and superfloppy (F0) or normally 0x80 (aka drive 128) on HD (F8). If you compare the bootsector of the image dencorso posted, you will see that it has at 0x15 F0 whilst your snippet has F8. Basically GRDUW seemingly *somehow* transformed the "superfloppy" into a hard disk volume, maybe (or maybe NOT) connected to the "partitioned type" of ZIP disk. jaclaz

1. other two "exception" that need to be taken into consideration in the batch 2. Good. 3. Hmmm, don't think it is very productive, but the fact that the batch worked (though slowly) on a 250 Mb files is good news , it means that there are no strange "overflows" or something the like 4. The "ECHO OFF" line is good (actually "bad" ) news, it means that the variable that was supposed to be echoed got a null value. I need to have the .inf on which this happens, as it marks the place where the problem is. (just like #3 in previous bug report) If you use your "inappropriate" way depicted in #3 above, and, once you create the "original" BIG MERGED file you apply to it the splitinf.cmd, then go to the SPLIT_whatever directory you should be able to process the single section files, but I don't see how by sorting them you can know which one is the line relative to the single update .inf. jaclaz

@dencorso Good. Everything seems more clear. The big difference in calculations was the 1.5 bytes (FAT12) vs. the 2 bytes (FAT16) I still think though that *somehow* using the "large sectors" field represents cheating and exploiting some kind of deficiency (or unintended feature) of the filesystem drivers/whatever. I mean, most probably,and as rloew just confirmed, the driver/whatever is the same for FAT12/16 and the code somehow reads "large sectors" if "small sectors" is 0 no matter the "declared" FAT12 filesystem, whilst it strictly uses the 1.5 bytes depending on the same "declared" FAT12. Running chkdsk on the mounted image gives 3070 clusters, which seems right (and entirely addressable). We have: 1 = bootsector 9+9 FAT tables 512/32=16 Root directory 1+9+9+16=35 sectors that count anyway as one cluster So there should be just one cluster (plus the "spare" sectors above 64-35=29) that are not in any way "addressable". But if you use 10 sectors per FAT, I see no drawbacks, and you get an entire additional cluster addressable! @rloew Sure, the 01/04/06/0C 0E were only to "identify" different "versions", and their respective limits (that were "overtaken" by the new filesystem drivers/whatever). If you don't use mkisofs, what do you use to create a .iso? jaclaz

Yes, the image is non-standard, I have similar problems with dmde. I get: Filesystem: FAT12 Bytes per sector: 512 Sectors per cluster: 64 Reserved Sectors: 1 Root dir entires: 512 Total sectors: 196608 Sectors per FAT: 9 Start offset: 0 Then I get a "Total sectors number was decreased to fit the device" . A quick look at it with Tiny Hexer (+ my BSview structure viewer) tells me that it has a 64/32 geometry (correct for a ZIP drive) and has a "Large sectors" value of 196,608. Most of the difference between FAT12 and FAT16 should be that the sectors number is at offset 19dec, the so called "Small type sectors" in a FAT 12 (thus allowing a max number of 4 bytes, i.e. 65535 sectors x 512=33,553,920 bytes actually a few less) whilst in FAT 16 (06 and 0C 0E type, NOT 04) offset 32dec can be used (for volumes bigger than 32 Mb), the so called "Large sectors" , see also here: http://reboot.pro/5660/ So at first sight it seems like a "hybrid" FAT12/FAT16 filesystem Or maybe better put, it is a FAT 16 filesystem (06 or 0C 0E) "labeled" as "FAT12". Having only 9 sectors per FAT should mean that as soon as you fill the image with files there may be a problem, even with 32 Kb clusters. 9*256=2,304 2,304*32,768=75,497,472 the default for that size being around 200 (with clusters sized 2K) 200*256=51200 51,200*2,048=104,857,600 See also this: http://reboot.pro/13466/ jaclaz

The "old type" had a pre-impressed cross on the top, they are normally not SMD. This acted as "safety" or "pressure release" valve to avoid defective ones to actually explode. The SMD ones leak (when it happens) on the bottom, never on the top: http://www.repeater-builder.com/motorola/spectra/spectra-caps.html jaclaz

I don't want to be a nuisance (or not more than usual ) but could you share: the EXACT size in bytes of those? an example mkisofs command line to build such a super-floppy .iso? (or some reference to the above if available) Any reason for the 32K sized clusters? It should be 2K: http://support.microsoft.com/kb/140365/en-us and it really should be FAT16. Or am I missing something? jaclaz

It seems like the FD32 uses a ZBR (Zone Bit Recording) and PRML : http://www.storagereview.com/guide/dataPRML.html As always happens there are contrasting info, see this: http://slashdot.org/story/01/02/06/1916200/Forget-SuperDisks----Try-32MB-On-A-Floppy The actual "right" data should be this one: http://rays-place.dyndns.org/Extras/PCTechGuide/16storage.htm The time frame is also debatable. See page 13 of this: http://frpcug.org/k-byte/Kbyte03_04_01.PDF It seems to me like the drive was available in 2nd quarter of 2001, but apparently it was initially only OEM. This sheds some more light: http://translate.google.it/translate?u=http%3A%2F%2Fpc.watch.impress.co.jp%2Fdocs%2Farticle%2F20010131%2Fpana.htm&sl=ja&tl=en&hl=&ie=UTF-8 As it gives a link to original product pages: http://translate.google.it/translate?u=http%3A%2F%2Fweb.archive.org%2Fweb%2F20010602074703%2Fhttp%3A%2F%2Fwww.pcc.panasonic.co.jp%2Fp3%2Fproducts%2Fdrive%2Fsuperdisk%2Flkrf240uz%2Findex.html&sl=ja&tl=en&hl=&ie=UTF-8 http://translate.googleusercontent.com/translate_c?ie=UTF8&rurl=translate.google.it&sl=ja&tl=en&twu=1&u=http://web.archive.org/web/20010305113345/http://www.pcc.panasonic.co.jp/p3/products/drive/superdisk/lkrf240uz/fd32_1.html&usg=ALkJrhhfSf3FWqC4g3809zcnbq1HxU9TZQ and to this "media" page: http://translate.googleusercontent.com/translate_c?ie=UTF8&rurl=translate.google.it&sl=ja&tl=en&twu=1&u=http://web.archive.org/web/20010418053908/http://www.pcc.panasonic.co.jp/p3/news/128/index.html&usg=ALkJrhjJmJfJ2icU0gcWfs7Jqcm7k_2EcQ that actually contains links to the various drive models. I guess we need a (paid ) account to get this full text: http://ci.nii.ac.jp/naid/110003688595 http://sciencelinks.jp/j-east/article/200110/000020011001A0346381.php to learn something more. Just a guess on my side, but probably the actual first tracks looks (very loosely) something like: =----------- with the first sector (or maybe whole track) of normal "width and length" (i.e. compatible with a 1.44 MB floppy one) and all the other ones thinner (and probably shorter) jaclaz

What you might not have suspected is that you have much thinner tracks (and 777 of them) apparently: http://everything2.com/title/FD32MB the actual width of the track seems like having been copied and pasted wrongly, this (German) source looks like more reliable http://www.tecchannel.de/storage/komponenten/401752/test_panasonic_ls_240/index6.html jaclaz

OT but not much maybe this thingy here works (not "as is" but as a Registry key) on 9x/Me too? http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14149 jaclaz

Yes, NO LS-120 can, to my knowledge. The "FD-32" technoloigy (whatever it is) is inherent to the LS-240 and NOT to the LS-120 (another old announce): http://www.neoseeker.com/news/994-que-ls-240-superdisk-external-drive-announced/ and from the mouth of the wolf: An actual PDF for the QPS USB version: http://web.archive.org/web/20011225004413/http://www.qps-inc.com/products/ls240.pdf where the feature is present and the actual manual of the LS-240 from Winstation SCSI version: http://web.archive.org/web/20040401092201/http://www.winstation.com/PDF/SCSI%20SuperDisk/sls-240/SLS240_Manual.pdf where the feature is NOT. BUT http://web.archive.org/web/20011218095613/http://www.winstation.com/Superdisk.htm "Definite proof": http://www.informit.com/articles/article.aspx?p=339027 jaclaz

LS-240 only: http://panasonic.jp/support/p3/st_others/download/index.html (japanese, but clear enough to understand that it is a LS-240 only feature) However: http://www.itreviews.co.uk/hardware/h309.htm jaclaz

I doubt it. There is nothing that can differentiate the two sections in themselves. With the "Install XP from USB" consolidating Sections (with FEDIT) did not produce any unwanted effect, I can also mantain them "separate" by temporarily renaming them, but as I see it it would be philosophycally wrong. I would keep the current (see attachment) consolidating approach and, once we will have solved the actual merging of two files, you will need to test if it works (as it should) with no duplicate sections. Issue #3 was caused mainly by a question mark "?", which now is fixed. The new version should work allright with the 4 mentioned .inf's, try with some other ones and let me know.... jaclaz split_inf_2.zip

Yes it should mean that, strangely enough, the modified .iso works allright. (that was the feared issue, more often than you would like .iso's modified with .iso editors don't boot properly anymore/have strange quirks , expecially XP setup related ones, errors like missing txtsetup.sif, etc. are common) jaclaz

#1 is expected behaviour. #2 is strange, the "beautify.cmd" is the one that should revert the "§#§" and "§##§" to their original values. ::Restore changes made to make the .inf "batch compatible" ::Replace dummy string "§#§" with "==" CALL :run_gsar :xa7:x23:xa7 :x3d:x3d ::Replace dummy string "§##§" with stoopid "&" CALL :run_gsar :xa7:x23:x23:xa7 :x26 Are you sure you did run the beatify.cmd on the file? Anyway I will try to reproduce and fix. #3 should mean that somehow something was a-miss (a variable got a value of "space" or "tab") I will try to reproduce and fix , the other quirks should be easily fixable #4 yes, this was expected in case of duplicated sections, I'll put a check for such duplicated entries so that these sections will be merged when split (I do know that is sounds queer, but it is how it will work ) jaclaz

For the record it is very possible, just use El-Torito "Hard disk emulation" (instead of "Floppy emulation" or "No emulation"). Or you mean a super-floppy format? Maybe one can use the Hard disk emulation with a "dual-mode" MBR/Bootsector like the makebootFAT one. @rloew Which media type do you need for a super-floppy larger than the 2.88 Mb? Standard ones are: 0x00 - No Emulation 0x01 - 1.2 Mb floppy 0x02 - 1.44 diskette 0x03 - 2.88 diskette 0x04 - Hard disk emulation @Multibooter, sorry for the OT. If you are interested in the matter can you start a new topic "CD related"? @rloew, maybe we can continue this interesting discussion on the above new thread? jaclaz

Well, you posted about XP, Vista and 7, not about three versions of XP. Yes, you should change the NTDETECT.COM in the three \I386\ but you need to ALSO change it into the .iso, READ the given thread. jaclaz

Are you sure you have an \I386\ for Vista and 7? With a NTDETECT.COM in them? And yes, normally you change it in the \I386\ of the XP (and or 2003) source, before running WinsetupFromUSBwithGUI or you will need to change it also inside the actual .iso, see here: jaclaz

Maybe useful, maybe not. http://reboot.pro/12436/ jaclaz

NOT the intended "final" result, ONLY "intermediate steps". Find attached three batches. splitinf.cmd - to split an existing .inf (run it with one parameter, the original .inf) join_inf.cmd - to join the split parts created by the above (run it with one parameter, the SPLIT_ directory) beautify.cmd - to make the result more readable and reset some changes I have to do to the Split parts to process them easily in batch gsar is needed: http://home.online.no/~tjaberg/ Basically: create a directory (please NO spaces in paths or filenames) like C:\INFTEST put in it the batches, gsar.exe and the (basis)Windows2000-KB891861-v2-x86-ENU.EXE.inf (please rename it to something manageable, like "base2K.inf"), never use in filenames characters that are parsed by the command line, like "(", ")", "&" "|" and interpreted like commands or are however part of syntax or need to be escaped normally, even if allowed on the filesystem, see here: http://en.wikipedia.org/wiki/Filename (please note how right now the batches do use "[" and "]" so may be not good on a FAT filesystem, please use them on a NTFS one) open a command prompt and navigate to the directory you made: CD /D C:\INFTEST run: splitinf.cmd base2K.inf join_inf.cmd SPLIT_base2K beautify.cmd JOINED_base2K.inf the "end result", i.e. BEAUTY_JOINED_base2K.inf should be comparable with the original base2K.inf and be a "fully" working .inf file If not, post which problems there are. Once we get these steps working successfully, we will talk about the actual merging of the "base" with another "split" file.... Also, I have noticed that in some of the "example files" there are many "empty" sections, are they actually *needed* (right now they are mantained as they are)? Please note how the above are early, preliminary tests and the actual .cmd's need to be cleaned and polished a lot (and quite a bit of "error controls" need to be added to them). jaclaz split_inf.zip

Molecule I am getting maybe half of what you probably mean, I never saw such a behaviour. Unless you - instead of talking of "foreign powers" and "locked open backdoors" - post something meaningful (like the EXACT steps you made to install the 2K, WHICH programs you post-installed to it, etc. etc.) it would be difficult or impossible to help you troubleshoot the issue. 512 megabytes is enough to run a "normal" 2K with no pagefile.sys, for experimenting, I use normally a laptop with 128 Mbytes of RAM and a 256 Mb of pagefile, fixed size, of course without running on it programs requiring lots of RAM and with a reduced number of running services. I do understand how you are annoyed by the whatever is happening on your system, but ranting about MS, suggesting yourself what is the cause and telling us what you want to hear and what you don't want to hear about possible ways to solve the problem may make things unneededly more complex. jaclaz

Why? I mean there is no need of Partition Magic. You can use the filter driver and make the stick "fixed", then partition it "normally" or, unless I am mistaken, since Vista diskpart can be used "directly" on a stick. jaclaz