Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Problem with TmpCreatDOS and DOSBox :(
285 views
Skip to first unread message
Harry Potter
Mar 17, 2015, 9:15:20 AM3/17/15
to
Hi! I have been working on Template Packager for DOS, which is a utility for Template Creator for DOS, and ran into a problem. I couldn't figure out why it couldn't copy files. After some testing and experimentation, I found the problem. TmpCreatDOS and TmpPackDOS rely on the XCOPY command to copy files, and, well, DOSBox doesn't support it. :( I can still use the computers at my mother's house, but I can only go there occasionally. I am not asking for help. I'm just saying what's going on.
R.Wieser
Mar 17, 2015, 11:22:56 AM3/17/15
to
Harry,
Are you sure you need the XCOPY command at all (and not just use COPY) ?
Also, its quite doable to write your own routine to copy multiple files
and/or folders from one place to another.
Regards,
Rudy Wieser
-- Origional message:
Harry Potter <rose.j...@yahoo.com> schreef in berichtnieuws
a8d4fb46-7549-4417...@googlegroups.com...
Are you sure you need the XCOPY command at all (and not just use COPY) ?
Also, its quite doable to write your own routine to copy multiple files
and/or folders from one place to another.
Regards,
Rudy Wieser
-- Origional message:
Harry Potter <rose.j...@yahoo.com> schreef in berichtnieuws
a8d4fb46-7549-4417...@googlegroups.com...
DMcCunney
Mar 17, 2015, 2:59:02 PM3/17/15
to
it wasn't a built-in on real DOS - it was an external command.
If DOSBox is properly set up, with XCOPY in the %PATH% defined, I
believe XCOPY *should* work.
You might also look at vDOS. vDOS is a fork of DOSBox intended for
character mode DOS business apps. It drops the DOSBox stuff intended
for gaming support. It's also Windows specific, and available for Win
XP/Vista/7/8.1.
I have an assortment of old DOS apps running under it on 64 bit Win7.
See https://sourceforge.net/projects/vdos/
______
Dennis
Harry Potter
Mar 17, 2015, 7:08:23 PM3/17/15
to
On Tuesday, March 17, 2015 at 11:22:56 AM UTC-4, R.Wieser wrote:
> Harry,
>
> Are you sure you need the XCOPY command at all (and not just use COPY) ?
>
I believe I can use COPY.
> Harry,
>
> Are you sure you need the XCOPY command at all (and not just use COPY) ?
>
> Also, its quite doable to write your own routine to copy multiple files
> and/or folders from one place to another.
>
All this said, I *still* want to use my current method. Don't know why, though. :(
Harry Potter
Mar 17, 2015, 7:11:15 PM3/17/15
to
On Tuesday, March 17, 2015 at 2:59:02 PM UTC-4, DMcCunney wrote:
> Define "DOSBox doesn't support it". XCOPY is not a DOSBox built-in, but
> it wasn't a built-in on real DOS - it was an external command.
>
I type in XCOPY at the command line and get the response "Illegal command: XCOPY."
> Define "DOSBox doesn't support it". XCOPY is not a DOSBox built-in, but
> it wasn't a built-in on real DOS - it was an external command.
>
> If DOSBox is properly set up, with XCOPY in the %PATH% defined, I
> believe XCOPY *should* work.
>
DMcCunney
Mar 17, 2015, 8:21:50 PM3/17/15
to
and the PATH statement in DOS?
COPY is built into COMMAND.COM, and will work as long as that's the
shell you use. XCOPY is an *external* program.
The DOS PATH command lets you create a list of directories to look in
when you type a command. It's normally issued in AUTOEXEC.BAT, and
takes the form "PATH C:\DOS;C:\BIN;C:\UTILS" - a list of directories
separated by semi-colons. (The above list is just an exab\mple - change
the directory names to what exist on your machine.) Tjhe APTH command
creates a %PATH% variable in the environment, and you can see what it is
by typed SET at a prompt. SET lists the variables defined in the
environment.
DOS looks in whatever directory you are currently in first for a command
with the name you typed, and then in the list provided by the PATH command.
In order to use XCOPY, it must either be in the current directory, or in
a directory listed in the PATH.
Does XCOPY in fact exist on your machine? If it does, is it in a
directory in your PATH?
I would say the answer is no to the second question, and possibly to the
first. Switching to Z: won't help because XCOPY does't exist there. If
it *does* exist on your system, you need to create a PATH statement and
place XCOPY in a directory in that list.
______
Dennis
Harry Potter
Mar 18, 2015, 6:46:11 AM3/18/15
to
On Tuesday, March 17, 2015 at 8:21:50 PM UTC-4, DMcCunney wrote:
> Do you understand the difference between internal and external commands,
> and the PATH statement in DOS?
>
I understand DOS well! :x The problem is with a DOS *emulator*, *not* DOS!
> Do you understand the difference between internal and external commands,
> and the PATH statement in DOS?
>
R.Wieser
Mar 18, 2015, 8:21:24 AM3/18/15
to
Harry,
> I understand DOS well!
No, you don't.
DMcCunney was talking about the PATH environment variable (type SET on a
dosprompt and see what you get), which is very much part of how DOS is able
to find its executables. It does not matter if the environment is DOS, or
the DOS emulator (which should behave the same).
How did you think that DOS is able to find a command like XCOPY (but also
eny other program), when that program isn't in the local folder ?
In short: when an executable isn't in the current directory -- where the OS
always looks first -- it will seach in all the folders named in the PATH
environment variable. Hence, if that variable doesn't include the folder
the executable is in it will not be found (unless you are in that exact
folder ofcourse)
Just as a test: type
echo %TEMP%
and see if the folder the XCOPY command is located in is mentioned. If not
.... Well, there than you have your problem. :-)
To add another folder to an already existing PATH variable you can do this:
set PATH=%PATH%;Z:\SOMEPATH
(notice the semicolon in there)
Regards,
Rudy Wieser
-- Origional message
Harry Potter <rose.j...@yahoo.com> schreef in berichtnieuws
7c1ac9c7-3d2a-4eae...@googlegroups.com...
> I understand DOS well!
No, you don't.
DMcCunney was talking about the PATH environment variable (type SET on a
dosprompt and see what you get), which is very much part of how DOS is able
to find its executables. It does not matter if the environment is DOS, or
the DOS emulator (which should behave the same).
How did you think that DOS is able to find a command like XCOPY (but also
eny other program), when that program isn't in the local folder ?
In short: when an executable isn't in the current directory -- where the OS
always looks first -- it will seach in all the folders named in the PATH
environment variable. Hence, if that variable doesn't include the folder
the executable is in it will not be found (unless you are in that exact
folder ofcourse)
Just as a test: type
echo %TEMP%
and see if the folder the XCOPY command is located in is mentioned. If not
.... Well, there than you have your problem. :-)
To add another folder to an already existing PATH variable you can do this:
set PATH=%PATH%;Z:\SOMEPATH
(notice the semicolon in there)
Regards,
Rudy Wieser
-- Origional message
Harry Potter <rose.j...@yahoo.com> schreef in berichtnieuws
Harry Potter
Mar 18, 2015, 9:28:34 AM3/18/15
to
On Wednesday, March 18, 2015 at 8:21:24 AM UTC-4, R.Wieser wrote:
> Harry,
>
> > I understand DOS well!
>
> No, you don't.
>
> DMcCunney was talking about the PATH environment variable (type SET on a
> dosprompt and see what you get), which is very much part of how DOS is able
> to find its executables. It does not matter if the environment is DOS, or
> the DOS emulator (which should behave the same).
>
> How did you think that DOS is able to find a command like XCOPY (but also
> eny other program), when that program isn't in the local folder ?
>
I know about the PATH variable! :x DOSBox supports it. The problem is that DOSBox doesn't support *XCOPY*!
> Harry,
>
> > I understand DOS well!
>
> No, you don't.
>
> DMcCunney was talking about the PATH environment variable (type SET on a
> dosprompt and see what you get), which is very much part of how DOS is able
> to find its executables. It does not matter if the environment is DOS, or
> the DOS emulator (which should behave the same).
>
> How did you think that DOS is able to find a command like XCOPY (but also
> eny other program), when that program isn't in the local folder ?
>
R.Wieser
Mar 18, 2015, 9:39:47 AM3/18/15
to
Harry,
> The problem is that DOSBox doesn't support *XCOPY*!
How do you *know* that ?
Did the OS tell you that it could not find the command, or did XCOPY itself
throw an error ?
In the first case, have you already searched if its on that Z: drive
somewhere ? If its not there, what about copying it from another DOS
environment. If it however *is* there, how come the OS could not find and
run it ?
In the second case, what was the error ? Without it we have little, if
any, chance to figure out what goes wrong --- and thus no chance to help you
solve the problem.
Regards,
Rudy Wieser
-- Origional message:
Harry Potter <rose.j...@yahoo.com> schreef in berichtnieuws
53bad7ff-1823-4cbc...@googlegroups.com...
> The problem is that DOSBox doesn't support *XCOPY*!
Did the OS tell you that it could not find the command, or did XCOPY itself
throw an error ?
In the first case, have you already searched if its on that Z: drive
somewhere ? If its not there, what about copying it from another DOS
environment. If it however *is* there, how come the OS could not find and
run it ?
In the second case, what was the error ? Without it we have little, if
any, chance to figure out what goes wrong --- and thus no chance to help you
solve the problem.
Regards,
Rudy Wieser
-- Origional message:
Harry Potter <rose.j...@yahoo.com> schreef in berichtnieuws
Harry Potter
Mar 18, 2015, 9:47:05 AM3/18/15
to
On Wednesday, March 18, 2015 at 9:39:47 AM UTC-4, R.Wieser wrote:
> Harry,
>
> Harry,
>
> > The problem is that DOSBox doesn't support *XCOPY*!
>
> How do you *know* that ?
>
I switched to the Z: drive, which is where DOSBox stores supported commands and typed in DIR. It wasn't listed.
>
> How do you *know* that ?
>
> Did the OS tell you that it could not find the command, or did XCOPY itself
> throw an error ?
>
> In the first case, have you already searched if its on that Z: drive
> somewhere ? If its not there, what about copying it from another DOS
> environment. If it however *is* there, how come the OS could not find and
> run it ?
>
> In the second case, what was the error ? Without it we have little, if
> any, chance to figure out what goes wrong --- and thus no chance to help you
> solve the problem.
>
Harry Potter
Mar 18, 2015, 10:03:52 AM3/18/15
to
I'm going to use COPY. Thank you for your support! :)
R.Wieser
Mar 18, 2015, 10:58:45 AM3/18/15
to
Harry,
> I switched to the Z: drive, which is where DOSBox stores
> supported commands and typed in DIR. It wasn't listed.
Have you also tried "DIR Z:\XCOPY*.* /s/b" ? That will look for any file
starting with "xcopy", in the current folder and all below it (in other
words & in the above case: the whole Z: drive)
> I typed in "XCOPY," and the emulator responded with
> an Illegal Command error.
Yep, that means it cannot *find* the command. That does not mean it does
not *support* it though. Quite a difference.
> As I've explained, I'm running on an emulator.
I understood that. To me that doesn't make much, if any difference.
> although I like the suggestions of using the COPY command
> or vDOS instead. :)
You're not going to try to write your own copying code ? Bummer ... :-)
> The next time I go to my mother's house--she has MS-DOS
> and Windows 98 computers--I can grab a copy of XCOPY,
> but I don't think it'll work on DOSBox
When you decide to copy from Win98 you need to be carefull: the "xcopy.exe"
in the "command" subfolder is just a stub, loading the program doing the
actual work. I would suggest taking the one from MS-DOS. I get the
feeling that that one will run just fine.
Regards,
Rudy Wieser
-- Origional message:
Harry Potter <rose.j...@yahoo.com> schreef in berichtnieuws
e613149e-ca1b-49e6...@googlegroups.com...
> I switched to the Z: drive, which is where DOSBox stores
> supported commands and typed in DIR. It wasn't listed.
starting with "xcopy", in the current folder and all below it (in other
words & in the above case: the whole Z: drive)
> I typed in "XCOPY," and the emulator responded with
> an Illegal Command error.
not *support* it though. Quite a difference.
> As I've explained, I'm running on an emulator.
> although I like the suggestions of using the COPY command
> or vDOS instead. :)
> The next time I go to my mother's house--she has MS-DOS
> and Windows 98 computers--I can grab a copy of XCOPY,
> but I don't think it'll work on DOSBox
in the "command" subfolder is just a stub, loading the program doing the
actual work. I would suggest taking the one from MS-DOS. I get the
feeling that that one will run just fine.
Regards,
Rudy Wieser
-- Origional message:
Harry Potter <rose.j...@yahoo.com> schreef in berichtnieuws
Harry Potter
Mar 18, 2015, 11:19:21 AM3/18/15
to
On Wednesday, March 18, 2015 at 10:58:45 AM UTC-4, R.Wieser wrote:
> Harry,
>
> Harry,
>
> > I switched to the Z: drive, which is where DOSBox stores
> > supported commands and typed in DIR. It wasn't listed.
>
> Have you also tried "DIR Z:\XCOPY*.* /s/b" ? That will look for any file
> starting with "xcopy", in the current folder and all below it (in other
> words & in the above case: the whole Z: drive)
>
I typed in DIR Z:\, and it wasn't there. :(
> > supported commands and typed in DIR. It wasn't listed.
>
> Have you also tried "DIR Z:\XCOPY*.* /s/b" ? That will look for any file
> starting with "xcopy", in the current folder and all below it (in other
> words & in the above case: the whole Z: drive)
>
> > I typed in "XCOPY," and the emulator responded with
> > an Illegal Command error.
>
> Yep, that means it cannot *find* the command. That does not mean it does
> not *support* it though. Quite a difference.
>
> > As I've explained, I'm running on an emulator.
>
> I understood that. To me that doesn't make much, if any difference.
>
> > although I like the suggestions of using the COPY command
> > or vDOS instead. :)
>
> You're not going to try to write your own copying code ? Bummer ... :-)
>
> > The next time I go to my mother's house--she has MS-DOS
> > and Windows 98 computers--I can grab a copy of XCOPY,
> > but I don't think it'll work on DOSBox
>
> When you decide to copy from Win98 you need to be carefull: the "xcopy.exe"
> in the "command" subfolder is just a stub, loading the program doing the
> actual work. I would suggest taking the one from MS-DOS. I get the
> feeling that that one will run just fine.
>
R.Wieser
Mar 18, 2015, 12:09:22 PM3/18/15
to
Harry,
> I typed in DIR Z:\, and it wasn't there. :(
That command will only search in the *current* directory. The /s/b
switches will tell it to look further, in all subfolders it might have (and
display the full path of the found item).
> If it *is* supported, where *is* it? :x
I think we've got a language problem here.
That something is supported does not automatically mean its part of the
current package. It might be part of an upgrade packet (seperatily bought).
If XCOPY really is *not supported* than copying it from another OS will not
work, ever. (which, in the case of this command, is not a likely scenario)
As for the answer to your question ? How would I know ? I've suggested you
use the /s/b switches and explained why, and have not heard any results from
it. Neither have you bothered to mention if that Z: drive actually has
subfolders (which absense would negate the need for those switches), leaving
me completely in the dark.
In other words: carefull, you're again going full steam to the point where I
will simply wish you good luck into solving your problem yourself. :-\
Getting help is a *dialog*. If you do not respond to suggestions or
questions others make you make it hard, if not impossible, for the ones
bringing them forward to gouge your situation, and help you find the answer
to your problem
> Well, the DOSBox was said by its creators to target games mainly.
Correct. That means that they where very carefull to support all kinds of
screen access (in that time an unified solution like DirectX didn't exists)
and SoundBlaster compatible audio (there where more, but this one was the
most well-known), as well as to support the in that time known "tricks" to
the OS.
> I could. I mean I can do it. :)
So ? What stops you ? You could learn a thing or two from it along the
way. :-)
> I forgot about that. Thank you for reminding me. :)
> I'll use COPY for now.
You're welcome.
Regards,
Rudy Wieser
-- Origional message:
Harry Potter <rose.j...@yahoo.com> schreef in berichtnieuws
119240a1-d0bb-4a2c...@googlegroups.com...
> I typed in DIR Z:\, and it wasn't there. :(
switches will tell it to look further, in all subfolders it might have (and
display the full path of the found item).
> If it *is* supported, where *is* it? :x
That something is supported does not automatically mean its part of the
current package. It might be part of an upgrade packet (seperatily bought).
If XCOPY really is *not supported* than copying it from another OS will not
work, ever. (which, in the case of this command, is not a likely scenario)
As for the answer to your question ? How would I know ? I've suggested you
use the /s/b switches and explained why, and have not heard any results from
it. Neither have you bothered to mention if that Z: drive actually has
subfolders (which absense would negate the need for those switches), leaving
me completely in the dark.
In other words: carefull, you're again going full steam to the point where I
will simply wish you good luck into solving your problem yourself. :-\
Getting help is a *dialog*. If you do not respond to suggestions or
questions others make you make it hard, if not impossible, for the ones
bringing them forward to gouge your situation, and help you find the answer
to your problem
> Well, the DOSBox was said by its creators to target games mainly.
screen access (in that time an unified solution like DirectX didn't exists)
and SoundBlaster compatible audio (there where more, but this one was the
most well-known), as well as to support the in that time known "tricks" to
the OS.
> I could. I mean I can do it. :)
way. :-)
> I forgot about that. Thank you for reminding me. :)
> I'll use COPY for now.
Regards,
Rudy Wieser
-- Origional message:
Harry Potter <rose.j...@yahoo.com> schreef in berichtnieuws
Rod Pemberton
Mar 18, 2015, 6:38:52 PM3/18/15
to
On Wed, 18 Mar 2015 10:59:43 -0400, R.Wieser <add...@not.available> wrote:
> Harry wrote:
>> I switched to the Z: drive, which is where DOSBox stores
>> supported commands and typed in DIR. It wasn't listed.
>
> Have you also tried "DIR Z:\XCOPY*.* /s/b" ? That will look
> for any file starting with "xcopy", in the current folder and
> all below it (in other words & in the above case: the whole
> Z: drive)
>
>> I typed in "XCOPY," and the emulator responded with
>> an Illegal Command error.
>
> Yep, that means it cannot *find* the command. That does not
> mean it does not *support* it though. Quite a difference.
>
If I access my Windows 98/SE partition, MS-DOS v7.10, from
> Harry wrote:
>> I switched to the Z: drive, which is where DOSBox stores
>> supported commands and typed in DIR. It wasn't listed.
>
> Have you also tried "DIR Z:\XCOPY*.* /s/b" ? That will look
> for any file starting with "xcopy", in the current folder and
> all below it (in other words & in the above case: the whole
> Z: drive)
>
>> I typed in "XCOPY," and the emulator responded with
>> an Illegal Command error.
>
> Yep, that means it cannot *find* the command. That does not
> mean it does not *support* it though. Quite a difference.
>
Linux using DOSBox, executing XCOPY on my C: issues an
"Incorrect MS-DOS version" error message. I'm not going
to attempt SETVER in DOSBox against a real DOS partition.
DOSBox's default path is "PATH=Z:\" which obviously won't
find anything, not that there is much of anything installed
with DOSBox anyway:
Z:\>dir/s
COMMAND.COM
AUTOEXEC.BAT
KEYB.COM
IMGMOUNT.COM
BOOT.COM
INTRO.COM
RESCAN.COM
LOADFIX.COM
MEM.COM
MOUNT.COM
MIXER.COM
CONFIG.COM
I.e., XCOPY doesn't come with DOSBox and Harry will need to
get a DOS which has XCOPY. E.g., FreeDOS supposedly has a
version XCOPY:
http://www.freedos.org/software/?prog=xcopy
Rod Pemberton
DMcCunney
Mar 18, 2015, 7:12:46 PM3/18/15
to
Rod Pemberton wrote:
> I.e., XCOPY doesn't come with DOSBox and Harry will need to
> get a DOS which has XCOPY. E.g., FreeDOS supposedly has a
> version XCOPY:
>
> http://www.freedos.org/software/?prog=xcopy
I have it here, and it works and appears MSDOS XCOPY compatible. If I
> I.e., XCOPY doesn't come with DOSBox and Harry will need to
> get a DOS which has XCOPY. E.g., FreeDOS supposedly has a
> version XCOPY:
>
> http://www.freedos.org/software/?prog=xcopy
put in the a directory in a PATH defined in DOSBox box, I can type XCOPY
at the prompt and it will run and display a usage message.
I *have* seen a quirk. As a test, I put FreeDOS XCOPY in the \MSDOS\bin
directory, which was in the DOS PATH.
I created a tmp sub-directory beneath it, and did "XCOPY *.* TMP" from
the bin directory.
In the vDOS fork of DOSBox, the entire contents of the bin directory got
copied to the tmp sub-directory as expected. In an actual DOSBox
session, only the first file was copied.
I'm not sure what's going on there, since vDOS *is* a fork of DOSBox
code, and to my knowledge only stripped out the video and sound stuff
needed by games. File system handling and copy support shouldn't be
different. I'll poke around some more later.
> Rod Pemberton
______
Dennis
Harry Potter
Mar 18, 2015, 7:53:49 PM3/18/15
to
On Wednesday, March 18, 2015 at 6:38:52 PM UTC-4, Rod Pemberton wrote:
> DOSBox's default path is "PATH=Z:\" which obviously won't
> find anything, not that there is much of anything installed
> with DOSBox anyway:
>
> Z:\>dir/s
>
> COMMAND.COM
> AUTOEXEC.BAT
> KEYB.COM
> IMGMOUNT.COM
> BOOT.COM
> INTRO.COM
> RESCAN.COM
> LOADFIX.COM
> MEM.COM
> MOUNT.COM
> MIXER.COM
> CONFIG.COM
>
> I.e., XCOPY doesn't come with DOSBox and Harry will need to
> get a DOS which has XCOPY. E.g., FreeDOS supposedly has a
> version XCOPY:
>
> http://www.freedos.org/software/?prog=xcopy
>
Rod Pemberton got it right! :D I'm going to switch to COPY at my next opportunity. I only need COPY because I only need to copy one file at a time.
> DOSBox's default path is "PATH=Z:\" which obviously won't
> find anything, not that there is much of anything installed
> with DOSBox anyway:
>
> Z:\>dir/s
>
> COMMAND.COM
> AUTOEXEC.BAT
> KEYB.COM
> IMGMOUNT.COM
> BOOT.COM
> INTRO.COM
> RESCAN.COM
> LOADFIX.COM
> MEM.COM
> MOUNT.COM
> MIXER.COM
> CONFIG.COM
>
> I.e., XCOPY doesn't come with DOSBox and Harry will need to
> get a DOS which has XCOPY. E.g., FreeDOS supposedly has a
> version XCOPY:
>
> http://www.freedos.org/software/?prog=xcopy
>
BTW, I wasn't expecting this response. The main reason for this thread was for informative purposes: I just was sharing what happened. But FreeDOS's XCOPY, vDOS and usage of COPY were good suggestions, and I thank all of you for giving them! :)
Rod Pemberton
Mar 18, 2015, 11:21:33 PM3/18/15
to
On Wed, 18 Mar 2015 19:53:46 -0400, Harry Potter <rose.j...@yahoo.com>
wrote:
> But FreeDOS's XCOPY, vDOS and usage of COPY were good suggestions,
> and I thank all of you for giving them! :)
There are differences between COPY and XCOPY.
COPY can verify that files are copied. /V
XCOPY can copy empty files, i.e., zero byte.
XCOPY can copy subfolders. /S or /E
XCOPY can copy hidden or system files. /H
If you're going to be copying files with
LFNs (Long FileNames) you'll really want
Ortwin Glück's LCOPY from his LFN tools.
It'll copy files with LFNs without needing
DOSLFN to be installed and copies subdirectories
too. I.e., easy to copy your entire system
to a new drive with all LFNs intact.
http://lfntools.sourceforge.net/
Rod Pemberton
wrote:
> But FreeDOS's XCOPY, vDOS and usage of COPY were good suggestions,
> and I thank all of you for giving them! :)
COPY can verify that files are copied. /V
XCOPY can copy empty files, i.e., zero byte.
XCOPY can copy subfolders. /S or /E
XCOPY can copy hidden or system files. /H
If you're going to be copying files with
LFNs (Long FileNames) you'll really want
Ortwin Glück's LCOPY from his LFN tools.
It'll copy files with LFNs without needing
DOSLFN to be installed and copies subdirectories
too. I.e., easy to copy your entire system
to a new drive with all LFNs intact.
http://lfntools.sourceforge.net/
Rod Pemberton
Harry Potter
Mar 19, 2015, 7:14:50 AM3/19/15
to
On Wednesday, March 18, 2015 at 11:21:33 PM UTC-4, Rod Pemberton wrote:
> There are differences between COPY and XCOPY.
>
It doesn't really matter: I am only copying one file at a time. :)
> There are differences between COPY and XCOPY.
>
> If you're going to be copying files with
> LFNs (Long FileNames) you'll really want
> Ortwin Glück's LCOPY from his LFN tools.
> It'll copy files with LFNs without needing
> DOSLFN to be installed and copies subdirectories
> too. I.e., easy to copy your entire system
> to a new drive with all LFNs intact.
>
> http://lfntools.sourceforge.net/
>
DMcCunney
Mar 19, 2015, 2:47:51 PM3/19/15
to
Harry Potter wrote:
>
>> If you're going to be copying files with
>> LFNs (Long FileNames) you'll really want
>> Ortwin Glück's LCOPY from his LFN tools.
>> It'll copy files with LFNs without needing
>> DOSLFN to be installed and copies subdirectories
>> too. I.e., easy to copy your entire system
>> to a new drive with all LFNs intact.
>>
>> http://lfntools.sourceforge.net/
>>
> It couldn't possibly work under DOSBox. :(
It might under vDOS. A user did a quick and dirty hack on it to provide
>
>> If you're going to be copying files with
>> LFNs (Long FileNames) you'll really want
>> Ortwin Glück's LCOPY from his LFN tools.
>> It'll copy files with LFNs without needing
>> DOSLFN to be installed and copies subdirectories
>> too. I.e., easy to copy your entire system
>> to a new drive with all LFNs intact.
>>
>> http://lfntools.sourceforge.net/
>>
> It couldn't possibly work under DOSBox. :(
some LFN support, and it seems to work here. (vDOS's author seems to
have it as a matter of principle that if it wasn't in original MSDOS,
he's not adding it to vDOS. Fortunately, not all agree.)
Let we know if you want a pointer to the patched version.
______
Dennis
Wildman
Jun 14, 2015, 12:53:42 PM6/14/15
to
group in some time. Anyway, I have a little info about DOSBox
that may be of use to you in the future. INT 21h Function 30h,
Get Dos Version, returns version 5.0 in DOSBox. So any external
DOS commands used in DOSBox, such as xcopy, must be from DOS 5.0.
--
<Wildman> GNU/Linux user #557453
May the Source be with you.
Harry Potter
Jun 15, 2015, 7:30:55 AM6/15/15
to
On Sunday, June 14, 2015 at 12:53:42 PM UTC-4, Wildman wrote:
> I know this thread is almost 3 months old as I haven't read this
> group in some time. Anyway, I have a little info about DOSBox
> that may be of use to you in the future. INT 21h Function 30h,
> Get Dos Version, returns version 5.0 in DOSBox. So any external
> DOS commands used in DOSBox, such as xcopy, must be from DOS 5.0.
>
Thank you for the tip! :) Now, where can I find DOS 5.0?
> I know this thread is almost 3 months old as I haven't read this
> group in some time. Anyway, I have a little info about DOSBox
> that may be of use to you in the future. INT 21h Function 30h,
> Get Dos Version, returns version 5.0 in DOSBox. So any external
> DOS commands used in DOSBox, such as xcopy, must be from DOS 5.0.
>
Sjouke Burry
Jun 15, 2015, 8:24:02 AM6/15/15
to
Wildman
Jun 15, 2015, 10:58:32 AM6/15/15
to
with several of the external commands.
http://filetrip.net/pc-downloads/operating-systems/download-ms-dos-50-f28009.html
Below is a DIR output of the disk.
Directory of A:\.
IO SYS 33,430 00-00-1980 0:00
MSDOS SYS 37,394 00-00-1980 0:00
COMMAND COM 47,845 00-00-1980 0:00
EDIT HLP 17,898 00-00-1980 0:00
EDIT COM 413 00-00-1980 0:00
SYS COM 13,440 00-00-1980 0:00
FORMAT COM 33,087 00-00-1980 0:00
FDISK EXE 57,224 00-00-1980 0:00
HIMEM SYS 11,616 00-00-1980 0:00
CONFIG SYS 38 00-00-1980 0:00
AUTOEXEC BAT 29 00-00-1980 0:00
MEM EXE 39,818 00-00-1980 0:00
UNDELETE EXE 13,924 00-00-1980 0:00
UNFORMAT COM 18,576 00-00-1980 0:00
XCOPY EXE 15,820 00-00-1980 0:00
CHKDSK EXE 16,200 00-00-1980 0:00
ATTRIB EXE 15,796 00-00-1980 0:00
LABEL EXE 9,390 00-00-1980 0:00
QBASIC HLP 130,810 00-00-1980 0:00
QBASIC EXE 254,799 00-00-1980 0:00
20 File(s) 767,547 Bytes.
0 Dir(s) 685,056 Bytes free.
--
<Wildman> GNU/Linux user #557453
0 new messages