Where to start? Newbie but Not Newbie

[dubhe]

I am an experienced assembly programmer that started with 6502 assembly in the 80's and added PC assembly in the 90's. I have a legacy program from the 90's that is still in limited use, written as 16 bit code using the original MASM. I have been maintaining it on a 32 bit XP laptop. When I upgraded to a 64 bit Win10 laptop, I find that none of my development software runs. (Not surprising) I realize that I have to bring my development world up to date, but I'm not sure what are the best tools.
The source code exceeds 25000 lines and runs under DOS.  I would like to avoid a total rewrite, but I would be willing to make accommodations to the code if required.
I have some (minimal) knowledge of C and would consider embedding the assembly in a C shell. I have zero experience programming with the Windows API or Linux.
First priority (important) is to be able edit, assemble and link the existing .ASM file to get a 16 bit .EXE
(In the future, I might try to migrate the project to a current OS, but that would be more a labor of love than important.)
Crazy, huh?
Thanks to anybody that wants to tackle this question...

[Siekmanski]

Hi dubhe,

Welcome to the forum.  :t

Look at the right top of this page and click on "MASM32 Downloads", download The MASM32 SDK and you're ready to go.
There are many examples to get you started if you want to make the step to 32bit.

[hutch--]

I think you are in trouble with the task in mind, the architecture of a modern executable file is vastly different to a real mode DOS program and the conversion would be more difficult that doing a complete re-write. As you would well understand the original design from maintaining it, I would recommend that you make a logic map of what the old app does then either learn how to write it in 32/64 bit OR find someone who is able to do this for you. If the task is as big as it sounds, I imagine it would be an expensive task to get up and running.

[dubhe]

Thanks Siekmanski! That's where I'll start...

[jj2007]

the conversion would be more difficult that doing a complete re-write. As you would well understand the original design from maintaining it, I would recommend that you make a logic map of what the old app does

I can only echo what Hutch writes; with a 25,000 lines application, don't even think of trying the conversion.

You write that you have zero WinAPI experience. That could be tough, too - the learning curve is long and steep. And C won't help much, as you need to use the WinAPI calls, too. Take a look at the MasmBasic commands, it is assembler but wraps most of the difficult WinAPI stuff into simpler commands like e.g. Open "O", #1, "MyNewFile.txt".

The Masm32 SDK has also plenty of good wrappers. What kind of processing does your application? Number crunching, parsing text, ...?

You may wish to read Masm32: What you absolutely need to get started; two pages only, but they help to avoid some common errors.

[dubhe]

Thanks, Hutch!
Yeah, I understand the structure problem between an old DOS executable and what's happening now. I doubt that it is worth the effort to rewrite the whole thing from scratch. I'm pretty good at coding, but learning the Win API looks like a career in itself.... I had a fantasy that maybe I could rewrite the user interface in a variant of C and include the rest as inline ASM. But the program architecture is still the problem. "In my day" (LOL) you could "own the machine". Now you have to share. The original program has some strict timing requirements. I don't know how the induced latency of the "round robin" application sharing performed by modern OS's would affect it. Yeah, I think it would require a total rewrite...
For the time being I will be content with simply maintaining it as a DOS application. Sooner or later it will be totally obsolete and I won't have to worry about it...

[dubhe]

Thanks for the hints, jj2007! I'll take a look at them.

[hutch--]

It is the familiarity with the Windows API that would be the problem. You could go the route of re-writing the idea as a console mode app (modern version of the DOS prompt) but in the long term it would be a far better and simpler proposition to write it with a normal UI interface. Timing should not really be an issue as you can use a multi-media timer that has reasonably high precision but of course you would need to know how to write it.

[mineiro]

hello sir dubhe, welcome.;
As you said, on ms-dos we own our machine. So you can have used ms-dos interruptions, bios interruptions, our own interruptions and you can also touch memory addresses like video, or input/output instructions on ports.
We don't have all that freedom today. What I can suggest is try to find all external functions used on your program and create a relation by functions that windows offers. A hard job.

When I change from ms-dos to windows I followed "iczelion tutorial".

[raymond]

Welcome to the forum dubhe

I do feel for you. I also started assembly in the late 80's for the Z-80 processor, then switched to MASM for the PC-XT, and then to 32-bit more modern MASM a few years later. At first, the latter seemed to be written in hyeroglyphs, but I finally learned how to use it.

I also had old programs from the Z-80 era which I managed to eventually convert to modern 32-bit assembly but they were small. However, there is one I wrote for 16-bit MS-DOS which had 120 pages (50 lines/page) of instructions. Over the years, I've looked at converting it but always gave up; I can still use it with a DOSBox even under 64-bit Windows10.

If your main concern is primarily timing requirements, that should not be a deterrent. Modern computers are almost 1000 faster than the PC-XT was (4 MHz). If your program was working fine on a 16 MHz machine, it would only require about 1% of the CPU time on modern computers and sharing would not be a problem unless your box is significantly overloaded.

[aw27]

then switched to MASM for the PC-XT,

The most popular assemblers at the time were the A86 and TASM.
I also remember well the Z80 and the 48K Spectrum from Sir Clive Sinclair.

[FORTRANS]

Hi,

   You could look at DOSBOX, VirtualPC, or something similar to run
your DOS program on Win 10.  Not a good long term solution, but a
nice short term solution.

HTH,

Steve N.