Ennél az XP -s módszernél tényleg sokkal egyszerûbb, ha mezei DOS lemezekkel, vagy pl. Win98 boot lemezzel indítasz, és FDISK -el particionálsz. De ha már mindenképpen win szörny, akkor legalább azon belül Partition Magic, vagy valami... (Utóbbinak DOS -os veriója is van.) Ez a Win lemezrõl boot -olás, és ott macera szerintem nem az igazi... Pláne, hogy XP, ami elég távol áll már "tõlünk", így amit az particionálás címén néha a vinyón elkövet...

Jaj.... kipróbáltam az újabb FDISK-et, letöröltem a 2 meglévõ partitiot, hideg reset után meg hdd detectáláskor végtelen ciklusban detectálja újra meg újra a vinyót... 

Gafz ezennel kiérdemelt egy bétateszter pirospontot  a felfedezett bugért

A jelenség akkor lép fel, ha van vinyó a rendszerben, de nincs rajtuk egyetlenegy partició se. Ekkor elszabadul a IDE ROM partició listázó programja 
Szerencsére nem végtelen ciklus, csak 256 szóval sok türelem, és tovább megy utána lehet FDISK-kel particiót csinálni, és megszünik a gond.
Az is megoldás, ha bekötünk még egy vinyót, amin van partició.

Következõ IDE.ROM-ban majd likvidálom a hibát

Hála a remek VHD-s mókának, végre egy este alatt sikerült kikísérletezni, hogy miért nem olvassa az MSDOS az EP-n formázott partíciót!
Na persze, hogy megint Bill bácsiék alkottak valami remek, szabványokat semmibe vevõ mókás operációs rendszert, hogy az a...
A PC-n amikor bootolásra használunk egy lemezt, akkor fogja beolvassa a boot szektort, és ráugrik az elejére. Mivel a szektor elején leginkább az adatok eléréséhez szükséges adatok vannak tárolva, ezért az elsõ pár bájton egy ugrás van, ami átugorja a logikai adatblokkot, és a további rendszertöltõ programra ugrik.
Az egyszerû naiv, szabványokat betartó programozó úgy gondolja, hogy neki ezzel az elsõ 3 bájttal nincs semmi dolga, ha nem akar boot programot írni. Benne is van az eredeti FAT szabványban, hogy "rendszernek fenntartva", tartalma nincs meghatározva:
[ Guests cannot view attachments ]
Ha nem foglalkozik vele az ember, akkor Bill bácsiék mûve ezt vágja az ember képébe:
[ Guests cannot view attachments ]
Hiszen ha az a 3 bájt nincs kitöltve, az olyan hatalmas helyreállíthatatlan hiba, ami megakadályozza az összes adat elérését...
Ha az elsõ bájton elhelyezünk egy EBH-t, a harmadikon pedig 90H-t, akkor végre megnyugszik, és hajlandó foglalkozni a lemezen lévõ adatokkal is.
Egyébként erre valószínüleg az IS fiúk is rájöhettek, mivel az EXDOS odarakja ezt... (egyébként anno a suliban ezek szerint ezért nem olvasta a sok hülye PC egyes Atari ST-n formázott lemezeket. EP természetesen igen )

Na ha sikerült leküzdeni ezt a baromságot, még nem lehet hátradölni, ha elkezdenénk megnézni az EP-n feltöltött adatokat, akkor kiderül, hogy a hülye MS-DOS "természetesen" hibásan kezeli a lemezt...
Újabb több óra szívás után rá lehet jönni, hogy a formázó program nevének a végén a verziószámnak legalább 4.0-nak kell lenni! Ha 4-esnél kisebb szám van, akkor önkényesen kitalál saját logikai paramétereket, a boot szektorban megadott valódi paraméterekre meg nagy ívben tojik...
Egész pontosan a pont meglétét, és az elõtti karakter értékét nézi a rohadék.

