Re: DOS applications ?

From: Jim Carlock (anonymous_at_127.0.0.1)
Date: 05/23/04 

Date: Sun, 23 May 2004 01:09:21 -0400

A DOS batch file runs dos programs sequentially and can run
programs asynchronously as well. You can start up a second
command prompt window and keep the second command
prompt active... I've not done it since Windows 98 but there
is a /c switch that can be used with command prompts to keep
the window open... I don't know how to tie the two open
command prompts together, but I'm sure there's a way to use
Windows APIs to do it.

You mentioned command.exe. It was really command.com.

The boot process was io.sys, msdos.sys, command.com, then
Windows.

When Command.com started, that in turn called and ran the
programs within config.sys, autoexec.bat. Sometimes a mouse
driver would be contained within the autoexec.bat and once
the mouse driver was loaded, it stayed running, thus, you had
a program loaded and called from a command prompt and
physically running while the command prompt continued
processing the calling of autoexec.bat.

The only thing I'm not sure about, is whether it was msdos.sys
that loaded config.sys and autoexec.bat or if it was the initial
loading of command.com.

The START command (which I think is a command.com or
cmd.exe internal command) is used to start up separate command
prompts. This can be demonstrated by the following batch file:

START "Window 1" cmd.exe
START "Window 2" cmd.exe

In the earlier versions of Windows there was a way to start up
separate command prompts as well, but I just don't recall if it
was done in the same fashion. 

-- 
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:lsska0hlb6160a9n0cdv8c63v62ioeqh3b@4ax.com...
I should point out that this is true only for MS-DOS apps running in other
than pure
MS-DOS, for example, under 16-bit Windows running over MS-DOS, or a 16-bit
DOS app running
on Win32. A 16-bit DOS app running on pure MS-DOS cannot launch another app
easily
(although it can launch another app; sequentially; I've done that too, but
not since about
1990, so I've forgotten how I did it)
joe
On Tue, 18 May 2004 14:49:11 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
>Actually, a slight correction. A 16-bit DOS app CAN launch and communicate
with other
>windows processes. I did it in Win16, and I've done it in Win32. A Windows
command window
>is NOT a 16-bit environment, it is a full 32-bit environment. When a 16-bit
app is
>launched, it is run under an NT Virtual DOS Machine, but it is important to
not confuse
>the cmd.exe program with command.exe, which was the 16-bit command
interpreter. cmd.exe is
>a native 32-bit app that supports 32-bit environments.  In fact, you can
double-click a
>16-bit console app in the Explorer and it will launch it.
>
>The 16-bit apps inherit all of the limitations of Win16; for example, if
you have a suite
>of 16-bit apps running in a single NTVDM, and one of them goes into an
infinite loop, you
>have to kill the entire NTVDM because all the other processes will be
blocked.
>
>A 16-bit app cannot do 32-bit API calls unless it goes through a "thunking
layer", which
>is very painful to deal with. But 16-bit apps can do
SendMessage/PostMessage to 32-bit
>apps (although they can only send the low order 16 bits of WPARAM because
that's all that
>were supported in Win16) and can receive messages sent by 32-bit apps
(although the
>high-order 16 bits of WPARAM will be discarded). I know, because I have one
app that is
>basically a 16-bit app which runs with a 32-bit app to provide networking
and serial port
>communication, and other 32-bit API calls. So when I need a 32-bit API
call, intead of
>going through a thunking layer, I just add a new message to the 32-bit
"server" app (which
>the 16-bit app launches using WinExec) and do the 32-bit work in the 32-bit
app.
>
>Any app (16 bit or 32 bit) can launch any app (16 bit or 32 bit) without
limitation. For
>example, my "server" app, if it detects the 16-bit app has terminated, will
re-launch it,
>using CreateProcess.
>
>The reason they maintain this 16-bit app is that it uses a critical 16-bit
library that is
>pervasive in the program. There is no equivalent 32-bit library, and the
company that
>produced the 16-bit library has gone out of the business of supporitng that
library (years
>ago). I gave this client an estimate of the cost of rewriting the main app
(132,000 lines
>of code) to WIn32, and they can't afford it. The server app cost a small
fraction of the
>cost of rewriting the 16-bit app.
>
>16-bit console apps can only call the same API calls that were supported in
16-bit
>Windows. This means, for example, no threading, no mutexes, no critical
sections,
>primitive I/O capabilities (no asynchronous I/O, and serial port I/O is
nearly unusable,
>as is network I/O). Many GUI components work fine, however, and you can't
tell the
>difference between 16-bit and 32-bit apps if you are running on the
obsolete Win9x family,
>because after all those versions of Windows have only 16-bit Windows
capabilities anyway.
>But the same limitations on address space, available DCs, GDI and USER
space, etc. all
>continue to exist,
>
>On Tue, 18 May 2004 12:36:19 -0400, Tim Slattery <Slattery_T@bls.gov>
wrote:
>
>>ajaykalra@yahoo.com wrote:
>>
>>>How about creating a Win32 Console app in the current compiler? Is it
>>>not the same thing?
>>
>>No! A  console app is definitely NOT the same as a DOS app. A DOS app
>>is 16-bit code, it must run in a 16-bit environment, and there are
>>many things it cannot do, like launch or communicate with other
>>Windows processes. A Windows console (DOS box) will provide a 16-bit
>>environment to run DOS code. Since it's a 16-bit program there are
>>strict limitations on the amount of memory it can use.
>>
>>A console app is 32-bit code that can do anything that a Windows GUI
>>application can do. It has access to the same huge amounts of virtual
>>memory that GUI apps can use, it can launch and communicate with other
>>windows programs, and use any part of the Win32 API (except the
>>graphical calls, I'd guess.)
>
>Joseph M. Newcomer [MVP]
>email: newcomer@flounder.com
>Web: http://www.flounder.com
>MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Relevant Pages

  • Re: how to call print screen and how to read windows clip board
    ... between our DOS versions of our software's screen contents and their ... own WORD or other Windows softwares's screen contents. ... just want to export the ASCII text from your DOS app to ... If your clients normally run your app full-screen, ...
    (comp.lang.asm.x86)
  • Re: Great SWT Program
    ... can have its own cursor/selection independently of the underlying ... it and the underlying app will contend for the one and only text-mode ... A DOS box is a full blown VM ... You normally can iconify in this circumstance in Windows too, ...
    (comp.lang.java.programmer)
  • Re: Confusing stack effects
    ... And DOS ... is the best way to start assembly programming. ... To learn todo 16-bit dos programming, for programming in windows later is the worst kind of advice. ... Learning to program for a Click&Go GUI is a tedious incredible complex job, compared to doing a dos app, where all you need to do is set up a loop, to take input that in all cases _you_ made the rules for. ...
    (alt.lang.asm)
  • Re: Deployment and debugging of apps from VS2005 via ActiveSync &
    ... "From the command prompt on the device…" ... Windows Mobile Developer Power Toys v3.0 ... (My app is an embedded one based on PPC 2003 BTW, ... I have tried very very hard to get the suggested instructions on: ...
    (microsoft.public.pocketpc.activesync)
  • Shell() or Windows API question
    ... Windows 98 DOS prompt) - ... Running the above from DOS / command prompt works perfectly. ... both of the batch files described above do work perfectly when run manually ...
    (microsoft.public.access.modulesdaovba)