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: [PATCH 1/3] drivers: misc: add omap_hwspinlock driver
    ... it is somewhat error prone; ... interrupts where it really shouldn't. ... Don't you feel that proving a simple spin_lock_irqsave-like API is ... move the internal locking implementation to raw_ methods ...
    (Linux-Kernel)
  • 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: strange functions binutils-2.21
    ... I already know what some of this API does but these functions like ... I don't think the sockets API has any ... Now in later code you can kake a pointer to this function: ... // Could make decisions to assign different values to handler here. ...
    (comp.lang.c)