Ezekután itt egy újabb IDE ROM, amivel már MS-DOS kompatibilis boot szektort lehet formázni. Legalábbis MS-DOS 5.0-val már jó a többi mindenféle DOS meg WIN még ellenõrzésre vár.

Pontosítás, már a 3.1 is jó. A valódi ellenõrzésnél azt nézi, hogy a verziószám elsõ két karaktere nagyobb-e mint 2E33H, ha igen akkor jó, ebbõl következik ha pont helyett nagyobb kódú karakter van, pl _ akkor be lehet írni kisebb verzió számot is ilyen formában: 1_0

Akkor ezek szerint ez is jó: 0EBh, 3Ch, 90h, "mkdosfs"

PC-n onnantól kezdve, hogy túlléptek a FAT12-n, valószínüleg cluster méret optimalizálás okán, már 16M felett is FAT16-t hoznak létre a programok, nem is találtam egyetlen olyan programot se, ami engedné 32M-ig, vagy egyáltalán megkérdezné, hogy milyen FAT típusra gondolunk? (Csak nagyobb méreteknél lehet választani FAT32-t is)
Ami jó hír: ha 16 megás particiókat gyártunk, akkor még az XP is hajlandó FAT12-t létrehozni! Ezeket aztán kezeli a PC meg az EP is.

Én az mkdosfs-t használtam (Linux alatt), azzal be lehetett állítani FAT12-t 32 MB méretű partíciónál is.

A türelmeteket eszelõsen irigylem!  Mikre rá nem jöttök már, õrület! 

Na megnéztem, MS-DOS 5.0, 6.0, 6.2, 6.21, 6.22, 7.0, 7.1, 8.0 mindegyik ugyanarra kényes a boot szektorban.

Remek... Akkor legalább következetesen voltak hülyék Redmondban... 

Voltak hülyébbek is: MS-DOS 4 ami nagyobb bukás volt mint a Windows ME és a Vista együtt véve , annyi adatvesztéssel járó hiba volt benne, hogy az emberek inkább ráfizettek, hogy 3.3-as DOS-t kapjanak...
Annyira vacakra sikerült, hogy eddig nem is sikerült komplett példányt felkutatnom belõle amit találtam több helyen MS-DOS 4.0-nak nevezett csomagot abban is a 4.01-es IO.SYS és MSDOS.SYS van 1989.04.07-es dátummal. Tud valaki eredeti 1988-as 4.0-ás rendszerfájlokat?

A 4.01-et megvizsgálva még durvább dolog derül ki: nemcsak a verziószámos móka van benne, hanem azt is nézi, hogy MSDOS-e a rendszer neve? Ha nem akkor nem a boot szektorba írt logikai adatok alapján kezeli a lemezt, hanem Microsoftos szokás szerint saját kitalált adatok alapján.
És ha ez nem egyezik a lemez valódi logikai adataival, akkor gyorsan adatvesztés, fájlrendszer összeomlás lesz a vége. (Ugyan ez az újabb verzióknál is fent áll, ha nem stimmel a verziószám az izlésének!)
Ilyen súlyos hibáért programozás órán akkora egyest adnának, hogy kilóg a naplóból!

Itt még azért is durva a dolog, mert ekkoriban a Microsoft operációs rendszer koránt sem volt egyeduralkodó, gépeknek legalább a felén PC DOS volt, és volt DR-DOS meg egyebek is.
Még emlékszem is, anno 90 körül mikor kezdtünk ismerkedni a PC-vel az volt a vélemény, hogy IBM PC kompatibilis gépre IBM PC DOS való, MS-DOS csak valami gagyi utánzat valami nevesincs cégtõl 

Mindenesetre az 5.0-ból már kiszedték ezt az MSDOS string ellenõrzést, õk is rájöhettek, hogy ez így nem kóser

4.01-ben még nincs ez az EBH,xx,90H ellenõrzés.