Windows Assembly Language Programming

[FORTRANS]

Somewhere I heard about a DOS extender?

Is this so that I can use 32 bit instructions in a DOS program?

Hi,

   No.  They are for accessing the large amount of memory
that 32-bit modes allow.  You can use 32-bit instructions in
plain DOS.  Use the .386, .486, .586, or .686 directive.  Be
careful, if used wrongly you will be executing instructions that
expect 32-modes in a 16-bit mode, or the opposite.

(If it is it would make it a whole lot simpler to convert DOS programs to winows 32 bit because I could test the changes I've made part way through the process of converting a 16 bit DOS program to a 32 bit Windows program. The changes I've made so far compile OK but it crashes when I try to run it.)

If there is a 32 bit DOS extender, how do I get it?

   Open Watcom C and Fortran comes with a DOS extender.

HTH,

Steve N.

[hutch--]

Joe,

you can go that way and there are some very good ones around but you then limit your database design to a tiny percentage of computers around the world. What I would suggest is to use your original concept and simply re-write it in 32 bit code so that it is the same to use at the interface level but leverages the Windows API functions and the full 32 bit instruction set.

the Windows API functions look a bit daunting but you can break them down to different families of functions, disk IO, memory allocation strategies, console IO and in the future a GUI interface if and when you need it.

[clive]

There are the DOS4GW, CAUSEWAY and DOS32A DOS Extenders, which work with the Watcom compilers and assembler. There are others more suited to DOS and OS/2 era code, but these aren't free and are more liable not to work well with XP, Vista, Win7, etc. because everyone has moved on, and 1990's era code is not a big priority for everyone today.

Personally I think you be better just skipping that step if you can. You'd have to re-learn the INT 21H interface, ie which registers have expanded to 32-bit, how the segments/selectors work, etc. This is especially true if you are unfamiliar with DPMI. All of which will be completely useless knowledge to gain in 2011.

If you have any familiarity with C, then building a framework in that and working on small 32-bit assembler code fragments might be easier. Or build a small test harness/framework in assembler, and slowly port over basic functions/subroutines from your existing code, assuming you have some layers of abstraction of course.

The big thing you need to get your head around with the Win32 / 386 assembler is that the address space is flat, and you don't want to be using DS/ES/SS/GS/FS etc.

Unless you are writing an OS, the LDT, GDT, TSS and all the other more advance concepts are irrelevant for day-to-day 32-bit coding.

For Win32 API books the following would be worth a look, the latter is broken into functional sections like Hutch describes above.

http://www.amazon.com/Windows-Win32-SuperBible-Other-Sams/dp/1571690891

http://www.amazon.com/Windows-Programming-Complete-programmers-reference/dp/1571690093/ref=pd_sim_b_1

[MichaelW]

Joe,

One problem with 32-bit DOS code, particularly when you are programming in assembler, is that to access the underlying OS you must have a reasonable understanding of the low-level details of both 16-bit real mode code and 32-bit protected mode code. While converting 16-bit DOS code to 32-bit DOS code may be somewhat easier than converting 16-bit DOS code to 32-bit Windows code, with Windows code you are generally insulated from the low-level details of 32-bit protected mode code, and you are targeting the predominate platform.

If I needed a DOS Extender, I would use Japheth's HX DOS Extender

[GregL]

Joe,

I agree with the others, forget the DOS Extender.  Go with a port to 32-bit Windows.  Here are some links that may help.

Porting MS-DOS System Calls to the Windows API
Windows API Reference

Good luck with your project.

[hutch--]

Joe,

Do yourself a favour, instead of "porting" your DOS design to Windows, rewrite it using the design so that you can take advantage of linnear addressing, far faster disk IO and a far more powerful Intel instruction set. You can take advantage of multi-threading and inter-application communication technologies and plonk any of it into a graphics interface where it can be used. Write your own load on call DLLs so that yo can extend the required code base without bloat. Its like shifting from a postage stamp to a football field and you will get a far more powerful result by bothering.

Most of the older guys here came from the DOS and earlier era and we have all had to do the transition from that architecture to a modern protected mode OS architecture but the gains are many and the results when written correctly are massive.

[Joe Btfsplk]

Joe,

Do yourself a favour, instead of "porting" your DOS design to Windows, rewrite it using the design so that you can take advantage of linnear addressing, far faster disk IO and a far more powerful Intel instruction set. You can take advantage of multi-threading and inter-application communication technologies and plonk any of it into a graphics interface where it can be used. Write your own load on call DLLs so that yo can extend the required code base without bloat. Its like shifting from a postage stamp to a football field and you will get a far more powerful result by bothering.

Most of the older guys here came from the DOS and earlier era and we have all had to do the transition from that architecture to a modern protected mode OS architecture but the gains are many and the results when written correctly are massive.

Thanks hutch! Now that I'm getting into it! Windows 32 bit doesn't look as daunting as it did before.

When I wrote ADAM around 1986,  I used a little trick to make the parameter passed to ADAM look like a DSECT. (That's mainframe lingo.) ADAM loads the address of the user's parameter into DS which must conform to the Data segment that ADAM has but never uses so it's like a mainframe DSECT. After opening the ADAM file, ADAM gets as much memory as it needs, transfers the data in the user's parameter to the memory it acquired and loads that address into the DS reg. ADAM is then able to address everything as if it were in its data segment.

The same sort of thing should be possible to use in Windows 32 bit. Since ADAM is a far:call for the caller, It should be able to run in the same mode that the caller is in. I shouldn't need to worry about whether ADAM is running in real mode or protected mode. If anyone knows DOS Assembly Language and would like to fool around with ADAM, I'll send you the three .obj modules and some programs that you can use as samples of how to use them. In the meantime, I'm busy on the Windows 32 bit conversion. There should be Windows functions to replace any of the INT instructions that I used in ADAM. I can't see starting over. It works great under DOS and most of it should run under Windows without major modification. Now I just have to find the Windows functions that I need.

Joe Btfsplk
wrmattison@suddenlink.net

[clive]

Realistically you probably only need a dozen or so Win32 API calls to replace the INT21h stuff. Mostly the memory allocation and file stuff I would imagine.

CreateFile, SetFilePointer, ReadData, WriteData, GetFileSize, CloseHandle, and some assorted tricks to get the current file position, or truncate it.

I'll take a look at the DOS OBJs.

[MichaelW]

The same sort of thing should be possible to use in Windows 32 bit. Since ADAM is a far:call for the caller, It should be able to run in the same mode that the caller is in. I shouldn't need to worry about whether ADAM is running in real mode or protected mode.

Beyond the problem with software interrupts, if ADAM was assembled/compiled as 16-bit real mode code it will not run in protected mode without modification.

I can't see starting over.

I can see why you would not want to start over on the algorithm, file format, etc design, but why not start over on the code design? You already need to change the OS interface and change from 16-bit near or far addressing to 32-bit near addressing. Why not redesign the code to take full advantage of the 32-bit address space, 32-bit instructions, and the much larger memory capacities of today?

[dedndave]

noone is more resistant to change than i am, Joe - lol
i wrote 16-bit asm code for years
a couple years ago, i decided to bite the bullet and dig into win32
there is a lot of material to cover for GUI apps - but it's not that bad
it isn't bad at all if you want to write 32-bit console apps