DOS ain't dead

Another practical question: How can I burn a CD in DOS?
I have two tools: CDRecord and Disk-at-one registered.

ASPI drivers have loaded. So, what I have to do?
Case 1 - how to burn a single file? (f.e. AVI)
Case 2 - how to burn a CD image?
Case 3 - how to burn whole directory?

---
DOS-u-akbar!

> Another practical question: How can I burn a CD in DOS?

Dirk Paehl's CDR Tools
http://www.paehl-info.de/cdr/

Windows PE programs, maybe usable with HX DOS.

> Another practical question: How can I burn a CD in DOS?
> I have two tools: CDRecord and Disk-at-one registered.
>
> ASPI drivers have loaded. So, what I have to do?
> Case 1 - how to burn a single file? (f.e. AVI)
> Case 2 - how to burn a CD image?

With CDRecord in command line:

case 1, file hola.avi:

mkisofs -v -iso-level 1 -o hola.iso hola.avi (step 1, create the image)

- The best is put the file that you want burn in the cdrecord directory.

cdrecord -v dev=0,0,0 -dao hola.iso (step 2, burn the image)

- "dev=0,0,0" is your -cd-device: dev=0,0,0 is the first -cd-device (o dvd), dev=0,1,0 the second... if you have doubts "cdrecord -scanbus" shows all devices.

case 2:

(Again) cdrecord -v dev=0,0,0 -dao cd.iso

- Other way to burn a whole CD:

readcd dev=0,0,0 f=cdimage.raw (create a image)
readcd dev=0,0,0 -w f=cdimage.raw (burn the image)

> Case 3 - how to burn whole directory?

I don´t know it, I have never done it.

But the best, read this...
http://cdrecord.berlios.de/old/private/man/cdrecord/index.html

Bye

> Another practical question: How can I burn a CD in DOS?

http://www.freeweb.hu/doscdroast/

---
Forum admin

Laaca wrote:

> Case 1 - how to burn a single file? (f.e. AVI)
> Case 2 - how to burn a CD image?
> Case 3 - how to burn whole directory?

Both "Case 1" and "Case 3" can be converted into "Case 2" using MKISOFS

rr wrote:

> http://www.freeweb.hu/doscdroast/

COOL.

1. It's a GUI only
2. 4 years old and abandoned
3. Doesn't like CTMOUSE

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Another practical question: How can I burn a CD in DOS?
> I have two tools: CDRecord and Disk-at-one registered.

BTW burning CDs in DOS seems to me pure masochism when I can run much user-friendly Nero in windows :) BTW can be burned JolietFS CD from a source LFN directories/files by DOS tools? Can they make a bootable CD/DVD? How about compilnig DVD image when there's 2GB file limit on FAT32? How about > 8-level directory tree depth?

---
DOS gives me freedom to unlimited HW access.

> > http://www.freeweb.hu/doscdroast/
>
> COOL.
>
> 1. It's a GUI only

No. It provides a GUI for command-line tools.

> 3. Doesn't like CTMOUSE

What a "wonderful" error report...

---
Forum admin

> BTW burning CDs in DOS seems to me pure masochism when I can run much
> user-friendly Nero in windows :)

But there are still DOS purists among us.

---
Forum admin

> But there are still DOS purists among us.

OK, r3$p3c+ to them :)
I personally say that don't wan to be purist in every case, simply some jobs can be done easily in other OS or got right OS for right task :)

---
DOS gives me freedom to unlimited HW access.

> BTW burning CDs in DOS seems to me pure masochism when I can run much
> user-friendly Nero in windows :)

But on my second machine in my sleeping room is DOS the only installed OS. (and I am happy with it)

---
DOS-u-akbar!

> But on my second machine in my sleeping room is DOS the only installed OS.
> (and I am happy with it)

OK, but do you really need to burn CDs on this second machine? I also have more than 1 PC but I burn only on main one. I didn't say that its a nonsense, in some cases no choice. But what about the limitations I asked?

---
DOS gives me freedom to unlimited HW access.

> But on my second machine in my sleeping room is DOS the only installed OS.
> (and I am happy with it)

BTW
Laaca, for cz/sk users I added some article about XMM and SATA on
my site
Please check if I didn't write some bullshit there...

