| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | OS/2 programming tips ??? |
David Etheredge wrote in a message to Mike Bilow: DE> 1) I am writing a program for OS/2 that I only want one copy DE> to load. How can I detect whether or not a copy is already DE> loaded at runtime? MB> There are several ways to do this, but the easiest is to attempt to MB> create and request ownership of a semaphore with a MB> predefined name when your program starts and then MB> release and close it when your program ends. If the MB> semaphore is already owned when you request it with a MB> time-out of zero, then you can assume that another MB> instance of your program is running. You obviously MB> need to take some care in using a semaphore name that MB> would not be likely to collide with that used by MB> another program. DE> Unfortunatly, the program can be called in the startup DE> routine and would most likely be in use until either DE> shutdown or powerdown. This means that the semaphore might DE> be left on disk and the program would not load during the DE> next startup. I am looking for something more like the DOS DE> Multiplex functions. The OS/2 semaphore facility that I was describing above does not go through the disk. There are API calls available which allow the use of kernel semaphores, which are entirely contained in memory and which are automatically extinguished when all of the processes which have access to them are no longer running. You need to look at the OS/2 Control Program documentation, specifically at such functions as DosCreateMutexSem(), DosOpenMutexSem(), DosRequestMutexSem(), DosReleaseMutexSem(), and DosCloseMutexSem(). DE> 3) Are you allowed to use the 1ch timer in OS/2? If not, how DE> can you synchronize timed events to the tic counter? MB> Maybe you would get better answers if you backed up a MB> bit and explained in more broad terms what it is that MB> you want to do. There are numerous timer APIs provided MB> in OS/2, some such as DosSleep() based on CPU time, MB> others such as DosTimerXxxx() based on absolute time. DE> Well, I need something more reliable in order to more DE> reliably simulate real-time operation (which I hear is a DE> failing with OS/2). Interrupt driven is probably a key word DE> here. Hooking the Int 1Ch vector in DOS is by no means a "real time" facility. As a matter of fact, the only thing that you get by hooking the Int 1Ch vector in DOS is a very primitive kind of multitasking. Just running an ordinary thread in OS/2 will get you that much. If this does not prove adequate, you can have your thread set itself to a fixed-high priority, and that almost always suffices. When we say that OS/2 has no true "real time" facility, we mean that in the context of issues such as interrupt latency and scheduler latency. OS/2 is really designed as a desktop operating system, but there are ways of adjusting priorities and organizing your program to get at least as good performance as you would from the Int 1Ch vector in DOS. DE> 5) is there a way to do automatic unattended shutdown and DE> reboot? MB> Yes, and it is undocumented. The procedure is actually MB> not simple, since you have to do things very carefully MB> and in a strict order, such as shutting down the file MB> system. You also have to make sure you don't kill your MB> shutdown process, which requires a bit of special MB> handling. Why do you want to do this? Programmers MB> should not assume that they own the machine under OS/2, MB> and doing things like shutting down the operating MB> system would be viewed as not being a good OS/2 citizen. DE> If the operator who is using the computer that is running DE> one of my programs runs some other program, he understands DE> and wants my program to have absolute priority. The operator DE> would only use any other task with this understanding as he DE> would be at risk of considerable financial loss if my DE> program failed. You can set threads in your program to run at fixed-high or time-critical priority if absolutely necessary. There are even more extreme things you can do, such as setting PRIORITY=ABSOLUTE and adjusting the TIMESLICE parameter in CONFIG.SYS. However, if you are writing a program that must have total control of the machine and you never want to allow anything else to run, then what is the point of using OS/2? You would be much better off using DOS. In any case, how would abruptly rebooting the machine solve this? If bad consequences would ensue from even a single missed interrupt, I would expect utter disaster to result from a reboot. MB> Well, as I asked, what is it that you are trying to do? DE> Most of the programs that I write are control programs. DE> Automater Water purification and distribution systems, DE> automated irrigation and chemigation systems, power DE> substation monitoring and control, environmental monitoring DE> and hazard alart systems, etc. All of these are MUST NOT DE> FAIL applications if you know what I mean. No PC or PC-based operating system is suitable for a "must not fail" system. I use OS/2 and have very high regard for it, but I would not use it as a platform for, say, a life support machine. Some of the things you describe can only be done properly with custom, triple-redundant hardware. Even if OS/2 is the world's finest operating system, it will fail quite thoroughly if it happens to be running on a machine with a power supply that was soldered together by prisoners in a Chinese labor camp. DE> Being fairly new to OS/2 programming, I am asking questions DE> as fast as I can come up with them. I appreciate your help. OS/2 can be quite reliable and is a nice platform for control software of the general sort you are describing, but I would not trust my life to it. -- Mike ---* Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8 (1:323/107) SEEN-BY: 105/42 620/243 711/401 409 410 413 430 807 808 809 934 955 712/407 SEEN-BY: 712/515 628 704 713/888 800/1 7877/2809 @PATH: 323/107 150 3615/50 396/1 270/101 105/103 42 712/515 711/808 809 934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.