DOS and Vista ?
Rodney
--
...
`·.¸¸.·´¯`·.¸¸.·´¯`·-> rodney
Auric__
>Any word on how DOS apps run under Vista?
Worse than ever, I'm sure.
--
auric dot auric at gmail dot com
*****
These are not free-range boobies!
Michael Bednarek
>Any word on how DOS apps run under Vista?
1) You need to be more specific. I'm sure MS-Kermit (DOS) will not run;
I'm similarly certain that Adventure ("You are in a maze of twisty
little passages, all alike") will.
2) I think it's a safe to assume they run just as well as they did under
previous versions of NT - or not.
3) I don't understand the need. If you have to use a program which
requires a certain platform, you have to run it on that platform.
Given that hardware for DOS is almost free, I wonder: what's the
point?
--
Michael Bednarek http://mbednarek.com/ "POST NO BILLS"
Dave R.
news:eyrMe.19097$Rm3....@bignews4.bellsouth.net...
> Any word on how DOS apps run under Vista?
From what I have read, Vista will not have 16-bit support at all. From
an eWeek article May 5, 2004:
"Not included in 64-bit Windows are some legacy subsystems like 16-bit
support, the OS/2 subsystem and the portable operating-system interface
for Unix [Posix]. Some of the legacy transport protocols will also be
lost," Brian Marr, product manager for the Windows 64-bit client, said
Wednesday at a session on 64-bit computing during the Windows Hardware
Engineering Conference (WinHEC) here.
Rest of article at http://www.eweek.com/article2/0,1895,1585522,00.asp
So unless someone writes a DOS emulator (and I suspect someone will),
you won't be able to run DOS apps under Vista.
Regards,
Dave
Dave R.
"Michael Bednarek" <ROT13-a...@gtz.pbz.nh> wrote in message
news:r6c5g1h2aikelur1i...@4ax.com...
> On Tue, 16 Aug 2005 16:04:16 -0400, "Rodney"
> <NoMoreSpamP...@ars-florida.com> wrote in alt.msdos.batch:
>
>>Any word on how DOS apps run under Vista?
>
> 1) You need to be more specific. I'm sure MS-Kermit (DOS) will not
> run;
> I'm similarly certain that Adventure ("You are in a maze of twisty
> little passages, all alike") will.
Unless Adventure has a 32-bit or better port, it won't run - or at
least, MS has said that Vista won't have 16-bit support. See my
response to the OP.
> 2) I think it's a safe to assume they run just as well as they did
> under
> previous versions of NT - or not.
Or not. Again, see my response to the OP.
> 3) I don't understand the need. If you have to use a program which
> requires a certain platform, you have to run it on that platform.
> Given that hardware for DOS is almost free, I wonder: what's the
> point?
Certainly there may be other reasons, but for me and the company I work
for, the point is that we have several thousand legacy (16-bit DOS
based) systems in the field. We need to be able to provide technical
support for these systems. The best and most efficient way to do this
is to run the UI portion of the system and the various (also 16-bit)
tools developed over the years on our (currently Windows XP)
workstations using customer configuration and data stored on our
(Microsoft Domain-based) network. If we were to have to provide and
maintain a second machine for all of our support reps that handle the
DOS systems, it would be a major headache.
So for us, Vista is a non-starter unless and until someone writes an
emulator (VMWare, are you listening?).
Regards,
Dave
Rodney
someone can't port a DOS emulator for Vista.
Since the Vista Beta has been out for a few weeks now, I was hoping to hear
back by now just exactly how DOS apps are behaving when running (or
attempting to run) under the Beta.
M$ did a fine job (IMHO) getting DOS apps to run under XP.... and I rarely
give M$ kudos.
Dave R.
> Well, if a DOS Emulator can run fine under Linux, I see no reason why
> someone can't port a DOS emulator for Vista.
Likewise - I just haven't found one for Vista (or WinXP x64) yet.
> Since the Vista Beta has been out for a few weeks now, I was hoping to
> hear
> back by now just exactly how DOS apps are behaving when running (or
> attempting to run) under the Beta.
So am I, but I've not yet seen any actual real-world test data about how
16-bit/DOS apps work under Vista. I have seen reports that DOS and
16-bit executables didn't work at all or appeared to work initially but
then halted abruptly under WinXP x64, so that probably gives a good idea
of what will happen in Vista.
> M$ did a fine job (IMHO) getting DOS apps to run under XP.... and I
> rarely
> give M$ kudos.
MS didn't "get DOS apps to run" under XP. All they did was to _not_
remove the 16-bit support already in the code base when they built XP.
So perhaps they deserve thanks for that at least.
Regards,
Dave
Dr John Stockton
Wed, 17 Aug 2005 03:48:19, seen in news:alt.msdos.batch, Michael
Bednarek <ROT13-a...@gtz.pbz.nh> posted :
>
>3) I don't understand the need. If you have to use a program which
> requires a certain platform, you have to run it on that platform.
> Given that hardware for DOS is almost free, I wonder: what's the
> point?
Hardware may be cheap, but space to put it may not be available.
If one is working on a Vista platform, one may want to use the tools
that one has become used to for tasks that one commonly does, using
files on the Vista machine.
If I get Vista, I can see myself recompiling a number of 16-bit Pascal
programs as 32-bit in Delphi; I've been happy to keep them as 16-bit in
Win98 because speed is not an issue, and I still have older machines.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; Win98. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
Clay Calvert
dot com> wrote:
>"Rodney" <NoMoreSpamP...@ars-florida.com> wrote in message
>news:eyrMe.19097$Rm3....@bignews4.bellsouth.net...
>> Any word on how DOS apps run under Vista?
>
>From what I have read, Vista will not have 16-bit support at all. From
>an eWeek article May 5, 2004:
The current beta has the following .com files in the system32
directory. Edlin.exe was also present. I'd think that the 32-bit
version will have 16-bit support, becuause many people will still have
16-bit apps to run on 'older' hardware.
chcp.com
COMMAND.COM
diskcomp.com
diskcopy.com
edit.com
format.com
graftabl.com
GRAPHICS.COM
KB16.COM
LOADFIX.COM
mode.com
more.com
tree.com
win.com
Clay Calvert
CCal...@Wanguru.com
Replace "W" with "L"
Timo Salmi
> "Dave R." <dwragle at drbsystems dot com> wrote:
> >"Rodney" <NoMoreSpamP...@ars-florida.com> wrote
> >From what I have read, Vista will not have 16-bit support at all. From
> directory. Edlin.exe was also present. I'd think that the 32-bit
> version will have 16-bit support, becuause many people will still have
> 16-bit apps to run on 'older' hardware.
Although my question goes way beyond batches, even if related, what
decisive advantages will Vista offer over XP? What motivation will
we users have to upgrade, especially if losing some of the present
functionality? Or will this be forcing our hands by MS?
I can see the advantages (and a few drawbacks) of the going from
Win../95/98/Me to XP, having done that, but the next step?
Yes, I've read a couple of comments about MSH, but?
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Useful script files and tricks ftp://garbo.uwasa.fi/pc/link/tscmd.zip
Michael Bednarek
wrote in alt.msdos.batch:
What about DEBUG.EXE? Has anyone tried to run any of these, e.g.
EDIT.COM?
Are NTVDM.EXE, WOW32.DLL and WOWEXEC.EXE present?
And what does CMD's VER report?
Clay Calvert
wrote:
>Although my question goes way beyond batches, even if related, what
>decisive advantages will Vista offer over XP? What motivation will
>we users have to upgrade, especially if losing some of the present
>functionality? Or will this be forcing our hands by MS?
The question is related. It looks like many of the commands added to
2003 have been put into Vista, such a ForFiles and Choice.exe, which
were not in XP or 2000. However, these commands are available in
Admin Paks or free portions of Resource Kits.
The GUI has some extra frippery, that I'd try to turn off. There is
no real need for menus fading in and out, etc..
>I can see the advantages (and a few drawbacks) of the going from
>Win../95/98/Me to XP, having done that, but the next step?
At this point I see no significant advantage to Vista. As you said,
it may be a step backward due to lost functionality. I never switched
from 98SE to ME because I didn't see any reason to do so.
>Yes, I've read a couple of comments about MSH, but?
Now MS has stated that MSH was never intended for the workstation
version of longhorn. The new command shell was the main thing that
interested me.
Clay Calvert
<ROT13-a...@gtz.pbz.nh> wrote:
>What about DEBUG.EXE? Has anyone tried to run any of these, e.g.
>EDIT.COM?
>
>Are NTVDM.EXE, WOW32.DLL and WOWEXEC.EXE present?
Yes to all of the above.
>And what does CMD's VER report?
Microsoft Windows [Version 6.0.5112]
Now you'll probably refer to it as NT 6.0. Well, just like the last
two OSes from MS. This is nothing like NT.
WSH is still version 5.6. No surprise there.
Here's the output of Help.
For more information on a specific command, type HELP command-name
ASSOC Displays or modifies file extension associations.
ATTRIB Displays or changes file attributes.
BREAK Sets or clears extended CTRL+C checking.
BOOTCFG Sets properties in boot.ini file to control boot
loading.
CACLS Displays or modifies access control lists (ACLs) of
files.
CALL Calls one batch program from another.
CD Displays the name of or changes the current directory.
CHCP Displays or sets the active code page number.
CHDIR Displays the name of or changes the current directory.
CHKDSK Checks a disk and displays a status report.
CHKNTFS Displays or modifies the checking of disk at boot time.
CLS Clears the screen.
CMD Starts a new instance of the Windows command
interpreter.
COLOR Sets the default console foreground and background
colors.
COMP Compares the contents of two files or sets of files.
COMPACT Displays or alters the compression of files on NTFS
partitions.
CONVERT Converts FAT volumes to NTFS. You cannot convert the
current drive.
COPY Copies one or more files to another location.
DATE Displays or sets the date.
DEL Deletes one or more files.
DIR Displays a list of files and subdirectories in a
directory.
DISKCOMP Compares the contents of two floppy disks.
DISKCOPY Copies the contents of one floppy disk to another.
DISKPART Displays or configures Disk Partition properties.
DOSKEY Edits command lines, recalls Windows commands, and
creates macros.
DRIVERQUERY Displays current device driver status and properties.
ECHO Displays messages, or turns command echoing on or off.
ENDLOCAL Ends localization of environment changes in a batch
file.
ERASE Deletes one or more files.
EVENTQUERY Displays event log entries for specified criteria.
EXIT Quits the CMD.EXE program (command interpreter).
FC Compares two files or sets of files, and displays the
differences between them.
FIND Searches for a text string in a file or files.
FINDSTR Searches for strings in files.
FOR Runs a specified command for each file in a set of
files.
FORMAT Formats a disk for use with Windows.
FSUTIL Displays or configures the file system properties.
FTYPE Displays or modifies file types used in file extension
associations.
GOTO Directs the Windows command interpreter to a labeled
line in
a batch program.
GPRESULT Displays Group Policy information for machine or user.
GRAFTABL Enables Windows to display an extended character set in
graphics mode.
HELP Provides Help information for Windows commands.
IF Performs conditional processing in batch programs.
LABEL Creates, changes, or deletes the volume label of a
disk.
MD Creates a directory.
MKDIR Creates a directory.
MODE Configures a system device.
MORE Displays output one screen at a time.
MOVE Moves one or more files from one directory to another
directory.
OPENFILES Displays files opened by remote users for a file share.
PAGEFILECONFIG Displays or configures Pagefile properties.
PATH Displays or sets a search path for executable files.
PAUSE Suspends processing of a batch file and displays a
message.
POPD Restores the previous value of the current directory
saved by
PUSHD.
PRINT Prints a text file.
PROMPT Changes the Windows command prompt.
PUSHD Saves the current directory then changes it.
RD Removes a directory.
RECOVER Recovers readable information from a bad or defective
disk.
REM Records comments (remarks) in batch files or
CONFIG.SYS.
REN Renames a file or files.
RENAME Renames a file or files.
REPLACE Replaces files.
RMDIR Removes a directory.
SET Displays, sets, or removes Windows environment
variables.
SETLOCAL Begins localization of environment changes in a batch
file.
SC Displays or configures services (background processes).
SCHTASKS Schedules commands and programs to run on a computer.
SHIFT Shifts the position of replaceable parameters in batch
files.
SHUTDOWN Allows proper local or remote shutdown of machine.
SORT Sorts input.
START Starts a separate window to run a specified program or
command.
SUBST Associates a path with a drive letter.
SYSTEMINFO Displays machine specific properties and configuration.
TASKLIST Displays all currently running tasks including
services.
TASKKILL Kill or stop a running process or application.
TIME Displays or sets the system time.
TITLE Sets the window title for a CMD.EXE session.
TREE Graphically displays the directory structure of a drive
or
path.
TYPE Displays the contents of a text file.
VER Displays the Windows version.
VERIFY Tells Windows whether to verify that your files are
written
correctly to a disk.
VOL Displays a disk volume label and serial number.
XCOPY Copies files and directory trees.
WMIC Displays WMI information inside interactive command
shell.
Thanks,
Clay
Michael Bednarek
The article you quote refers clearly to the X64 architecture. Vista and
X64 are not the same thing. I'm pretty sure that Vista comes in both
flavours.
From Clay's response we can deduce that EDIT.EXE and EDLIN.COM will run
under Vista. So, my original response is probably true.
"I'm sure MS-Kermit (DOS) will not run; I'm similarly certain that
Adventure ("You are in a maze of twisty little passages, all alike")
will."
NTVDM seems still alive. The OP (Rodney) should be more specific which
"DOS" programs he enquires about.
Ted Davis
<ccal...@Wanguru.com> wrote:
>The new command shell was the main thing that
>interested me.
It interested other people too: there are already four
proof-of-concept viruses for it.
--
T.E.D. (tda...@gearbox.maem.umr.edu)
SPAM filter: Messages to this address *must* contain "T.E.D."
somewhere in the body or they will be automatically rejected.
Dave R.
"Clay Calvert" <ccal...@Wanguru.com> wrote in message
news:dpf7g19duui5pc5nt...@4ax.com...
> On Wed, 17 Aug 2005 08:00:53 -0400, "Dave R." <dwragle at drbsystems
> dot com> wrote:
>
>>"Rodney" <NoMoreSpamP...@ars-florida.com> wrote in message
>>news:eyrMe.19097$Rm3....@bignews4.bellsouth.net...
>>> Any word on how DOS apps run under Vista?
>>
>>From what I have read, Vista will not have 16-bit support at all.
>>From
>>an eWeek article May 5, 2004:
<snip>
> I'd think that the 32-bit
> version will have 16-bit support, becuause many people will still have
> 16-bit apps to run on 'older' hardware.
A bit more investigation shows that you are correct and I was mistaken -
or at least partially. The 32-bit version of Vista will indeed
have16-bit support, but the 64-bit versions of XP and Vista will not.
My apologies for the misinformation and any confusion it may have
caused.
Regards,
Dave
Dave R.
"Michael Bednarek" <ROT1...@zorqanerx.pbz> wrote in message
news:ntk8g1ltb1kefq1un...@4ax.com...
A bit more investigation shows that you are correct and I was mistaken -
Clay Calvert
dot com> wrote:
>A bit more investigation shows that you are correct and I was mistaken -
>or at least partially. The 32-bit version of Vista will indeed
>have16-bit support, but the 64-bit versions of XP and Vista will not.
>My apologies for the misinformation and any confusion it may have
>caused.
No problem. The reasons, I'd guess, that the 64-bit version won't
have 16-bit support is that the CPU would have "step down" twice to
work at that level. Microsoft, and several other major IT players,
are also trying to eliminate the BIOS. Many, if not most, 16-bit apps
speak often to the BIOS. Now it is true that BIOS access could be
emulated, but that would just slow things down.
Thanks
Scott Coffey
wrote:
>Clay Calvert <ccal...@Wanguru.com> wrote:
>> "Dave R." <dwragle at drbsystems dot com> wrote:
>> >"Rodney" <NoMoreSpamP...@ars-florida.com> wrote
>> >> Any word on how DOS apps run under Vista?
>> >From what I have read, Vista will not have 16-bit support at all. From
>
>> directory. Edlin.exe was also present. I'd think that the 32-bit
>> version will have 16-bit support, becuause many people will still have
>> 16-bit apps to run on 'older' hardware.
>
>Although my question goes way beyond batches, even if related, what
>decisive advantages will Vista offer over XP?
The same question could be asked about XP vs 2000 Pro. The answer is
that Bill needs a new revenue stream. Microsoft could have easily
patched 2000 Pro to turn it into XP. And without the fancy new file
system that will be missing from Vista, Microsoft could have patched
XP to turn it into Vista. It's all about $. You can't charge $200
for a patch.