feustel@netcom.COM (David Feustel) (05/28/91)
At least the 16-bit OS/2 1.3 interface is stable(frozen). The 2.0 interface appears to be still changing as I type this message. -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 EMAIL: feustel@netcom.com or feustel@cvax.ipfw.indiana.edu
tholen@uhccux.uhcc.Hawaii.Edu (David Tholen) (05/28/91)
Allan S. MacKinnon writes: > Do you think MOST developers will go right to using the full > 32-bit capabilites (i.e. can't use it in 1.3) -OR- do you > think that they will still offer versions for 1.x? Well, it's true that a lot of developers still generate code for the lowest common denominator (8088, no 8087) to maximize the potential market for their product. If they continue such strategy, they will develop for 16-bit OS/2, given that 16-bit apps are supposed to run under 32-bit OS/2 just fine. There are at least two reasons why real 32-bit apps might be written: (1) perhaps market surveys will show that the number of 286 machines running OS/2 is so small that this segment of the market can be safely ignored; (2) those developers who need the flat address space of 32-bit OS/2 to solve problems with those 64-kbyte segments of the older processors will definitely take advantage of it; if the 64-kbyte segments are not a problem for them, there is less incentive to develop for 32-bit OS/2 only. I'm sure there are other reasons as well, such as performance; a 32-bit data path is twice as wide as a 16-bit data path, so some code might speed up by close to a factor of two; if speed is essential to a product, 32-bit is the way to go. (Of course, this discussion ignores what a lot of developers may actually do, which is develop single-threaded Windows apps and port them to OS/2, which is a less-desirable approach, speaking from an OS/2 perspective.)