---
DOS gives me freedom to unlimited HW access.

rr wrote:

> > 3. Doesn't like CTMOUSE
> What a "wonderful" error report...

It's not a report ... the bug has been known for years I don't consider it as a bug of CTMOUSE and DOSCDROAST seems dead

RayeR wrote:

> BTW burning CDs in DOS seems to me pure masochism when I can
> run much user-friendly Nero in windows

Windows is good

Anyway, even in "Windows" there are some alternatives for CD writing ... less bloated and with a bit more usable design than the Black junk ("Nero")

> BTW can be burned JolietFS CD from a source
> LFN directories/files by DOS tools?

It's a question of MKISOFS'ing ... but should work.

> Can they make a bootable CD/DVD?

See above.

> How about compilnig DVD image when there's 2GB file limit on FAT32?

Missed something ?

Anyway, I dislike DVD's and bloats or any kind. For movies, I'd rather use an external USB HD than DVD's. Reportedly the lifetime of self-brewed DVD's is not very long, and even worse, the old DVD "standard" is now obsolete in favor of some "better" more "blue" and more "density/definition-full" discs with a higher capacity and what's more important even more of absurd copy protection "technology"

> How about > 8-level directory tree depth?

Should be no problem either ...

Regrettably my personal experiences are neither very recent nor very good ... occasionally I'll retest CD brewing in DOS.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Anyway, I dislike DVD's and bloats or any kind. For movies, I'd rather use
> an external USB HD than DVD's.

So you don't like removable and easily transportable disks. Excellent.

> Reportedly the lifetime of self-brewed DVD's is not very long,

Rewriting degrades disks over time. Melting and remelting stresses metal - not a secret.

> and even worse, the old DVD "standard" is now obsolete

Not yet. Relax.

> absurd copy protection "technology"

Only on the disks you tried to pirate.

> Regrettably my personal experiences are neither very recent nor very good

RTFM.

> ... occasionally I'll retest CD brewing in DOS.

I'm waiting for the results.

> Rewriting degrades disks over time. Melting and remelting stresses
> metal - not a secret.

Did he talk about CD/DVD-RW? I though R only. Anyway I readed somewhere that phase-change (RW) medias may have longer durability than R.
But dying medias are common problem. Probably everybody who burns over 10 yars met some unreadable media in his archive. I did big scanning last week and must trash about 30 Philips CD-R about 6 years old because of this (see pictures of rising C1/C2 errors and bad blocks in scan).

So currently I keep important data on HDD and DVD-RAM which I belive more that R/RWs. It would be nice to have UDF (even read only) driver for DOS...

---
DOS gives me freedom to unlimited HW access.

> But dying medias are common problem. Probably everybody who burns over 10
> yars met some unreadable media in his archive. I did big scanning last
> week and must trash about 30 Philips CD-R about 6 years old because of
> this
> (see pictures of rising C1/C2 errors and bad blocks in scan).

