◇ The Future of DOS Programming - China DOS Union Forum

--------------------------------------------------------------------------------Sender: [email protected] (嵐雲), Board: programming
Subject: The Future of DOS Programming
Posted at: NCTU CS Heavenly Dragon News Agency (Thu Jan 26 02:10:28 1995)
Forwarded via: cis_nctu!news.cis.nctu!news.cc.nctu!news.csie.nctu!nctubbsgate!csie.nc

In the future, Windows NT & Windows 95 will be the leading players among M$ OSes. Even if
M$ continues to release DOS 7.0, it would probably only be reduced to a supporting role. So does that mean
the DOS programming I'm learning now is no longer useful? Do I have to go learn Windows GUI programming instead,
using the message-driven concept, and write programs with SDK or frame classes like MFC, OWL? The answer is not
like that. Current DOS programs can still be recompiled under NT&95 and become Win32
console programs, that is, text-mode programs.

However, of course there are some programming techniques that will be of no use later, or cannot be used.
Here, I want to provide some information related to this sort of thing, and share it with everyone for discussion.

First, let me introduce the Win32 API. API is short for Application Programming
Interface, similar to a system call. You should know that
in an OS, an AP (application program) is not allowed to directly touch hardware; everything has to be handled
through the OS. The API consists of functions provided by the system
for programmers to use. And M$ has defined the Win32 API as the standard for future M$ OSes.

The Win32 API is not only for Windows GUI programs, it also applies to 32-bit
console (DOS mode) programs. For example, right now under the console (dos), you can use
LocalAlloc to allocate memory, or use CreateProcess to create a new process,
just like the fork function in Unix; under dos, you can still use
dll, ole2, dde, clipboard....., and the boundary between dos and windows is no longer so clear.
In other words, console (dos) is the text mode of winNT&95, while traditional win3.1 programs belong
to the graphical user interface (GUI) mode of winnt&95; both are Win32 programs.

Under Windows NT, the system provides you with the full Win32 API. Under Windows 95,
only a subset of Win32 is provided; the name seems not yet settled, possibly Win32r (mentioned in documents
M$ released last year) or Win32c (mentioned in beta-version documents). The APIs not provided are the functions
Win95 doesn't have, such as APIs related to C2 security, NTFS, and so on. Under Windows 3.1,
some dlls are used to provide another subset, the Win32s API. Most of Win32s is just the old APIs in
32-bit versions, without any multitasking or security stuff.

Therefore, writing Win32 programs will let them work under future Dos&WinNT&Win95, and through NT's
cross-platform support, your programs can also run on PowerPC, Alpha, and Mips.

In WinNT&95, the old 64k limitation in dos will no longer exist. All pointers are
32-bit, no more near and far, and all new, malloc calls have no 64K limitation. Because of this, there will also no longer
be any tiny, small, large... modes. What is used is flat addressing mode. Every
program has 4GB of address space, segments will no longer appear, and the terms Expanded & Extended Memory
will pass into history.

Don't go through any interrupts (whether bios or dos) or directly touch hardware; instead
use the Win32 API. Interrupts belong to real mode and are 16-bit programs, and more importantly they were not
designed with a multitasking execution environment in mind. If you need to write programs that communicate with
hardware peripheral devices, then you'll need the DDK;
you can't do that inside an ordinary AP. In win95's dos, programs that directly access hardware probably won't have
problems; this is to maintain compatibility with old APs (and because of this it also damages system stability), but it is not
the ideal way.

The term TSR resident program will probably also become history! In a preemptive multitasking system,
as long as a program does not terminate, it is a resident program. For those who like using TSRs to hook
interrupts, there is the corresponding use of dlls to hook API calls.

Hmm! That's all I can think of for now. If I think of more, I'll add it later. If there are mistakes, corrections are welcome.

Floor1　Dark-Destroy	Posted 2003-06-20 00:00
元老会员　Posts 3,551　Credits 8,312
--------------------------------------------------------------------------------Sender: [email protected] (嵐雲), Board: programming Subject: The Future of DOS Programming Posted at: NCTU CS Heavenly Dragon News Agency (Thu Jan 26 02:10:28 1995) Forwarded via: cis_nctu!news.cis.nctu!news.cc.nctu!news.csie.nctu!nctubbsgate!csie.nc In the future, Windows NT & Windows 95 will be the leading players among M$ OSes. Even if M$ continues to release DOS 7.0, it would probably only be reduced to a supporting role. So does that mean the DOS programming I'm learning now is no longer useful? Do I have to go learn Windows GUI programming instead, using the message-driven concept, and write programs with SDK or frame classes like MFC, OWL? The answer is not like that. Current DOS programs can still be recompiled under NT&95 and become Win32 console programs, that is, text-mode programs. However, of course there are some programming techniques that will be of no use later, or cannot be used. Here, I want to provide some information related to this sort of thing, and share it with everyone for discussion. First, let me introduce the Win32 API. API is short for Application Programming Interface, similar to a system call. You should know that in an OS, an AP (application program) is not allowed to directly touch hardware; everything has to be handled through the OS. The API consists of functions provided by the system for programmers to use. And M$ has defined the Win32 API as the standard for future M$ OSes. The Win32 API is not only for Windows GUI programs, it also applies to 32-bit console (DOS mode) programs. For example, right now under the console (dos), you can use LocalAlloc to allocate memory, or use CreateProcess to create a new process, just like the fork function in Unix; under dos, you can still use dll, ole2, dde, clipboard....., and the boundary between dos and windows is no longer so clear. In other words, console (dos) is the text mode of winNT&95, while traditional win3.1 programs belong to the graphical user interface (GUI) mode of winnt&95; both are Win32 programs. Under Windows NT, the system provides you with the full Win32 API. Under Windows 95, only a subset of Win32 is provided; the name seems not yet settled, possibly Win32r (mentioned in documents M$ released last year) or Win32c (mentioned in beta-version documents). The APIs not provided are the functions Win95 doesn't have, such as APIs related to C2 security, NTFS, and so on. Under Windows 3.1, some dlls are used to provide another subset, the Win32s API. Most of Win32s is just the old APIs in 32-bit versions, without any multitasking or security stuff. Therefore, writing Win32 programs will let them work under future Dos&WinNT&Win95, and through NT's cross-platform support, your programs can also run on PowerPC, Alpha, and Mips. In WinNT&95, the old 64k limitation in dos will no longer exist. All pointers are 32-bit, no more near and far, and all new, malloc calls have no 64K limitation. Because of this, there will also no longer be any tiny, small, large... modes. What is used is flat addressing mode. Every program has 4GB of address space, segments will no longer appear, and the terms Expanded & Extended Memory will pass into history. Don't go through any interrupts (whether bios or dos) or directly touch hardware; instead use the Win32 API. Interrupts belong to real mode and are 16-bit programs, and more importantly they were not designed with a multitasking execution environment in mind. If you need to write programs that communicate with hardware peripheral devices, then you'll need the DDK; you can't do that inside an ordinary AP. In win95's dos, programs that directly access hardware probably won't have problems; this is to maintain compatibility with old APs (and because of this it also damages system stability), but it is not the ideal way. The term TSR resident program will probably also become history! In a preemptive multitasking system, as long as a program does not terminate, it is a resident program. For those who like using TSRs to hook interrupts, there is the corresponding use of dlls to hook API calls. Hmm! That's all I can think of for now. If I think of more, I'll add it later. If there are mistakes, corrections are welcome.