Mark Evans a écrit :

> Yeah, they are sweet.  However I consider DOS ugly, something that should have died a long time ago, especially for embedded apps.
>

in fact there is nothing in DOS, you have to do everything, you controle everything.

>
> My hope is that Real-Time Linux will get to a point of stability such that it displaces all the old DOS stuff in the embedded world.  RT Linux will run on PC-104 too.

Linux is one option we are studying,

>
> For those interested in a Windows-compliant embedded tool check out Real Time Target (RTT) out of Germany which is a Win API emulation for real-time targets.  You end up writing code
> that pretty much reads, walks, and quacks like Windows or DOS code, but which actually runs on a real-time kernel.  It will even call DLLs.
>

interesting,


>
> Still it's great that Digital Mars supports 16-bit code and the DOS extended stuff.  Very few compilers still do.
>

and 32 bit DOSX too !


Roland

first i esitate to expose my problem here as it is not specificaly DM C++.

but i would like it to have a DM C++ based solution..

More informations:

a PC based little cnc machine:

- must run a real time softwear,
- must run a "'evoluted" OS because it is plugged on a LAN with other pc's,
a web cam is plugged on it, it is plugged on Internet  for remote mantenance
(Symantec pcAnywhere), etc..

well i don't feel like making all those drivers on MS-DOS..

The actual solution is:

A windows CAD/CAM program on the cnc and on the pc networked with it,
a DOSX program only on the cnc, for driving the cnc itself on real time mode
on pure dos.

The problems are:

- i wrote my worries about the future of DOS but especially the fact that pc
motherboard are less and less pc compatible, (yes pc-104 is a solution)
- i'm afraid pure dos mode will not exist any more on windows,
- switching from windows to pure dos and back is long,
- two programs to mantain.

The ideal solution would be to integrate the DOSX real time program inside the Windows CAD/CAM program.

I think Linux can be a solution.
I think Windows can do it two.

We have a Windows programmer but he is not a system programmer,
i'm rather system programing oriented, but not a Windows programmer.

that is the reason i asked for help for system programming on Windows

Thanks

Roland


Roland a écrit :

> One of our program is a DOSX program.
>
> We make real time with it on pure Dos: drives a cnc machine tool.
>
> It works fine, and i think nothing is faster than DOSX associated with DM C++.
>
> but i have some worries for the future:
>
> 1- will we be able to run in pure DOS mode in the future ? (i think Win
> 2000 and Win Me as well don't support pure
> dos mode),
>
> 2- PC's hardware are less and less PC Compatible.. as hardware is more and more virtualized,
>
> 3- for network, scanner and web cam, we have to restart windows, witch is pretty long..
>
> We are studying different solution for the future.
>
> One is to put more hardware in the machine (buffer) and port our program
> on Windows.
>
> The question is:
>
> What is the maximum response time of windows on hardware request ?
>
> There is already some real time program on windows:
>
> software audio and image decompression, web cam, CD-R engraving, etc...
>
> I would like to have some general informations about those kind of software, do i have to make a device driver, is there someting special to know, advices, etc..
>
> Thanks very much
>
> Roland

Roland,

You might want to look into writing a Windows NT device driver for this.
I have no idea what the required response times are your program needs.
If you want to get something working I would suggest, try a "service" on Windows
NT/2000 first. If that is reliable enough you're done easy. If not, you might
want to put the code into a device driver and see if that will work.
The problem with Windows NT/2000 is that everything seems to run in kernel mode
as the Unix people call it. Unix has split off the operating system which runs
in level-0 while userland is in level-1. This way the operating system can
always repond as it controls the system. I think that most (if not everyone) of
the people on this newgroup know that:

while ( 1 )
    ;

Has a rather great effect on Windows NT/2000. Start a number of threads with these kind of things and you probably won't be able anymore to decently shutdown the system.

