View source for Summary of the IBM OS/2 1991 Technical Seminar

''This text was written by [[Peter Fitzsimmons]] on June 16, 1991.''

What follows is a summary of the IBM OS/2 1991 Technical Seminar, for an audience I define as "myself" (what I would want to read if someone else attended in my place).

This seminar is to be repeated two more times (I think) in the USA, so you can sign up for it yourself if you want. Included with the seminar (to follow later in the summer) is a pre-release version of OS/2 2.00, the IBM Programmer's Workbench, SoftTerm (an asynch terminal program), and a set of 32bit programming tools (including IBMs 32bit C compiler). The price is approx $1595US.

If your company will pick up the tab, go for it. If you're like me and have to fork out these dollars yourself (and perhaps even more significantly: take time off of your current job to attend), I'm not sure I would recommend you attend.

==Notes==
Novell (3.2?) on AIX & OS/2 2.00 will ship sometime late 1992.

ES/LS (Extended Services/LAN Server) will run on other vendors OS/2 1.3/2.0.

A new copy of OS/2 1.3 is US$150. To upgrade from  IBM  PC DOS, the cost is US$127 (and you KEEP your DOS license).

The version of OS/2 2.00 they had at the seminar (for demos and for us to play with) was 6.140, released 91/06/02. It no longer has a Microsoft (c) copyright.

OS/2 2.00 (hereafter called "V2") will "boot" an arbitrary version of DOS (such as DR DOS 5.00 or CP/M) from a diskette image stored on your hard disk. The VM (virtual machine) created for it thinks it is booting from drive A:, so you loose the use of physical A: for that session.

If you use the supplied DOS, you get in excess of 647,000 bytes of free RAM, with XMS/EMS/MOUSE/NETWORK/CACHE/VDISK all drivers present.

The current release TARGET for V2 is October. This is only a target and is not an official release date.

The ICON Editor comes with the base operating system.

The FAT file system has been improved (coined "Super FAT" by the presenter):
* Lazy Writes.
* Read Ahead Caching.
V2 can be configured with "sticky keys", so that a one handed operator can simulate multiple simultaneous key presses.

The session manager API is completely documented, so that you can write your own shell program if you want. You'll be told how to init PM and SPOOL. The example given for this was for a customer wishing to have a very controlled user workstation (one where users could not launch applications themselves). I was not able to get the microphone to ask, but this sounds like it might be a way to boot V2 without PM (I'm not  sure if this is desirable; since there is no such thing as a pure 32bit "full screen" program. ie: pure 32bit apps are always PM apps.).

DosQProcStatus() will not be documented. Mike Kogan (one of the better speakers at the seminar) was quite amused that I and others were able to find and use this undocumented API. He's going to take the thought back with him as a user requirement. He said DosQProcStatus() itself will never be documented, but clearly we do want an API in there so that we can enumerate the running processes. He told me to use DosQProcStatus() carefully, since it basically stops OS/2 while it collects the info it returns. I brought the whole topic up when I discovered that the info  returned from it is different from OS/2 1.3 - another very good reason not to use it.

WinAllocMem(), etc, are gone. You're supposed to use the base OS memory functions, such as DosAllocMem().

There are some new PM Controls. A CONTAINER control looks like a Windows 3.00 "Program group". It supports icons, bitmaps, text and date/time.

A NOTEBOOK control looks like a spiral-binder with little plastic tabs sticking out as bookmarks; except that the tabs can be sticking out of any edge of the binder.

The SLIDER Control looks like something you'd find used as a "balance control" on your home stereo. It is to be used in place of a scroll bar which some people were using as a selection control, rather than a scroll control.

Palette Manager: This new GPI feature allows a PM application to change the PM palette. PM decides when to change the palette, based on which application has the largest portion visible on the desktop, and on which app is in the foreground. Dithering is done for apps farther down in the z-order. Simple animation can be done by changing the palette.

Popup Menus are menus that are not tied to a menu bar. For example, a user can go up to a menu bar, and "drag" the Edit menu down to the middle of their document, where it will stay, so that it is "within reach".

The Font Driver Interface is documented. This is the interface that ATM (Adobe Type Manager; included with V2 and V1.3) uses.
Therefore, new font engines (such as TrueType) can be added to work with the font drivers supplied with V2.

You can change the default font.

There is a GpiQueryLocicalFont() API (thank God! You could only GpiSet...() it before).

More VIO fonts. 128 character wide host session supported on VGA.

