Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

OS/2 2.0 Technical Seminar Summary

29 views
Skip to first unread message

Conrad Bullock

unread,
Jul 27, 1991, 7:03:00 AM7/27/91
to
This file has been knocking about on Fidonet for a while, and I
haven't seen it here yet, so I thought I'd post it. I found it VERY
interesting reading.


This text was written by Peter Fitzsimmons on June 16, 1991 and
posted as a series of seven messages in the Fidonet OS2PROG echo
conference. The text is collected and posted here in this text
file for a wider distribution. Pete Norloff 6/19/91

_____________________________________________________________________

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
-----

Novel (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 X.11 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 32bit 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
16bit 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 32bit 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 16bit 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 (ie: no privilege
switch is req'd).

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

Some Mixed model programs (programs that use both 32bit and 16bit
APIS) may have to supply their own Thunks. For example, a set
of PM apps (one 16bit, the other 32bit) 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 16bit code. Here
are some particulars, as Mike Kogan told us:

- The entire kernel is 32bits, except for the file system.
- There is no 32bit DDI (device driver interface) defined,
therefore all of the device drivers use a 16bit interface
(but may use 32bit logic internally).
- Queues are still 16bit.
- Window Manager (Win...() is still 16bit).
- GPI/GRE is currently 16bit, but will be 32bit 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.

32bit 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.

16bit 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 16bit 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 32bit 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: 1) 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:. 2) 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 32bit 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 coverted
it to 32bit, 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 IBMs 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 IBMs 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 32bit
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/3comm'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 mutli-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, netbois 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 Microchanel 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).

Novel 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
Novel 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 16bit 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.


--- Maximus-CBCS v1.02-OS/2-R5
* Origin: Fellow with closed mind often has open mouth. (1:250/628.1)


--
Conrad Bullock | Domain: con...@comp.vuw.ac.nz
Victoria University of Wellington, | or: con...@cavebbs.gen.nz
New Zealand. | Fidonet: 3:771/130
| BBS: The Cave BBS +64 4 643429

0 new messages