Take this with a grain of salt (I'm no expert), but ...

It may help if you burn at low speed, and verifying the data after burning (e.g. ImgBurn) is nice, too. But yeah, make a backup of a backup of a backup ... if you can spare the time. (Actually, I read that Doom's src was rereleased as GPL instead of non-commercial license b/c someone's src to a tweaked OpenGL version was lost in a HD crash.)

P.S. FAT32 has 4 GB for a single filesize limit, no?

> > 3. Doesn't like CTMOUSE
>
> What a "wonderful" error report...

CTmouse 2.1 is reported to fix some bugs (at the expense of no longer being EGA compatible).

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/mouse/eric/

Hi Laaca,

You can test and improve my utilietes. You will need gnu fileutils and perl,sh
etc ...
You can download it from http://home.tiscali.cz/petrs.al/vypal/
the file is burn.zip

David

> It may help if you burn at low speed, and verifying the data after burning

I always burn medias with lower speed than maximum, usualy 1/4 of rated max. speed. I'm not CD factory so don't need to hurry. Then I always check if media is fully readable after burn.
Some medias I tested 3-times from burning and they looked fine, no errors but it messed up this year. I hold CDs in boxes in room temperature ~20C in the dark so I think I cannot do it better. I only cannot defend against polution of air which may oxide/sulfide silver reflection layer (gold layer is very rare nowdays). BTW my oldest medium is TDK Gold 74 min. from 1997 which is still perfectly readable. So you can see that lifetime depends mostly on media quality. That times CD-R was quite expansive, about 10e per one. Then it came to mass production and now I got them for 1/3e so it can be expected lower quality for lower price :(

> P.S. FAT32 has 4 GB for a single filesize limit, no?

Hm, maybe I mixed it with filesize limitation under Win9x on FAT32, I didn't tried under MS/FreeDOS. Anyway CD images maybe up to 4.7G or 9.5G.

---
DOS gives me freedom to unlimited HW access.

> It's not a report ... the bug has been known for years I don't
> consider it as a bug of CTMOUSE and DOSCDROAST seems dead

DOSCDROAST was developed by Istvan Horvath from Hungaria.
It was my friend on Web, I don`t have any news from him via email or cell.

> > BTW burning CDs in DOS seems to me pure masochism when I can
> > run much user-friendly Nero in windows

cdrtools work as nice in pure DOS as Linux or Windows, NERO is not needed

> It's a question of MKISOFS'ing ... but should work.

mkisofs can create any DVD image in pure DOS, no problem.
but Jason Hood`s shucdx doesn`t support UDF, so it is a big problem
how to open DVD-RAM disc.
you can format it by ext3, or FAT32 and read with Paragon driver IFSDRV
from pure DOS, but this I don`t test it.
cdrecord doesn`t support for DVD in pure DOS.

> don't like removable and easily transportable disks. Excellent.

YES.

> Melting and remelting stresses metal - not a secret.

Good to know. Not a good DOSSER, but a good metallurgist at least

> Only on the disks you tried to pirate.

Hey Dude ! You always payed promptly for my pirated DVD's and never complained, piracy DVD's sold by me do work, there is no "tried to" !!!

> RTFM.
> I'm waiting

FO. I'm waiting.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo wrote:

> FAT32 has 4 GB for a single filesize limit, no?

Please finalize your argument/claim: who/what is good/bad now because of this "fact" ?

Rayer wrote:

> Did he talk about CD/DVD-RW? I though R only.

Both.

> somewhere that RW medias may have longer durability than R.

Most claim the opposite

> would be nice to have UDF (even read only) driver for DOS

Maybe ... any benefit of UDF over ISO ? This of course won't help with existing UDF CD/DVD's

> Hm, maybe I mixed it with filesize limitation

Did you study the link ?

> under Win9x on FAT32, I didn't tried under MS/FreeDOS.
> Anyway CD images maybe up to 4.7G or 9.5G

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Maybe ... any benefit of UDF over ISO ? This of course won't help with
> existing UDF CD/DVD's

I mean UDF on DVD-RAM which is widely used for DVD-RAM 'write like on HDD' feature. I think DVD-RAM can be also burned with ISOFS but then you just trashed your money for it.

> > Hm, maybe I mixed it with filesize limitation
>
> Did you study the link ?

What link exaclty? I can only say win9x api and also DJGPP and other C programs uses signed 32bit for file pointers (look at e.g. seek function) and then cannot handle files over 2GB. FAT32 directory entry uses probably unsigned 32bit so may use 4G but then you may have problems to read file in many C programs.

OK, checked on Wiky: "The maximum possible size for a file on a FAT32 volume is 4 GiB minus 1 Byte"

---
DOS gives me freedom to unlimited HW access.

> > Did you study the link ?
> What link exaclty?

?????????? (not new, same as above, you didn't)

> I can only say win9x api and also DJGPP and other C programs uses
> signed 32bit for file pointers (look at e.g. seek function) and
> then cannot handle files over 2GB.

YES.

> FAT32 directory entry uses probably unsigned 32bit so may use 4G but
> then you may have problems to read file in many C programs.

YES.

> OK, checked on Wiky: "The maximum possible size for a file on a FAT32
> volume is 4 GiB minus 1 Byte"

What "Wiky" ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> What link exaclty? I can only say win9x api and also DJGPP and other C
> programs uses signed 32bit for file pointers (look at e.g. seek function)
> and then cannot handle files over 2GB. FAT32 directory entry uses probably
> unsigned 32bit so may use 4G but then you may have problems to read file
> in many C programs.

(quoted from here):

> Here is a list of changes from DJGPP V2.03 to V2.04.
> * The functions _creat, _creatnew and _open now set extended size flag
> in DOS calls to be able to create files with size up to 2^32-1,
> supported on FAT32 volumes.
> * The function llseek added with type offset_t to support file seeks
> up to 2^32-2.
> * The function statfs have been made to report correct values > 2^31
> on FAT32 partitions.
> * The function _invent_inode has been changed to start numbering
> invented inodes from USHRT_MAX+1 to 2^28+1.
> * Functions _is_cdrom_drive, _is_ram_drive and _media_type has been
> taken out of `mntent.c' and made externally callable.
> * New functions _get_fat_size, _get_fs_type and _is_fat32 added.

So, some improved functionality is present in DJGPP 2.04 beta, at least.

> OK, checked on Wiky: "The maximum possible size for a file on a FAT32
> volume is 4 GiB minus 1 Byte"

P.S. I haven't tested this in pure FreeDOS either.

---
Know your limits.h

> > Rewriting degrades disks over time. Melting and remelting stresses metal - not a secret.
>
> Did he talk about CD/DVD-RW? I though R only. Anyway I readed somewhere
> that phase-change (RW) medias may have longer durability than R.
> But dying medias are common problem.

The stability of RW tracks is an inverse function of the number of overwrites. Which is to say, first write can be very stable - but next writes degrade the physical medium, with result similar to repeated overrwriting of magnetic media.

As you note in another message, there are variations in media durability. My guess is that poor plastic sealing is a major factor - with proper sealing, air pollutants count for nothing, and therefore temperature counts for little or nothing. [No chemical contact => No chemical reaction, therefore no reaction rate that can be determined by temperature].

> So currently I keep important data on HDD and DVD-RAM which I belive more that R/RWs.

I tried using CD-RW for a while, to backup working files from HD. It turned out to be too expensive - daily backups killed the CDs fast. For my purposes, adding HDs has been the most cost-effective for backup of working files. And DVD is cheap and reliable enough for backup of original program files, other older files that don't need fastest or most frequent access, etc..

> > don't like removable and easily transportable disks. Excellent.
>
> YES.

YES what? You don't like removable etc.? It's excellent that you don't? Or both?

> > Melting and remelting stresses metal - not a secret.
>
> Good to know. Not a good DOSSER, but a good metallurgist at least

I am neither a DOSSER nor a metallurgist. However, I do use DOS, and part of the computer game is knowing properties of materials.

> > Only on the disks you tried to pirate.
>
> Hey Dude ! You always payed promptly for my pirated DVD's and never
> complained, piracy DVD's sold by me do work, there is no "tried to"
> !!!

You must have me confused with someone else - I have never been your customer.

> > RTFM.
> > I'm waiting
>
> FO.

Ya tozhe tyebya lyublyu.

> I'm waiting.

I'm so happy.

??????????
> (not new, same as above, you didn't)

OK, thx. I don't know about FAT32+. I quickly looked to fatplus.txt and see they use some reserved bits in FAT32 directory entry to extend 32bit size value. It may work well for apps which understand it. But what will say scandisk or NDD to it when found that file had allocated more clusters in FAT chains than is marked in size filed in dir entry? I guess it will try to truncate file according to readed file size and free other clusters. For me is important to have full compatability in win98 and later.

---
DOS gives me freedom to unlimited HW access.

> (quoted from
> here):

Yes I already saw this new feats of 2.04 but still some people uses 2.03 and the most of existing sw is compiled with 2.03 libs and older. I think this new functions don't solve FS limitation but only allow work with big files on advanced OSes like on NTFS in NTVDM box (or maybe NTFSDOS).

---
DOS gives me freedom to unlimited HW access.

> OK, thx. I don't know about FAT32+. I quickly looked to fatplus.txt and
> see they use some reserved bits in FAT32 directory entry to extend 32bit
> size value. It may work well for apps which understand it.
which hardly exist. (AFAIK they don't exist at all. IMHO FAT32+ is a specification of something that will never be implemented)

> But what will
> say scandisk or NDD to it when found that file had allocated more clusters
> in FAT chains than is marked in size filed in dir entry? I guess it will
> try to truncate file
right.

and COPY/XCOPY/Volkow Commander will copy only filesize % 4Gb
etc., show wrong directory info, etc. pp

> > (quoted from
> > here):
>
> Yes I already saw this new feats of 2.04 but still some people uses 2.03
> and the most of existing sw is compiled with 2.03 libs and older.

If you have the sources (luckily, most DJGPP stuff does), then it's just a simple recompile. 2.04 is bigger (more "bloated", heh), but it's also much improved. The only reason it isn't default is because it's unfinished (and even then, I think it should be default).

> I think
> this new functions don't solve FS limitation but only allow work with big
> files on advanced OSes like on NTFS in NTVDM box (or maybe NTFSDOS).

I dunno, never tried in pure FreeDOS, but in theory, FreeDOS should work (although probably doesn't). Oh well, testers wanted!

---
Know your limits.h

> > OK, thx. I don't know about FAT32+. I quickly looked to fatplus.txt and
> > see they use some reserved bits in FAT32 directory entry to extend
> 32bit
> > size value. It may work well for apps which understand it.
> which hardly exist. (AFAIK they don't exist at all. IMHO FAT32+ is a
> specification of something that will never be implemented)

Well, only EDR-DOS has it now. And it's hard to write compatible apps for an API that doesn't exist (e.g. FreeDOS).

>
> > But what will
> > say scandisk or NDD to it when found that file had allocated more
> clusters
> > in FAT chains than is marked in size filed in dir entry? I guess it
> will
> > try to truncate file
> right.
>
> and COPY/XCOPY/Volkow Commander will copy only filesize % 4Gb
> etc., show wrong directory info, etc. pp

Obviously, avoid using any of your previous low-level tools in such a case. I'm sure FD XCOPY could be updated, but the other closed-src stuff (Volkov) ... no way. But anyways, in DOS, most files aren't that huge, so the issue is pretty moot (unless you want to rip DVDs a lot, heh).

---
Know your limits.h

> If you have the sources (luckily, most DJGPP stuff does), then it's just a
> simple recompile. 2.04 is bigger (more "bloated", heh), but it's
> also much improved. The only reason it isn't default is because it's
> unfinished (and even then, I think it should be default).

Just a recompiling may not be enough, you may need to replace some functions and extend some variables to hadle right 64bit pointers/offsets.
BTW do you thing 2.04 become oficial? It's beta for several years. I don't know if its updated somewhere on cvs but binaries are pretty old.

---
DOS gives me freedom to unlimited HW access.

> (Volkov) ... no way. But anyways, in DOS, most files aren't that huge, so
> the issue is pretty moot (unless you want to rip DVDs a lot, heh).

I think that better way for DOS ripper/imager/burner would be to accept multiple files of splitted image (up to 2GB), eg. mydvd.iso, mydvd.i00, mydvd.i01...
when such .i?? files will be detected it would be automatically apanded on further data request. I used some DVD riper in win98 and also Nero do it same way on FAT32.

But I don't trash FAT32+ idea. If kernel developers of dr/free/other dos will accept same API extension - function numer - parameters order it would be then easy to use it in new programs.

---
DOS gives me freedom to unlimited HW access.

> I think that better way for DOS ripper/imager/burner would be to accept
> multiple files of splitted image (up to 2GB), eg. mydvd.iso, mydvd.i00,
> mydvd.i01...
right.

> But I don't trash FAT32+ idea. If kernel developers of dr/free/other dos
> will accept same API extension - function numer - parameters order it
> would be then easy to use it in new programs.
FAT32+ is a nice hack, and not difficult to implement.

OTOH, you can't CHKDSK any longer (and judging by experience not running
CHKDSK onve in a while is no particular clever idea), unless CHKDSK is updated.

You can't use XCOPY and friends.

Just booting Linux/Windows/... on this maschine might trigger a CHKDSK,
and your big Files are gone. Users won't love that ;)

IMO the only user of files > 4Gb are DVD rippers, burners, ... anyway, and its better (saver) if they implement a .ISO, .IS1, .IS2 scheme

> Ya tozhe tyebya lyublyu.

Dilbuempas ketranco ku vex.

EOD

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> looked to fatplus.txt and see they use some reserved bits in FAT32
> directory entry to extend 32bit size value.

YES.

> It may work well for apps which understand it. But what will say
> scandisk or NDD to it when found that file had allocated more clusters
> in FAT chains than is marked in size filed in dir entry? I guess it
> will try to truncate file according to readed file size and
> free other clusters.

You should NOT chase obsolete low level tooks (NDD/SCANDISK/...) to FAT32+ volumes - YES, the files will get truncated, at best. Thus, you would have to split/move out those files before. Anyway, this problem is not new: old MS-DOG <= 5 era tools will trash FAT32 volumes as well s LFN's

> For me is important to have full compatability in win98 and later.

For me it's important to get rid of MS-DOG and "later" ... future of DOS should not depend of M$ Anyway, read compatibility is perfect, and probably even writing of < 2GiB files.

> Yes I already saw this new feats of 2.04 but still some people uses
> 2.03 and the most of existing sw is compiled with 2.03 libs and older.

IIRC such "big" files support means 2 GiB ... 4 GiB only ... and is badly designed, immature and unusable. Reportedly doesn't work on FreeDOS either. FAT32+ is a much better approach. I wouldn't recommend to exceed 2 GiB the "old" FAT/FAT32 way ... it can work or not. (XP itself has 4 GiB limit on FAT32 for native apps.)

> I think this new functions don't solve FS limitation but only allow work with big files on advanced OSes like on NTFS in NTVDM box (or maybe NTFSDOS).

NTVDM is an advanced OS ?

But that's what D**PP targets http://www.drdosprojects.de/forum/drp_forum/posts/6546.html (OK, D**PP has some usefulness, see MPLAYER - it's a problematic product with 2 very different sides )

> BTW do you thing 2.04 become oficial?

No idea ... maybe there is no project goal ? Then one obviously can't finalize it

> think that better way for DOS ripper/imager/burner would be to
> accept multiple files of splitted image (up to 2GB), eg.
> mydvd.iso, mydvd.i00, mydvd.i01...

1. "splitted" -> "split" (yesterday, I pointed someone else to this bug last, no idea how many times total )
2. YES, split is an alternative good idea that should be developed/kept, but not "better" that FAT32+

> But I don't trash FAT32+ idea. If kernel developers of dr/free/other
> dos will accept same API extension - function numer - parameters
> order it would be then easy to use it in new programs.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Here is a list of changes from DJGPP V2.03 to V2.04.
> * The functions _creat, _creatnew and _open now set extended size flag
> in DOS calls to be able to create files with size up to 2^32-1,
> supported on FAT32 volumes.
> * The function llseek added with type offset_t to support file seeks
> up to 2^32-2.
> So, some improved functionality is present in DJGPP 2.04 beta, at least.

Discussable

> P.S. I haven't tested this in pure FreeDOS either.

No need - it doesn't work, 2 GiB is the limit of FreeDOS by now.

> have the sources (luckily, most DJGPP stuff does), then it's just a
> simple recompile. 2.04 is bigger (more "bloated", heh),
> but it's also much improved.

Not really - you won't get more on FreeDOS, and 4 GiB on EDR-DOS at best (untested)

> I dunno, never tried in pure FreeDOS, but in theory,
> FreeDOS should work (although probably doesn't).

See above, 2 GiB limit. I would recommend throwing away the ugly 4 GiB "extended size flag" hack and move to FAT32+ directly instead.

> Oh well, testers wanted!

YOU ? (no Box, no Vista)

> Well, only EDR-DOS has it now. And it's hard to write compatible
> apps for an API that doesn't exist (e.g. FreeDOS).

It perfectly exists. Just you can't test on FreeDOS.

> Obviously, avoid using any of your previous low-level tools in such a case.



> I'm sure FD XCOPY could be updated, but the other closed-src stuff
> (Volkov) ... no way. But anyways, in DOS, most files aren't that huge,
> so the issue is pretty moot (unless you want to rip DVDs a lot, heh).

Exactly. Keep using your Volkov, just don't touch files > 2 GiB with it.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Tom wrote:

> which hardly exist.

True, but can change.

> IMHO FAT32+ is a specification of something that will never be implemented)

It should be. Not in the next kernel/distro (there are enough bugs pending), but after

> and COPY/XCOPY/Volkow Commander will copy only filesize % 4Gb
> etc., show wrong directory info, etc. pp

I see no problem. You probably won't have 1000's of such files - just care about those 1...3 you might have.

> FAT32+ is a nice hack, and not difficult to implement.

A nice innovation from independent DOS developers, no hack at all

> OTOH, you can't CHKDSK any longer (and judging by experience not
> running CHKDSK onve in a while is no particular clever idea),
> unless CHKDSK is updated.

Temporarily remove those files, CHKDSK should get updated one day.

> You can't use XCOPY and friends.

You probably won't have > 2 GiB files inside a huge DIR structure

> Just booting Linux/Windows/... on this maschine might trigger a
> CHKDSK, and your big Files are gone. Users won't love that

NO. Prohibit them accessing this partition. Or store them on external HD.

> IMO the only user of files > 4Gb are DVD rippers, burners, ...

Video editing

> anyway, and its better (saver) if they implement a .ISO, .IS1, .IS2 scheme

It's also good ... but not instead of FAT32+.

Udo wrote:

> Well, I would be satisfied if I would ever read on the box of
> some software: "Minimum system requirements: MS-DOS 6 or higher,
> Enhanced DR-DOS or FreeDOS recommended".

I appreciate Udo's work on FAT32+ implementation (less banning me from his forum, of course)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> You should NOT chase obsolete low level tooks (NDD/SCANDISK/...) to
> FAT32+ volumes - YES, the files will get truncated, at best. Thus, you
> would have to split/move out those files before. Anyway, this problem is
> not new: old MS-DOG <= 5 era tools will trash FAT32 volumes as well s
> LFN's

[snip]

> For me it's important to get rid of MS-DOG and "later" ... future of DOS
> should not depend of M$ Anyway, read compatibility is perfect, and
> probably even writing of < 2GiB files.

If this is a try to "sell" us FAT32+ then I'd suggest to improve your argumentation, because it's "not very convincing". Actually, your reasons almost sound like "lucho"-arguments.

---
MS-DOS forever!

> > Ya tozhe tyebya lyublyu.
>
> Dilbuempas ketranco ku vex.

It seems you know a language that I don't. That's nice.

> EOD

Because you say so?

> For me it's important to get rid of MS-DOG and "later"

And then what?

> ... future of DOS should not depend of M$

1) It doesn't - MS no longer develops it.
2) The future of DOS does however depend on maintaining (a high degree of) application compatibility with MS & PC DOS. Reason: MS & PC DOS still have many users. It cannot be assumed that all will switch to new DOSes any more than they have switched to Windows.

