Re: bits 32 oddities in NASM

James Daughtry wrote:
Frank Kotler wrote:
Google glitches. :-P

Not written in asm - that's its damn problem! :)

Amen! :-)

When (if?) you sort through the replies to your original post, get back
to us with what you're trying to do. Looks like you've got one foot in
dos, and one in 32-bit... won't work unless you "take steps". - dos
extender or switch to pm yourself - and *then* dos interrupts won't work...

I was experimenting to see if I could use DOS interrupts with 32-bit
registers. I know I can do it with 16-bit registers, to some extent.
Most likely because there's some hidden emulation layer that caters to
stupid people who try to write DOS in Windows. ;-) Are interrupts real
interrputs on Windows XP? Or do they end up calling a Win32 function?

When a DOS program is run under Windows XP, ntvdm.exe takes care of
emulating all the DOS and BIOS calls. So yes, in a roundabout way, they
do end up calling code in Windows.

To be perfectly honest, I wanted to find a convenient way to do I/O
without resorting to the C library or the evil Win32 API. Interrupts
are simple and relatively easy to use. The C library is very simple and
easy to use, for me, but I can imagine it being somewhat bloated for an
assembly program. I *hate* the Win32 API with a well honed passion,
even for simple things, and I try to avoid it. :-)

Well, there's no way to do IO under Windows without at some point or
the other calling an API function. In fact calling it directly yourself
will be the fastest, least circutious route. The C library ends up
calling the Win32 API internally while a DOS INT instruction will trap
into NTVDM, which will inturn call several internal routines in Windows
to do it's emulation for your real mode program.

Of course writing to ports or otherwise interfacing directly with the
hardware is forbidden within user-mode programs. You could probably
write a Kernel Driver but it isn't worth that much trouble.

The shortest code path to do stuff in Windows is to call it's API,
(perhaps via INT 2Eh). So if you *hate* the Win32 API, you'll be
crippled, programming under Windows.

So why not change over to Linux/BSD? They've got a rich set of APIs
accessible via the software interrupt and you can even do some direct
hardware stuff if you run as root.

.

Relevant Pages

  • Re: Linux syscalls
    ... > A device driver or a rewrite of DOS could permit this, ... really "DOS inside Windows" or "Windows inside DOS"? ... > DOS interrupts are revectored... ... if you re-write DOS to use the _Windows device drivers_ ...
    (alt.lang.asm)
  • Re: bits 32 oddities in NASM
    ... registers. ... But, since dos interrupts are 16-bit code, Nasm needs to be generating 16-bit code to operate there. ... without resorting to the C library or the evil Win32 API. ...
    (alt.lang.asm)
  • Re: Win32 software interrupts?
    ... >>DOS 1mb scope? ... Interrupts were supported in Windows, ... ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal ...
    (comp.lang.asm.x86)
  • Re: Visual Assembler
    ... > Ralf Brown list of MSDOS interrupts. ... For Windows programming, you go with the WIN32 API. ... Internally, on NT, the win32 api runs ontop of the NT native API, ...
    (comp.lang.asm.x86)
  • Re: Building GUI with C
    ... using Win32 API for windows you can do it. ... I mean it doesn't pop out of DOS but all ... > programs are just command-line programs. ...
    (microsoft.public.dotnet.languages.csharp)