seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) (09/04/90)
Why not talking a little bit about OS/2 vs. 2.0 ? Slowly but surely some magazines start writing on the upcoming version 2.0. Anyway, the informations that I could get up to now are a little bit confusing. So I thought that this might be a good place to post a few questions and maybe start a small discussion: One of the features that are completely unclear to me concern the new APIs. As far as I read there will be the "old" 16-bit API and a new 32-bit API. Some Kbd, Mou,... will be discontinued. Well, what I don't see in the moment is how software development is supposed to work in future. My line of reasoning is that there are quite a few systems around running on a 286. As far as I understand there will be no way to have the new 32-bit API on these machines (?). Assuming this I would really like to know if anybody plans to use these new features since I guess that the market will get completely crazy dealing with two kinds of OS/2 software for different versions. Or maybe my assumptions are wrong: A better alternative might be if the new APIs would be provided for 286- machines, too. However, these functions would have to be mapped onto the capabilities of this hardware (what will probably be a complete mess). From the user's point of view this would be very nice since he doesn't have to worry about upgrading his software if he gets a new motherboard. On the other side software developement would be a lot easier since there would be only one kind of OS/2 version and not a few. I just try to imagine a software company developing two OS/2 versions (286 and 386+...) for a market that isn't that huge anyway... Is there anybody who would like to comment on this? I guess there are quite a lot of people (at least outside the U.S. where information is coming bitwise) who would like to know a little bit more. Thanks ! Uli
rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (09/04/90)
In article <1990Sep4.130929.16442@sun1.ruf.uni-freiburg.de> seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) writes: >Well, what I don't see in the moment is how software development is supposed >to work in future. My line of reasoning is that there are quite a few systems >around running on a 286. As far as I understand there will be no way to have >the new 32-bit API on these machines (?). Anybody who already works with OS/2 1.x knows, that for serious work, a 386 is required for 1.x too, because of the speed. I would not recommend using OS/2 on a 286 with up to 12MHz. A 386 with 25MHz and no cache is just fine. It's the same with memory (at least 8MB). For the 286's even Windows 3.0 becomes very slow when used on a machine with less than 3-4MB. And because of the new capabilities of 2.0 with a 386 (or 486) I don't think that the 286 machines will play a big role for the OS/2 market. Most *existing* 286 machines can rarely be used for OS/2 because hardware upgrade costs are too high (many don't even have sockets for enough 1MBit chips and require expensive RAM cards). >Assuming this I would really like to know if anybody plans to use these new >features since I guess that the market will get completely crazy dealing with >two kinds of OS/2 software for different versions. I was so often angry about the 16bit architecture (when using programs using very much data, ported from 32bit Unix systems, GNU diff, for example) that I *will* use the new features even in such small utility programs, as soon as I get an upgrade to 2.0 ... >Uli Kai Uwe Rommel Munich rommel@lan.informatik.tu-muenchen.dbp.de
seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) (09/05/90)
rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) writes: >Anybody who already works with OS/2 1.x knows, that for serious work, a >386 is required for 1.x too, because of the speed. I would not recommend >using OS/2 on a 286 with up to 12MHz. A 386 with 25MHz and no cache is >just fine. It's the same with memory (at least 8MB). For the 286's even >Windows 3.0 becomes very slow when used on a machine with less than >3-4MB. And because of the new capabilities of 2.0 with a 386 (or 486) I >don't think that the 286 machines will play a big role for the OS/2 >market. Most *existing* 286 machines can rarely be used for OS/2 because >hardware upgrade costs are too high (many don't even have sockets for >enough 1MBit chips and require expensive RAM cards). I think Kai Uwe is absolutely right. It is really a pain in the neck to do some serious work on a 286 machine. In any case it is a good idea to have a fast machine for OS/2. It is an old rule that usually you want to use the advantages of a powerful operating system after some time. But anyway, the strategic decision of IBM and Microsoft has been to develop OS/2 already for 286 machines. And I guess that this will be o.k. for some applications in companies, for instance. So we can't help it, OS/2 is an operating system for 286 processors and higher. Maybe we can start a new discussion on the Windows 3 vs. OS/2 topic seperately. So, for now we know Kai Uwe's position and mine is very similar. But what about the rest of the community? It would be really great if somebody else could tell us what he thinks. Maybe there is also somebody from a big software company who could give us an idea what they want to do concerning software development for 16-bit and 32-bit versions of OS/2. Greetings, Ulf
alistair@microsoft.UUCP (Alistair BANKS) (09/06/90)
In article <1990Sep4.130929.16442@sun1.ruf.uni-freiburg.de> seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) writes: >One of the features that are completely unclear to me concern the new APIs. >As far as I read there will be the "old" 16-bit API and a new 32-bit API. >Some Kbd, Mou,... will be discontinued. >Well, what I don't see in the moment is how software development is supposed >to work in future. As has been stated in these comp.os.os2.... areas before, OS/2 2.0 has all the APIs that are in OS/2 1.X including the KBD, MOU & VIO subsystems - these are all 16-bit APIs. OS/2 2.0 add 32-bit APIs - these are an addition, they do not preclude use of the 16-bit APIs, nor do they preclude use of 16-bit applications - OS/2 2.0 is a true superset of OS/2 1.X. Some of the duplicated functionality will not be brought into the 32-bit APIs. VIO, MOU & KBD all fall into that arena. Successful OS/2 applications will be graphical, and there are very rich facilities for aquiring mouse & keyboard events using either the PM APIs or the Windoes APIs with the Software Migration Kit (SMK) on OS/2. The VIO subsystem does not mix well with either the Win or PM APIs, and was only useful when porting 16-bit character applications quickly from the DOS world. Also, one of Microsoft's duties is to provide direction to the industry - we have said that Microsoft's Operating System family will be ported to run on non x86 machines over time - that means non-PCs. You will quickly realise that KBD, MOU & VIO are simply extensions of DOS-based, BIOS & x86 concepts, and that they are not very portable - so Microsoft is giving direction that the 32-bit API should be for either 'detached' style server apps, stdin/stdout filter-type apps or full GUI apps. Alistair Banks OS/2 Group Microsoft
feustel@well.sf.ca.us (David Alan Feustel) (09/07/90)
I suspect that there may be some interest in writing OS/2 applications
using the 1.2 APIs but running on OS/2 version 2.0 since the memory
management and debugging is (IMHO) better with the 1.2 API. This is
only true for small applications or applications that can be
decomposed into small programs where the 64k segments don't cause too
much aggravation.
Unfortunately, the 1.2 emulation of version 2.0 is not yet perfect;
Smalltalk V/PM runs fine on IBM OS/2 v1.2 but dies immediately when
run on the MS OS/2 v2.0.
--
Phone: (work) 219-482-9631; MCI mail: DFEUSTEL
E-mail: feustel@well.sf.ca.us {ucbvax,apple,hplabs,pacbell}!well!feustel
USMAIL: Dave Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805-2710feustel@well.sf.ca.us (David Alan Feustel) (09/07/90)
So how far away is an OS/2 version 2.0-specific device driver
development kit?
--
Phone: (work) 219-482-9631; MCI mail: DFEUSTEL
E-mail: feustel@well.sf.ca.us {ucbvax,apple,hplabs,pacbell}!well!feustel
USMAIL: Dave Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805-2710feustel@well.sf.ca.us (David Alan Feustel) (09/08/90)
Also, the more I play with the DOS box the more I think I would like
each dos box to be started with an optional CONFIG.SYS file that would
work just like on a stand-alone pc.
--
Phone: (work) 219-482-9631; MCI mail: DFEUSTEL
E-mail: feustel@well.sf.ca.us {ucbvax,apple,hplabs,pacbell}!well!feustel
USMAIL: Dave Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805-2710jeff@cornea.mitre.org (Jeff Graber) (09/12/90)
I have been trying to get DosExecPgm to work. But it doesn't seem to be passing the parameter I specify. I have to go to a different computer on a different floor so this example may not be accurate. I have tried specifying the full path to the parameter file, added a \0, and not done either of those two. Anybody have any success with starting a .exe with a parameter?? Thank s Jeff Graber
davidst@microsoft.UUCP (David STECKLER) (09/13/90)
In article <119809@linus.mitre.org> jeff@cornea.mitre.org.UUCP (Jeff Graber) writes: >I have been trying to get DosExecPgm to work. But it doesn't seem to be >passing the parameter I specify. I have to go to a different computer on >a different floor so this example may not be accurate. I have tried >specifying the full path to the parameter file, added a \0, and not done >either of those two. > >Anybody have any success with starting a .exe with a parameter?? > > >Thank s > >Jeff Graber To quote the docs about the pszArgs parameter, "...the program name, a null character, the program parameters (separated by spaces), and two null characters." Thus, if your program is Pickle and your arguments are arg1, arg2 and arg3, your argument string should be: "Pickle\0arg1 arg2 arg3\0" C (hopefully :) put the 2nd \0 at the end when it zero-terminated the string. ...Dave