Anyways, for information on how to write a Windows NT/2000 device driver check http://www.osr.com/., Patrick van Hoorn Alkema (PvHA@compuserve.com), who also used to use Symantec C++ and may be still does, forwarded me to this site and the book they sell has been of great help to me.

If it were not that I am swamped with work already I would offer you to help to convert the current program to a Windows NT/2000 service, but I can not decently offer that right now.

Don't worry, be Kneppie!
Jan



NancyEtRoland wrote:

> I think Windows can do it two.
>
> We have a Windows programmer but he is not a system programmer,
> i'm rather system programing oriented, but not a Windows programmer.
>
> that is the reason i asked for help for system programming on Windows

>>... Patrick van Hoorn Alkema (PvHA@compuserve.com), who also
used to use Symantec C++ and may be still does...<<

Certainly do!

I'd be glad to help with advice if 'NancyEtRoland' would contact me - I've written a lot of services, but no NT device drivers, though I have been on a course from OSR on the subject, and have written VMS device drivers (very similar).

Like you, I've been a bit busy, and don't check out the DigitalMars stuff as often as I should.

>>The problem with Windows NT/2000 is that everything seems to run in kernel
mode
as the Unix people call it. Unix has split off the operating system which
runs
in level-0 while userland is in level-1. This way the operating system can
always repond as it controls the system. I think that most (if not everyone)
of
the people on this newgroup know that:

while ( 1 )
    ;

Has a rather great effect on Windows NT/2000.<<

IMHO NOT TRUE: only WIN32 API's (and not all of them) and device drivers run in kernel mode. User code runs in user mode just as in UNIX and other O/S's. The difference is that NT/2000 CPU- and Memory-scheduler is by-default biased toward code run by the logged-in user (to deliver snappy response), so a user program that hogs CPU cycles will have a serious effect - it should do the equivalent of 'nice' first, and that will adjust it's quotas to allow other stuff to run properly.

The NT CPU scheduler is very powerful and flexible, it's just that no-one uses it properly - everyone runs with default priority regardless of what they are doing! You can run a program with altered priority quite easily, either run it from a command window with 'START /<priority>  FRED.EXE' (see 'HELP START | MORE' in command window) or adjust the priority while running using the Task Manager (processes tab, right-click on the process in question and select priority). In this case, it sounds like 'realtime' priority would be useful - a process with this priority will pre-empt any other process in the system as soon as it becomes runnable, so should not do any lengthy computing. For the record, if you do port a program to NT, you can make it multi-threaded and assign a separate piority to each thread (you have to do this in code), so make one thread deal with real-time stuff at realtime priority, and another thread run at default or lower priority to do the housekeeping, display updating whatever.

For the record, the characteristics of an NT service can be summarised as follows:

a) Written and built as a 'standard' console-mode NT program, but console input and output routed to NUL during execution.

b) 'main' entrypoint calls a special WIN32 API 'StartServiceCtrlDispatcher' with a pointer to address of a routine that does the processing for your program. This routine is run in a separate thread - the main thread stays in communication with the service control manager, essentially asleep.

c) Needs to be installed prior to use.

d) Only one instance of each service can run - multiple instances (if
needed) must be installed with unique names.

e) (usually) runs in a 'local-system' account with admin privileges but NO
NETWORK ACCESS - at least no ability to access network-mounted discs, and no
desktop access (no visible windows). You can run socket (TCP/IP, UDP/IP etc)
code though. EXE file *must* be on local disc.

f) Survives user logout - keeps running when no-one is logged in. Basically independent of the logged-in user.

g) Can be set to start automatically on bootup.

h) Is no more part of the system than any other program, so it is not preferentially treated by the memory- or CPU-scheduler. Runs in user mode like any other program.

i) Very tricky to debug. I build all my services such that 'main' looks for a special argument or environment variable, and if that is set, don't call 'StartServiceCtrlDispatcher', just run the code routine it would run - that way you can run the program under the debugger in the user context and see console (i.e. printf etc) output.

