Re: Porting a DOS app to Windows

From: Stephen Sprunk (stephen_at_sprunk.org)
Date: 06/08/04 

Date: Tue, 8 Jun 2004 15:45:27 +0000 (UTC)

"Prabhu" <prabhu.sundarraj@patni.com> wrote in message
news:66fc325.0406072107.6c6cfd64@posting.google.com...
> The application is in C and is using assembly code (Not too much) for
> accomplishing the above mentioned features.
> The multi-tasking simulation in DOS is written in assembly which we
> are not sure whether we should port or not?
> The multi-taskign scheme is implemented using two stacks for
> background and foreground tasks. Atmost there could only be two tasks
> running parallely. Its been implemented in assembly via the interrupts
> routines, such as they allocate the key board to the process
> (background or foreground), delaying using a timer interrupt handler
> is done. They switch between the both the tasks saving and restoring
> the register value.

This won't work. Under Win32, you create a second thread of execution by
calling the API function CreateThread() with the thread's entry point, and
after that everything is handled by the OS.

Let the OS do all the heavy lifting for you; that's why it's there!

> Please verify whether will this code work under Win XP (both in DOS
> box or as Win 32 console app)?
> There are various ISRs in this code -
> 1. clock tick,
> 2. serial
> 3. keyboard
> 4. ctrl break etc.

ISRs do not exist in Win32. All interrupts are handled by device drivers in
the kernel, and messages will be sent to your application if appropriate
(and requested).

> PS. If it doesn't work then we would re-design it. We are thinking of
> creating console application which would have multi-threading for this
> background/foreground scheme apart from the normal serial and keyboard
> routines in Win API.

You cannot bypass the API to write to (or read from) the hardware; the OS
will trap the access and terminate your program. If you want to port your
app, you have to rewrite the "illegal" parts to conform to the API.

S 

-- 
Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

Relevant Pages

  • Re: Poweroff / shell
    ... it was not the Explorer but Winlogon that handled that broadcast and called to ExitWindowAPI. ... if you are running your own application as the shell you can always "fix" the behavior by providing your own handler for the ... Basically if you catch the message by your window or thread proc, you should call a shutting the system ... Some more info and ways how to intercept the power management events you can find in this thread: ...
    (microsoft.public.windowsxp.embedded)
  • Re: Weird problem as using pthread to implement multithreading.
    ... I translated the generated assembly code ... the default pthreads API is not suitable ... But, I am developing on Linux, and the pthread library i use is NPTL ... the nptl design white paper: http://people.redhat.com/drepper/nptl-design..pdf ...
    (comp.programming.threads)
  • Re: Weird problem as using pthread to implement multithreading.
    ... I translated the generated assembly code ... the default pthreads API is not suitable ...
    (comp.programming.threads)
  • Re: Winforms, Shown Event and SetEnvironmentVariable
    ... Timing done using "QueryThreadCycleTime" API (Vista and up), with Processor clock at fixed rate. ... If you just put a Stopwatch in the Shown event handler, start it before the two calls, and check the Elapsed time after them, what results do you get? ... Not that it's relevant to this question IMHO, but what's the .NET API for the QueryThreadCycleTime call? ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: Running an Exe process then hidding?
    ... you will use the process of the System.Diagnostic namespace. ... process to the other new one notepad (you do that through API calls). ... handler that you hold) to reshow your other process. ...
    (microsoft.public.dotnet.languages.csharp)