> But that's what D**PP targets

Is the set of D**PPs larger than DJGPP only? If yes, what are the other D**PPs?

> 1. "splitted" -> "split" (yesterday, I pointed someone else to this bug
> last, no idea how many times total

I am not usually one of those who attacks people who do not use English perfectly because it is not their mother tongue, but for you I will make an exception: Be careful of pointing out the mistakes of other non-native users - unless you want to make me laugh.

This whole thing is ridiculous :)

Why bother implementing any kind of "FAT32+" or hack? If it's not supported by the current DOSes, then there's absolutely no point.

It's not backwards compatible.

If you're breaking backwards compatibility, you might as well *DO IT RIGHT*

Why not adopt a good file system that already exists rather than make yet another crappy, poorly designed FAT?

UFS? FFS? Reiser?

This way you'd have interoperability with other OSes with an FS aside from FAT, rather than a crappy file system that no OSes recognise other than a DOS or two.

> > 1. "splitted" -> "split" (yesterday, I pointed someone else to this bug
> > last, no idea how many times total
>
> I am not usually one of those who attacks people who do not use English
> perfectly because it is not their mother tongue, but for you I will make
> an exception: Be careful of pointing out the mistakes of other non-native
> users - unless you want to make me laugh.

No! Even non-native English speakers - and even if their English skills are "low" - may report a "bug" in someone's else English in this forum. You have no privileges here.

After all, I also report bugs in other people's software, despite I'm pretty sure that my own program's contain such bugs as well.

---
MS-DOS forever!

> > I think this new functions don't solve FS limitation but only allow work
> with big files on advanced OSes like on NTFS in NTVDM box (or maybe
> NTFSDOS).
>
> NTVDM is an advanced OS ?

I just wanted to say that Winnt-xp is advanced OS with advanced FS (NTFS) which doesn't have this 2 or 4G limit. So then if you run a new DJGPP program here it can utilize big files too as advantage of NTFS. But if you run it on FAT under DOS you cannot use big files. Only when you use FAT32+ compliant DOS (and maybe also libc fix would be needed to use new API).

> 1. "splitted" -> "split" (yesterday, I pointed someone else to this bug
> last, no idea how many times total )
> 2. YES, split is an alternative good idea that should be developed/kept,
> but not "better" that FAT32+

Well, I'm not such ignorant which doesn't know about irregular verbs but I don't remember them all. So when I type quickly some reply to the forum I don't care about it. If I would write an article to web then maybe I will try to use dictionary for it. Sorry for making you crying on my bad english but i think most people here will understand the text anyway and this is the goal, not to have perfect language exercise :).
It seems to be a common phenomen on forums. Czech language has many difficulties which leads to that also on czech forums are many linguist purists battles between czech people. I must agree that sometimes it also make me crying to see many others mistakes but I usually don't tell anything to keep discussion on theme (if it is information valuable) instead starting or supporting FW. As we could see (treads/pages) below how easy is to make FW here so I'll not reply to this anymore.