My advice is the following.  If you want true real-time performance with Windows compatibility, then you need a Windows API emulator that runs on a real-time kernel.  On-time sells exactly that.

		http://www.on-time.com/

Personally I would never bother with Windows for hard real-time requirements.

You might also consider the WINE project with Real-Time Linux, but I am told that RT Linux is much less mature (more buggy) than Linux per se.

I'm no expert on DOSX but presumably if it runs under DOSX then it will run under Windows emulation.

Mark



On Sat, 26 May 2001 01:48:30 +0200, NancyEtRoland <nancyetroland@free.fr> wrote:
> first i esitate to expose my problem here as it is not specificaly DM C++.
> 
> but i would like it to have a DM C++ based solution..
> 
> More informations:
> 
> a PC based little cnc machine:
> 
> - must run a real time softwear,
> - must run a "'evoluted" OS because it is plugged on a LAN with other pc's,
> a web cam is plugged on it, it is plugged on Internet  for remote mantenance
> (Symantec pcAnywhere), etc..
> 
> well i don't feel like making all those drivers on MS-DOS..
> 
> The actual solution is:
> 
> A windows CAD/CAM program on the cnc and on the pc networked with it,
> a DOSX program only on the cnc, for driving the cnc itself on real time mode
> on pure dos.
> 

Thank you very much everybody,

I'm always surprised how powerful internet is, thank to people like you.

Now i have to "digest" all those information and use some of usefull links you give me.

Roland


NancyEtRoland a écrit :

> first i esitate to expose my problem here as it is not specificaly DM C++.
>
> but i would like it to have a DM C++ based solution..
>
> More informations:
>
> a PC based little cnc machine:
>
> - must run a real time softwear,
> - must run a "'evoluted" OS because it is plugged on a LAN with other pc's,
> a web cam is plugged on it, it is plugged on Internet  for remote mantenance
> (Symantec pcAnywhere), etc..
>
> well i don't feel like making all those drivers on MS-DOS..
>
> The actual solution is:
>
> A windows CAD/CAM program on the cnc and on the pc networked with it,
> a DOSX program only on the cnc, for driving the cnc itself on real time mode
> on pure dos.
>
> The problems are:
>
> - i wrote my worries about the future of DOS but especially the fact that pc
> motherboard are less and less pc compatible, (yes pc-104 is a solution)
> - i'm afraid pure dos mode will not exist any more on windows,
> - switching from windows to pure dos and back is long,
> - two programs to mantain.
>
> The ideal solution would be to integrate the DOSX real time program inside the Windows CAD/CAM program.
>
> I think Linux can be a solution.
> I think Windows can do it two.
>
> We have a Windows programmer but he is not a system programmer,
> i'm rather system programing oriented, but not a Windows programmer.
>
> that is the reason i asked for help for system programming on Windows
>
> Thanks
>
> Roland
>
> Roland a écrit :
>
> > One of our program is a DOSX program.
> >
> > We make real time with it on pure Dos: drives a cnc machine tool.
> >
> > It works fine, and i think nothing is faster than DOSX associated with DM C++.
> >
> > but i have some worries for the future:
> >
> > 1- will we be able to run in pure DOS mode in the future ? (i think Win
> > 2000 and Win Me as well don't support pure
> > dos mode),
> >
> > 2- PC's hardware are less and less PC Compatible.. as hardware is more and more virtualized,
> >
> > 3- for network, scanner and web cam, we have to restart windows, witch is pretty long..
> >
> > We are studying different solution for the future.
> >
> > One is to put more hardware in the machine (buffer) and port our program
> > on Windows.
> >
> > The question is:
> >
> > What is the maximum response time of windows on hardware request ?
> >
> > There is already some real time program on windows:
> >
> > software audio and image decompression, web cam, CD-R engraving, etc...
> >
> > I would like to have some general informations about those kind of software, do i have to make a device driver, is there someting special to know, advices, etc..
> >
> > Thanks very much
> >
> > Roland