interrupt definition old DOS code, need to find it
Bob
Im a complete newb to programming console apps and just started using
Visual Studio recently. Im trying to port old DOS code to compile
under
VS 2003. When I compile, I cannot seem to find an include file or
whatever
I need to do to make the following work:
static void interrupt (*old_com_isr)();
This and many other references to 'interrupt' are giving me compile
errors.
Can someone point me in the right direction to resolve these,
or is the code too old and there is something new that replaces
this on newer systems/VS?
Thanks
Benjamin David Lunt
"Bob" <je...@rahul.net> wrote in message
news:ed784872-1abc-46ff...@z24g2000prf.googlegroups.com...
If I remember correctly, MSVC 1.52 was that last version of that
compiler that would still create DOS apps. The interrupt keyword
is a DOS only keyword.
You will need to find an older compiler that will still create
DOS apps.
Ben
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.frontiernet.net/~fys/index.htm
To reply by email, please remove the zzzzzz's
Batteries not included, some assembly required.
Jack Klein
in comp.os.msdos.programmer:
> Hi-
>
> Im a complete newb to programming console apps and just started using
> Visual Studio recently. Im trying to port old DOS code to compile
> under
> VS 2003. When I compile, I cannot seem to find an include file or
> whatever
Your problem is a misunderstanding of what you think you are trying to
do. All versions of Visual Studio and/or Visual C++ with a year for a
version, or a version number of 2.0 or higher, do not make MS-DOS
programs. They can make Win32 console applications, which look like
MS-DOS applications because they display text mode windows, but they
are not.
> I need to do to make the following work:
>
> static void interrupt (*old_com_isr)();
>
> This and many other references to 'interrupt' are giving me compile
> errors.
User mode Win32 applications can't do anything at all with interrupts.
In fact, the non-standard extended keyword "interrupt" is not
recognized, as you have found out.
> Can someone point me in the right direction to resolve these,
> or is the code too old and there is something new that replaces
> this on newer systems/VS?
As Benjamin already pointed out, you need a much older compiler to
generate true MS-DOS executables, Visual C++ 1.52c or earlier, or
older Borland compilers.
Then, depending on what hardware and interrupt related things you are
trying to do, and the version and configuration of your Windows
system, the operating system might or might not let your program
actually run and do them.
Versions of VS like the one you have provide full access to the entire
Windows API, which includes functions that can probably do anything
you need to do with a serial port.
You might start here:
http://search.msdn.microsoft.com/Default.aspx?locale=en-us&Refinement=4&Query=serial%20port&StartIndex=0&Brand=msdn
If you go down this path, ask further questions on Microsoft's MSDN
forum or a Windows group like news:comp.os.ms-windows.programmer.win32
because it has nothing to do with MS-DOS.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Rod Pemberton
As others pointed out, you're using a feature generally not directly
available on a non-DOS OSes. The 'interrupt' keyword allows you to create a
function compatible with an interrupt routine used by BIOS, or DOS.
Interrupt routines are typically protected from modification and hidden
behind installable device drivers on modern OSes. Interrupts were
essentially the API for DOS, so, you'd might need to replace (i.e., probably
completely rewrite...) with Windows API functions. Hardware generated
interrupts will have device drivers under Windows. You may also need to
rework the code so it calls the replaced interrupt function or device driver
API function, since it was probably called by the hardware (But, all this is
better asked in a Windows group...) The code implies com ports, right? You
may need additonal software such as 'userport.zip' suggested by Burry to
Terence recently:
http://www.embeddedtronics.com/public/Electronics/minidaq/userport/
Or, these:
http://geekhideout.com/iodll.shtml
http://www.beyondlogic.org/porttalk/porttalk.htm
WinIO http://www.internals.com/
Rod Pemberton
Ted Davis
As has already been said, you are trying to use the DOS Interrupt API in a
Windows program - it doesn't work that way.
There is a free compiler package that makes real mode DOS, Win16 and Win32,
and even OS/2 executables: OpenWatcom
<http://www.openwatcom.org/index.php/Main_Page>. It has an IDE and does
C, C++, and FORTRAN. It also has Royalty-free 32-bit DOS Extenders and
Cross-Platform Development Tools. Quite the package for the price.
--
T.E.D. (tda...@mst.edu) MST (Missouri University of Science and Technology)
used to be UMR (University of Missouri - Rolla).
Terence
confusion to the poster.
I can use a Fortran compiler for DOS, or an Assembler, again for DOS,
and my both these kinds of resulting executables will run on a DOS
operating system.
However only my Fortran programs will run in the Windows command line,
because in those source codes I only call those DOS services, which
can be accurately executed by the Windows DOS emuulation process.
So the original poster should abandon any idea of controlling
hardware other than external ports, keyboards, mouse and screen
controls by DOS services. Especially don't attempt anything else
because the hardware and the operating system is totally different
from an IBM AT.
Ted Davis
> There are two points of view here, both correct but generating more
> confusion to the poster.
>
> I can use a Fortran compiler for DOS, or an Assembler, again for DOS, and
> my both these kinds of resulting executables will run on a DOS operating
> system.
>
> However only my Fortran programs will run in the Windows command line,
> because in those source codes I only call those DOS services, which can be
> accurately executed by the Windows DOS emuulation process.
Each and every one of which is an interrupt accessed through the interrupt
table
>
> So the original poster should abandon any idea of controlling hardware
> other than external ports, keyboards, mouse and screen controls by DOS
> services. Especially don't attempt anything else because the hardware
> and the operating system is totally different from an IBM AT.
What makes you think the OP wants to control hardware? There is nothing in
the original message to indicate that. Interrupt were often used in user
code to get at the raw material that the HLL processed into a less than
usable form - if it provided a wrapper for the interrupt function in the
first place. The vast majority of documented DOS 5 and common
BIOS interrupt functions are present in the NT DOS emulator.
I consider playing games with interrupts in a DOS emulator to be best left
to experts, but sometimes people learn best by trying things until they
understand what is really going on.
For what it's worth, I still sometimes use this bit of assembly code to
catch a keypress:
XOR AX,AX
INT 16
MOV AH,4C
INT 21
Eight bytes - two interrupts: one BIOS and one DOS. Its behavior is
similar to but not exactly like getch() is C. Sometimes that
sort of difference might be important.
Terence
> For what it's worth, I still sometimes use this bit of assembly code to
> catch a keypress:
>
> XOR AX,AX
> INT 16
> MOV AH,4C
> INT 21
>
Yes, I use something similar too, as routine INPC.asm as follows, but
I also test for input.
Note that services 0,1,2, 16 and 17 are also available for keystrokes.
And also note that services 16 and 17 are only for extended keyboards
(more usual nowadays).
The call is using the standard Microsoft stack method with called
routine cleaning the stack.
name INPC
public INPC
sinpc segment
assume CS:sinpc
INPC proc far ;I=INPC(0/1/2/16/17)
PUSH BP ;0=WAIT, 1=CHECK, #10=WAIT EXTENDED CODE,#11=CHECK
EXT
MOV BP,SP ;2=GET SHIFT STATUS TO AL
LES BX ,dword ptr [bp+6]
MOV AH,ES:[BX]
AND AX,1300H
TEST AH,01H
JZ INPC2 ;IF NOT WAIT
INT 16H ;COPY BYTE AL, CODE AH
JNZ INPC1 ;CODE IF ZERO FLAG OFF
XOR AX,AX ;NOTHING
JMP SHORT INPC1
INPC2: INT 16H
INPC1 MOV SP,BP
POP BP
RET 4
INPC endp
sinpc ends
END
My original point was that somw of the DOS services, if called from
withing the Windows emultor of DOS will not always work as expected.
The original definitions of what registers are saved and which are not
are no longer to be trusted after W 95. And NT and XP shut off DOS
access to most of the hardware ports, for which there are work-
arounds.
Finally, the emulator will not execute all of the services available
from the MODE command (in EVERY service) as an internal call (i.e. as
a daughter service), but will execute theset as a direct call on the
command line, which apparently has higher rights.
Dirk Wolfgang Glomp
I prefer to get a key without using any softints. Here is my code:
;----------------------------
BEGIN:
cli
mov al, 2 ; stop IRQ 1
out 21h, al ; irq-controller
sti
;----------------------------
MAINLOOP:
in al, 64h ; status port
test al, 1 ; output buffer empty?
jz NOKEY
test al, 20h
jnz PS2MOUSE
in al, 60h ; get the key
dec al ; escape to exit?
jz HOME
; If we need an ASCII, it is neccessary to convert the keycode.
; Look at the tables below and maybe replace the ASCIIs.
PS2MOUSE:
NOKEY:
jmp MAINLOOP
;----------------------------
HOME:
cli
xor al, al ; start IRQ 1
out 21h, al
sti
mov ah, 1 ; clear buffer
int 16h
mov al, BYTE PTR[ERRORLEVEL]
mov ah, 4Ch
int 21h
;-----------------------------
; My tables for the data segment:
TASTTAB DB 02h,03h,04h,05h,06h,07h,08h,09h,0Ah,0Bh,0Ch,0Dh
DB 10h,11h,12h,13h,14h,15h,16h,17h,18h,19h,1Ah,1Bh,1Eh,1Fh
DB 20h,21h,22h,23h,24h,25h,26h,27h,28h,29h,2Bh,2Ch,2Dh,2Eh,2Fh
DB 30h,31h,32h,33h,34h,35h,39h
DB 56h
tablen = ($-TASTTAB)
TEXTTAB DB "1234567890ß'"
DB "qwertzuiopü+as"
DB "dfghjklöä^#yxcv"
DB "bnm,.- "
DB "<"
Textablen = ($-TEXTTAB)
;-----------------------------
Dirk
Dirk Wolfgang Glomp
> Im trying to port old DOS code to compile
An offen used archiv for DOS-programmer is
Ralf Browns x86/MSDOS Interrupt List(RBIL):
http://www.pobox.com/~ralf
http://www.pobox.com/~ralf/files.html
ftp://ftp.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/
Dirk