home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.os2.misc
- Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!smsmith
- From: smsmith@magnus.acs.ohio-state.edu (Stephen M Smith)
- Subject: Re: Game port access in DOS box under OS/2 (v2.0) ?
- Message-ID: <1992Jul24.040229.24640@magnus.acs.ohio-state.edu>
- Sender: news@magnus.acs.ohio-state.edu
- Nntp-Posting-Host: bottom.magnus.acs.ohio-state.edu
- Organization: The Ohio State University
- Date: Fri, 24 Jul 1992 04:02:29 GMT
- Lines: 30
-
- mig@cunixb.cc.columbia.edu (Meir I Green) writes:
-
- >>Is it possible for a program running in a DOS box under OS/2 (v2.0)
- >>to access the game port.
- >
- >It works fine on my 386/40. msd.exe even reads the port in real time.
-
- OS/2 is just SO coooool. I love to run msd.exe when I have a com
- program running because OS/2 traps the attempts to read the com
- port and STILL allows the utility to examine everything else! This
- would have caused the system to hang under Windows or Desqview.
- In fact, I hung my com port a lot when running QAPLUS under DV.
-
- I just added the following entry to the list of things that OS/2 has/
- can do that Windows doesn't have/can't do:
-
- --Allow utilities that analyze the hardware to safely proceed when
- trying to access hardware that is being used by other
- processes. For example, if a utility tries to examine
- the status and configuration of the COM and LPT ports and
- one of the COM ports is being used by a communications app,
- OS/2 will trap the attempt to access that COM port and allow
- the user to tell the utility to "ignore" the COM port and
- proceed to analyze other hardware. When the utility is
- done, that COM port is simply reported as "not available".
-
- Steve Smith | __|__ | " #*&<-[89s]*(k#$@-_=//a2$]'+=.(2_&*%>,,@
- <smsmith@magnus.acs. | | | {7%*@,..":27g)-=,#*:.#,/6&1*.4-,l@#9:-) "
- ohio-state.edu> | | |
- BTW, WYSInaWYG | | | --witty.saying.ARC
-