---
DOS gives me freedom to unlimited HW access.

> Why not adopt a good file system that already exists rather than make yet
> another crappy, poorly designed FAT?

> This way you'd have interoperability with other OSes with an FS aside from
> FAT, rather than a crappy file system that no OSes recognise other than a DOS
> or two.

I couldn't agree more.

> No! Even non-native English speakers - and even if their English skills
> are "low" - may report a "bug" in someone's else English in this forum.

I was only having a little fun with DOS386, who so loves to point out bugs while not committing any himself.

> You have no privileges here.

I only claimed the privilege of laughing.

> After all, I also report bugs in other people's software, despite I'm
> pretty sure that my own program's contain such bugs as well.

Your reporting is fair, then - a different case.

> BTW do you thing 2.04 become oficial? It's beta for several years. I don't
> know if its updated somewhere on cvs but binaries are pretty old.

There's still a bunch of patches DJ hasn't merged yet. He's still working on it, AFAIK, but very slowly (busy with other things, I guess). Mucho thanks to Juan Manuel Guerrero for all his hard work on porting stuff (among others)!

---
Know your limits.h

> > BTW do you thing 2.04 become oficial? It's beta for several years. I
> don't
> > know if its updated somewhere on cvs but binaries are pretty old.
>
> There's still a bunch of patches DJ hasn't merged yet. He's still working