Future Directions for PM:
* 32bit PMWIN.DLL.
* Distributed PM apps (32bit PM apps available to 286 DOS-Windows workstations, or non-Intel platforms such as UNIX via X11 protocol).
If OS/2 and/or PM is ported to a new platform or technology (such as "NT"),  the 32bit API will remain the same.

The toolkit is going to come with more (and better) samples.
(I'll believe it when I see it <g>). The source code for the games included with V2 (for example, an IBM developed version of Solitaire) will come with the toolkit.

The 32-bit C compiler was developed in house by IBM (in Toronto):
* Full ANSI C compiler.
* Re-entrant libraries.
* Consistent across SAA platforms.
* "lint like" options.
* DLL support.
* Optimizing.
* Asynchronous and in-memory file i/o.
* floating point libs.
* Improved memory management.
:After I get it (Mid-July time frame) I'll tell you if it works or not <g>

V2 supports 16-bit apps using "LDT Tiling", where the 286-style pmode segments are mapped onto 386-style flat pages. Thus the 16-bit apps are (ultimately) paging, not swapping. The entire 16-bit API is present in V2, and is mapped onto the new 32bit API on the fly.

Much of V2 is still written in 16 bits (more on this later), even though the interface to it is the new 32 bit API.

These last two points lead to a discussion of "THUNKING". A Thunk is a routine that translates a 16-bit segment:offset pair into a 32-bit flat offset, or vice versa. V2 relies heavily on thunking to support the old 16-bit apps, and to interface 32 bit apps with the portions of V2 which are still 16 bits (device drivers, for example).

Much thought was put into this, and thunking has very little overhead. The 16-bit selectors are assigned so that a simple 4 instruction algorithm can be used to convert it to 32 bits, and back again. The conversion happens at ring 3 (i.e.: no privilege switch is req'd).

Each application space is 512 MB. This limit is not arbitrary; the LDT tiling and Thunking techniques limit it.

Some Mixed model programs (programs that use both 32-bit and 16-bit APIs) may have to supply their own Thunks. For example, a set of PM apps (one 16-bit, the other 32-bit) that want to send each other WM_USER messages will have to use WinSetWindowThunkProc(hwnd, pThunkProc) to establish a thunk procedure to covert any pointers that are passed back and forth. (All system WM_* messages are autoThunked).

I mentioned that V2 is still made up of some 16-bit code. Here are some particulars, as Mike Kogan told us:
* The entire kernel is 32 bits, except for the file system.
* There is no 32-bit DDI (device driver interface) defined, therefore all of the device drivers use a 16-bit interface (but may use 32-bit logic internally).
* Queues are still 16-bit.
* Window Manager (Win...() is still 16-bit).
* GPI/GRE is currently 16-bit, but will be 32-bit by the time V2 ships. (This is the workhorse of PM, not the Win...() calls).
GPI is currently coded in 286 asm, and is being coded in 32bit C for portability (and performance).

The XGA driver is 32bit, exploits bus mastering, built in windowing support, hardware managed pointer, and can operate on system memory bitmaps. (wow - I can hardly wait to see one of those new 50MHZ 486 PS/2's running V2).

Every thread now has an exception handler (something like a signal handler). Thread 1 is a special case; it handles process signals and the Exit  List. Killing thread 1 kills the application.

Only two rings are used now, ring 0 and ring 3.

32-bit apps can (optionally) let the operating system dynamically grow the stack of a thread, thus very large stacks (in the megabytes) are supported.

Each VDM (virtual dos machine) uses 4MB of linear address space.  A task switch from one to another is as simple as a register set switch, and a page-context switch (ie: it is very fast, and does not require switching the CPU to real mode as is done in OS/2 1.x). The upper 3MB is defined as the "VDM workspace"; I don't specifically know what it is used for; screen images and the like, I would guess.

Each VDM has access to 16MB of XMS memory, 32MB of EMS memory, and 512MB (508 actually) if it is a DPMI app (such as the Windows 3.0 kernel that is included with V2).

They assured me that the new semaphore API (for private/anonymous semaphores) are just as fast (if not faster) than the RAM SEMAPHORES that OS/2 1.x supplied. The reason why they can be (sometimes significantly) faster than the old RAM sems is because of a brain-damaged DosClearSem() in OS/2 1.x. I'll try to explain; if several threads were blocked on a mutex semaphore under 1.x, DosClearSem() would release ALL of the threads, the
scheduler would post them all for execution, figure out which thread had the highest priority, then re-freeze all of the other threads. OS/2 2.00 will only unblock one thread when a sem is cleared. Apologies to Kent Cedola who figured out that DosEnterCritSec(), although not as elegant, was, much of the time, faster than RAM sems. Now we know why.

16-bit system semaphores are not compatible with any of the new 32-bit semaphores. If a 32bit semaphore needs to use an app that uses an old syssem, it will have to be a mixed 32/16-bit app that uses the old API to access that particular sem.

Named-shared memory, because of the 386 hardware, is much faster than OS/2 1.x, since the kernel does not need to be involved with memory transfers.

Standard Dialogs are now supplied (thank God!). They actually look good too. File Open, File Save, and Font Selection are supplied. They are customizable (no details given).

OS/2 1.x had a separate thread (and process) for swapping; thus swapping required a task switch. V2 does not.

There are four types of programs:
 link16---|    Pure 16 bit   |
 link32---|    Mixed 16 bit  |--- 16 bit runtime
          |    Mixed 32 bit  |
          |    Pure 32 bit   |--- 32 bit runtime
If you take a 16-bit application, and do nothing more than re-link it, it will become a "mixed 16 bit" EXE, and will see a performance will increase.

The new 32-bit API is "c like" in the sense that arguments are placed on the stack from right to left, and the caller (not callee) cleans up the stack. This allows the API to be changed in the future (by adding new arguments at the end) without breaking existing code (source or binary).

MOSS (I think this stands for Multiple Operating System Selection) allows you to boot several operating systems from your hard disk. It is an integral part of FDISK (FDISK, by the way, now has a full-screen version as well as a PM version). There are two ways you can use it:
# have more than one drive "C:" on your hard disk, such that booting one of them "hides" the others. This is useful for something that insists on booting from C:.
# Boot from another partition, such as D:. OS/2 2.00 will boot from D: (yiiiiiiippppppppeeeeeeee). This later method lets you access the partitions (such as C:) that may contain other bootable operating systems.

V2 install allows arbitrary source and destination drives. It will install over a LAN. It has a graphical install program. It uses PKZIP technology to speed up installation. You can jump to a command prompt at any time during Install.

CSDs: Graphical interface, LAN support, Progress indicators, Backout procedure.

Recommended Minimum Configuration:
                1.2       1.3       2.0
                -----------------------
 SE             3-5mb     2-4mb     3-5mb
 LAN Requestor  4-7mb     3-6mb     4-7mb

Applets: Calender and Diary, Address Book, Mini-spreadsheet and Database, Calculator, Alarm Clock, Business Graphics charting.

The next beta will have "32bit protected DLLs". Currently (under 1.x), a DLL that has SHARED data per instance can have parts of its dataspace corrupted by a separate processes. (It may not happen often, but it IS possible). This can even crash OS/2 itself. These new 32-bit protected DLLs will be able to have shared data (and/or be of the "init global" flavor) and be uncorruptable.

==A little more about MVDMs==
Migrate data to/from via PM clipboard (for Win and normal DOS text apps).

Named pipe support.

Bimodal device drivers (real/protected) are no longer required (This makes the job of writing an OS/2 DD a lot easier).

All but 10k of the 640k is available for a DOS app. This 10k is primarily used to support many of DOS's undocumented structures and features.  (note: The device driver chain is not supported; not many programs use this - some network programs do. If you want this level of compatibility,  simply boot a real version of DOS in a VDM).

Hardware is simulated. The following VDDs (Virtual Device Drivers) are supplied:
* BIOS
* PIC (interrupt controller)
* EMS
* XMS
* DMA (allows copy protected programs with a "key disk" to work, as well as programs like FASTBACK).
* Virtual CMOS
* NPX (80x87).

Some of us speculated that V2 would contain a BCL (Binary compatibility layer). Apparently this was coded, but it ran like a dog. Since IBM has a full cross-license for Windows 3.00 source, they simply included it with V2. They have removed large chunks of it (dealing with "386 enhanced mode"), since these features are now supplied by V2 itself. They also turned Windows 3 into a DPMI (DOS Protect Mode Interface) client, and it is run as any other DPMI client is under V2; except there is a few hooks in there to support cut/paste for the clipboard.

Win 3 runs in "standard mode" under V2. You can therefore start more than one winapp in a Win 3 session, and they will use "cooperative muktitasking" <giggle>, and crash each other just like they do under real Windows today. Or, you can start one winapp per Windows 3 MVDM, and get pre-emptive multitasking and full memory protection.

Ron Cadima did a side by side V2/Win3 demo for us. The Windows machine had twice as much memory installed (16mb vs 8mb on the OS/2 2.00 machine). The Win3 machine was configured to be as fast as possible (large smartdrv, himem, enhanced mode, etc). The V2 machine was using the new SUPER FAT (not HPFS or lazy write), so as not to make Win look too bad <g>. Two programs were used for this demo; a Win3 "disk write" program that writes data out to disk a few hundred times, and a Win3 program that draws a MAP about a dozen times. Both programs time their own execution.
                          Windows   OS/2
 DISK WRITE               28        10
 DRAW MAP                 4         8
 DRAW MAP/DISK WRITE      26        8   (time for map)
  (time in seconds).
You'll notice that the win machine did one thing faster - the drawing of the map while no other programs were running. But look at the difference when the same program was running while the disk write program was running!.

==REXX==
Not much new here, except for performance. When they converted it to 32 bit, they saw a significant (60%?) performance increase.

There will be an online REXX reference.

IBM really wants this to be the next "basica", and spent more time talking about it than I wanted to hear. <g>.

==Programmer's Workbench==
This is a PM program that is extensible. It reminds me very much of Microsoft's PWB program (which is NOT a PM program), except that it does not  have a built-in editor. There was a demo given, but it is hard to judge such things without using it yourself. I saw nothing revolutionary about it.

Actually, I found IBM's hyping of this tool a little arrogant.
They describe it as the last IDE (integrated development environment) you'll ever use, and "of course" all future compiler vendors will support it. Ten minutes later they touched on Borland C++, which will ship with it's own Borland-standard IDE (but will probably plug into IBM's workbench as an option).

Except for the possible interface to IBMs workbench, Borland's C++/TASM for OS/2 has nothing to do with IBM. It will not be licensed or marketed by IBM.

Oddly enough, Zortech was one of the guest participants at the seminar, yet they were not mentioned in the slides during this presentation. One of the attendees (obviously an angry Zortech C++ fan) pointed this out to the presenter during Q&A. Zortech ships a C++ compiler for OS/2 today.  Borland's has a planned (but not announced) ship date of 2H92. Go figure.

The Borland slide had "PM Debugger, PM Profiler, OOP Assembler,
Resource editor and compiler" listed as features. Could be good!

IBM, by the way, will be shipping a PM debugger with their 32-bit C compiler. It will have a built in PM queue debugger (like PMSPY).

==IPF==
The Information Presentation Facility will have author-controlled fonts and horizontal scroll bars.

Multi-view support (for mixed text/graphics and motion video support, etc.).

==Extended Services==
A lot of time was spent talking about DBM (database manager). The most significant new feature is "roll forward". All and all, DBM is still not as good as SQL Server in my opinion - unless you are planning to interface to other SAA platforms. (There are ways to do this with SQL Server too, though. Not all SAA platforms, but you never know).

There are no plans for an SQL API; we're stuck with the embedded SQL - although the presenter I asked about this said he recognized the requirement and the "mind set" (like mine) that wanted a clean C API.

A few interesting things about CM (communications manager). A new feature, called LOC (LAN Over Coax) is a very clever feature. As a result of embracing NDIS (Microsoft/3Com's Network Device Interface Standard), CM/LS have gained a lot.
This new LOC feature allows you to run a LAN using your 3270 connection card, over standard coax cabling. It is not as fast as a 4mbps token-ring, but it is very good news to people that have a lot of this cable buried in the walls.

CM now comes with a real ASCII terminal program. It is a subset of Softerm Modular, from Softronics. It has a whole bunch of terminal emulation modes and file transfer protocols, including IND$FILE (zmodem to arrive in late  91). Softronics has look-alike programs for DOS/Windows. It is not a PM program.

It looks like we are still stuck with C:\MUGLIB, so it is possible that MS LAN Manager will not coexist with ES.

==Network Services/2==
This is a new product that will probably be merged into ES (Extended Services). It may even be part of ES when it is released later this year. However, NS/2 is available now (it was just announced recently) for about us$200 (for EE 1.2 or 1.3).

NS/2 is a complete rewrite of APPC, and much more.

Bob Trower and I bumped into the presenter, Steve Joyce, in the demo room the day before his presentation. As soon as he said "I've got a better APPC", an alarm went off in my head (Run away! Run Away! Run Away!), and I ditched him as quick as I could. Anyone who has used APPC under EE OS/2 knows how I feel.
Just configuring it can turn your hair gray. From a programming viewpoint, a mature man can be brought to tears trying to get those first few bytes across the LAN. Named pipes look so much better you'll consider waiting for them to implement them under TSO and/or VM <g>.

After Steve's presentation, I had to go back and apologize profusely. Besides encapsulating an exciting idea called APPN (Advanced Peer to Peer Networking), NS/2 will install/configure over top of CM with three parameters - you never have to wander aimlessly around the CM config screens.

APPN is a concept where you don't have to rigidly define everything. It is part of SNA/SAA. It dynamically finds LUs on the network and picks the best route, rather than the way something like VTAM works today.

NS/2 also has a new APPC programming interface called CPI-C (Common Programming Interface), which supplies a 100% source compatible APPC interface across all SAA platforms (3090, AS/400, etc). CPI-C is still not as nice as Named Pipes, but Steve said they were working in an Open/Close Read/Write interface that most micro programmers can wrap their brains  around.

APPC has DRASTICALLY improved performance (double), with reduced CPU usage (50%). All current OS/2 APPC apps gain from these benefits. Faster  than Named pipes. Sends at about 7mbps on a 16mpbs TRN (under OS/2 1.3).

NS/2 comes with REAL sample programs.

Besides the simple config (you don't even have to define the TPs if you don't want to!) NS/2 makes the APPC programmer's life much easier with better error codes. Before, if your ALLOCATE failed, you weren't told WHY. (It could have been any number of things, like a screwed up CM config, bad wiring, programmer error, etc). NS/2 will tell you why your ALLOCATE failed. This one little feature can potentially save days of programming hours.

NS/2 has "local-remote transparency". This improves its performance, but more importantly, lets you write an APPC program with only one computer (one machine debug).

NS/2 comes with some utilities that you may have seen before as IBM IUO (Internal Use Only) utilities, such as an APPC TRACE file analyzer.

I don't plan on rushing out and writing a bunch of APPC apps, but you can tell I liked NS/2. I'll perfectly happy with Named Pipes most of the time, and as long as the app is running solely on a LAN (no host interaction) I'll continue to use them. But I think NS/2 has drastically removed my fear of programming APPC again - especially when the host programmers and I will be able to talk the same language (CPI-C).

==NDIS==
They went on and on about this. It was not why I went to an OS/2 seminar. If I plan on writing an NDIS driver, I'll download the spec and read it, thank you very much.

It was nice to know that 100mbps Token-Ring LANs are on their way though.

Further to a Ethernet/Token ring argument I've been having with some people, IBM had a good real-world example where TR shines over Ethernet. In their full motion video (DVI) work, they found that they could only have one station running video across a 10mbps Ethernet, since Ethernet is a  collision-based bus network. If they added another workstation, the video and audio would go out of sync, or become too choppy to watch. A 15 station TR (16mbps) LAN had no problem running the same s/w.

==LAN Server (LS) 2.00==
Almost the same as LAN Manager 2.00 <g>.

The largest differences are in the user interface (not even remotely similar) and the fact that LS 2.00 does NOT HAVE PEER SERVICES. (You should have seen me standing there with  my mouth open in disbelief). They did not even mention it - I had to ask them the question point blank during Q&A. They said the way MS implemented peer services was not good enough for IBM customers. (So IBM customers get nothing - go figure).

For those who don't know, Peer Services allows an OS/2 workstation to become a limited server. It can server disk resources (one user at a time), or print resources (more than one person at a time). You can't do this with LS 2.00, so you will have to buy the full blown server software just to share a printer.

There are some good things to say about LS. The Net API is allegedly 100% compatible with LAN Manager 2.00 now.

Since it uses NDIS drivers, dozens of third party network cards will work with LS now.

LS has HPFS386 (available with LM about a year ago). This gives much better remote performance, and has new features like Local Security.

HPFS386, CACHE.EXE, and the "ring 0 server" (netwksta.sys) have an intimate relationship. When a request comes from a workstation, the request has a good chance of being satisfied completely in ring 0. This can drastically improves performance, because before it would have taken a round-about route up to ring 3 (to the main server code) and  than through the OS/2 kernel to the file system (at ring 0) and then back up to ring 3, etc.
HPFS386 never even goes through the OS/2 kernel. Since local applications run at ring 3, and go though the kernel for file system access, running HPFS386 has no (or very little) effect on local application performance.

Unfortunately, this makes LS 2.00 incompatible with OS/2 2.00! After drilling the speaker about it, she finally agreed that if I used the default HPFS.IFS that ships with V2, there would be a good chance that it will work; but I'll have to wait till LS 2.00 is released to know for sure.

MS shipped a multi-processor version of LAN Man to Compaq, which will run on their SystemPro (I'm not sure if it is released yet). IBM's multi-processor version looks better. Not only is HPFS386 on the second CPU (as with the Compaq version), but so is the ring 0 server, NetBIOS and the NDIS drivers. Coupled with a busmaster Token Ring  card, it is possible that a remote data request could be satisfied without ever using the main CPU. If the data is located on disk (not cached), then the main CPU will be needed. However, since  Microchannel supports peer-bus masters, it would be possible for the TR card to talk directly to something like a bus master SCSI card for the data - this is in the future though. (is this sort of thing even in the EISA spec?).

LS 2.00 comes with all of the disk mirroring/duplexing software than LM 2.00 has. UPS support too.

One unique feature to LS is "dynamic sharing". A server does not SHARE a device until the first user tries to USE it.

LS will run on OS/2 SE, including OEM OS/2 and hardware (Compaq, Olivetti, Siemens, Tandy and Zenith were given as examples).

RIPL (Remote Initial Program Load) is supported for OS/2. Each RIPL client can have a separate subset of files (config.sys, for example).

Novell support to be released in 3 phases. Even after the final phase, Netware clients will not have access to LS/LM servers (unless they load two requestors).

IBM is setting up a LS application certification program (like Novell has, except that IBMs is free).

A busmaster TR driver will be available for OS/2. A benchtest showed that with this driver the CPU utilization dropped from 70% to 15% on a particular test.

==SPM/2 (System Performance Monitor/2)==
This tool is available now in the US, and on June 28 in Canada.

SPM/2 is a combination of some separate tools we have seen from IBM and elsewhere. It has a CPU Usage Monitor, Physical Disk Access meter (by monitoring the disk DD), and a Memory Usage Monitor. These three run as separate child windows in the same PM app.

The last one looked the most interesting (since we've all seen many CPU monitors). The Memory monitor shows many things in a combined graph, so you can clearly see the relationship each has with each other. For example, the system will start swapping the moment the "working set" of memory exceeds your physical storage.

SPM/2 receives its data via a named pipe from the DCF (Data Collection Facility). Since it uses a named pipe, the computer you are monitoring can be a remote computer. The pieces are sold separately (SPM/2 with DCF is us$245, and DCF alone is $75).

THESEUS is included too (They plan to clean up the user interface of it soon).

The data can also be dumped to a log or spreadsheet file, so that a remote operator (using something like Netview/DM) can grab the data off of the remote servers and analyze it centrally.

The named pipe data is completely documented; so you can write your own real-time apps using the data if you want.

Since the Disk Activity monitor has a close relationship with the disk device driver (disk0?.sys/base0?.sys), this feature may not work with OEM versions of OS/2, if the OEM changes the DD and does not leave the proper hooks in. IBM OS/2 1.2 and 1.3 have these hooks today; someone like Compaq may not have them.

==Multimedia (MM)==
IBM will be shipping beta OS/2 Multimedia extensions this year.

IBM does not see DOS as a good environment for MM, so it will not be supported very much. They will be concentrating on OS/2.

Since 1991 seems to be the year everyone is defining MM, there is not too much to tell you. The demonstrations IBM did for use were impressive though.

One thing that caught my attention was a 16-bit ACPA card (Audio Capture and Playback Adapter) which will be compatible with SoundBlaster cards.(Isn't Compact Disk technology based on a 16bit DAC? This card will sound awesome).

==MISC==
OS/2 1.3 contains 1500 source code changes to fix problems in 1.2 (the last 1.2 CSD fixed 1000 of them).

IBM is working with the following companies to test ES and/or V2:
 AST      Siemens  Acer          Everex
 Netframe CompuAdd Hewlett       Packard
 Dell     Olivetti Tandy/Grid    Compaq
 AT&T     Epson    Tandon        Reply
 Trichord NEC      NCR           Apricot
Some new toys were recently announced by IBM:
* 128MB optical diskette.
* 8516 Touch screen. This monitor uses a new technology called a "Strain Gage" which is built right into the monitor glass. If you look at an 8516, it looks EXACTLY like an 8515. The strain gage is NOT based on capacitance or resistance, therefore you can press on the screen with anything you want (pen, gloves, hammer <g>, etc), not just a human finger. There are 256 pressure levels.

[[Category:Event Review]]