farber@linc.cis.upenn.edu (David Farber) (03/10/88)
I have just brought up OS/2 on a 386AT. Several questions. Anyone have a microemacs that runs under it (crashes on mine) and anyone know how to use a ms bus mouse with it? Dave --------------- David J. Farber; Prof. of CS and EE, Director - Distributed Systems Labs. University of Pennsylvania/200 South 334d Street/Philadelphia, PA 19104-6389 Tele: 215-898-9508 "The fundamental principle of science, the definition almost, is this: the sole test of the validity of any idea is experiment." -- Richard P. Feynman
mjy@sdti.UUCP (Michael J. Young) (03/11/88)
In article <3601@super.upenn.edu> farber@linc.cis.upenn.edu.UUCP (David Farber) writes: > > >I have just brought up OS/2 on a 386AT. Several questions. > >Anyone have a microemacs that runs under it (crashes on mine) and >anyone know how to use a ms bus mouse with it? Sorry for the post, but mail fail... I ported micro-emacs 3.9 to OS/2. I made a new file os2.c that was the OS/2 equivalent of ibmpc.c, and made some minor changes to various other files. I can send you os2.c and the diffs, if you like. It works pretty well, but I eventually ended up buying Epsilon for OS/2 from Lugaru Software. It's much more powerful, but it's not free. I've never used a mouse with micro-emacs, so I can't help you there. -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel: +1 617 443 5779
alex@mks.UUCP (Alex White) (01/17/89)
There doesn't seem to be an os/2 newsgroup, so lets do it here! I've just finally getting so sick of os/2's system-call level botches that I have to scream, even if only to the net. These people, that had the example of Unix before them, and Dos behind them, managed to do so many basic basic basic things wrong. DosExecPgm takes arbitrary argv, arge lists... but DosStartSession only takes one argc; cmd.exe uses DosStartSession, so this means every program still has to have full arg list processing in its startup. Signals aren't inherited by childen, there doesn't appear to be any method of setting a child's signals on or off. This is very much a single-user system. No future provision whatsoever for any form of multi-user interaction. For example, DosTimerAsync requires a named public semaphore to do timing - this means that any arbitrary process can fire off your timer. While they have left it open to future different file systems [e.g. if you open a file with 9 characters you get an error, rather than truncating like dos] they haven't left anything open for userids. No fork. You can kludge it, but its slow. No concept of a unique file name identification internally (i.e. like an inode number). This manifests itself by such goodies as file locking; you can't do ANYTHING to a file which is being executed -- well, you can rename the directory its in, do what you like to the file and rename the directory back!!! No form of cpu usage is available; i.e. not possible to write time, prof. Actually, prof comes with the SDK, but with a readme which says the kernel hooks won't be in the production versions of OS/2. The compatability box sucks. I can't touch-type in it, it drops so many keyboard keystroke transitions, its constantly dropping characters and loosing the state of the shift/ctrl keys. Oh, and get this one! This one is wonderful. The equivalent to stty for terminals (KbdSetStatus) has TWO bits for echo, and TWO bits for raw. i.e. one bit says echo on, and a different bit says echo off. What happens if both are on or both off you ask?? well, there are the errno values: ERROR_KBD_INVALID_ECHO_MASK, and ERROR_KBD_INVALID_INPUT_MASK Speaking of keyboards, all the zillions of things you can normally do with keyboard handlers can't be done - i.e. erase/kill characters and such. It appears to be able to lock up the system easily enough. For example, when VI comes in, it gets a bunch of buffers - 400k Now 9 times out of 10 it works fine. Just occasionally vi will hang while it trys to get the memory. Not available? swapping? Who knows? Going back to the PM, starting another shell and spawning another vi will sometimes work, sometimes not. Going back to the PM and closing the window will sometimes kill the vi, sometimes not. No way to find out the state of memory. i.e. if any process is in memory, or swapped out, or what free memory there is. Some programs don't recover in an out of memory situation, some don't. For example, NET, the lan manager interface brings up the screen and then ignores keystrokes. The purchase of an extra 2megs solved this [bringing my machine to 6megs]. The compatability box Dos version system call returns a version of 10.10. Since this version is supposedly compatable with 3.3, this means you can't check for dos version 4, but doing >3, but rather >3 and <10. "OS/2 -- yesterday's operating system tomorrow"