Yes? There are updates at CVS now, but not from DJ...

> mkisofs can create any DVD image in pure DOS, no problem.
> but Jason Hood`s shucdx doesn`t support UDF, so it is a big problem
> how to open DVD-RAM disc.

Yes, I contacted Jason before some years and ask him for UDF support. He made 1st attempt to create a very simple test utility which sucessfully listed files from UDF formatted DVD-RAM media under DOS. But that was all I got. He's probably busy or have another priority. Maybe if there will be more people needing UDF and will contact Jason, then we may see further progress (I mean try to mail Jason just now :). I still have his small test program if you want to try it but unfortunately binary only.

---
DOS gives me freedom to unlimited HW access.

> Yes, I contacted Jason before some years and ask him for UDF support. He
> made 1st attempt to create a very simple test utility which sucessfully
> listed files from UDF formatted DVD-RAM media under DOS. But that was all
> I got. He's probably busy or have another priority. Maybe if there will be
> more people needing UDF and will contact Jason, then we may see further
> progress (I mean try to mail Jason just now :). I still have his small
> test program if you want to try it but unfortunately binary only.

when You will burn DVD with NERO and etc. in Windows, you should read it
in pure DOS, the big problem starts when you burn DVD in Linux. It will not
works with burn soft, but cdrecord works in command line.