Hi Mike,

Replying to a message of Mike Luther to All:

A friend of mine intensively involved in network support for the
WIN-NT world tonight told me a fascinating tidbit.

He said that after close consultation (but not with whom!) they
removed I think he said four files from all their WIN-NT operations:

OS2.EXE
OS2.DLL
POSIX.EXE
(?) one more

PINBALL.SYS perhaps? That's the HPFS driver for NT.

Their reasoning was that in the early days of WIN-NT, any program
which was strictly a POSIX compliant code operation that originated
in OS/2,could, for example be run with OS2.EXE and the corresponding
.DLL!

Not quite.

All 16-bit OS/2 programs could be run natively under NT, as 16-bit, protected mode NT *IS* 16-bit OS/2. There were even DLLs to support 16-bit Presentation Manager under NT doing the rounds, circa 1993.

Their security analysis of the threat of OS/2 to them was so
great for simplistic programs which could be uploaded to them which
might be run under OS/2 shim in this way that it was un-acceptable!

How many 16-bit, protected mode OS/2 programs were they expecting?

The most widespread 16-bit OS/2 programs were: MS Word for OS/2; MS Excel for OS/2; and DeScribe.

The first 2 were never upgraded to 32-bit, but were canned by Microsplat, and the last was upgraded about 7 or 8 years ago. So these 16-bit programs have been long extinct.

The attack of the killer tomatoes would be more of a threat to their network than the attack of the 16-bit, protected mode OS/2 programs.

Similarly, the UNIX game was also something they had to absolutely
block as they had no way of policing or working to figure out what
someone else had done if these other systems' programs could be
executed on their networks.

Most importantly, that could be done from outside the WIN-NT network through this tactic from an outside connectee across the Internet!

No, the OS/2 programs have to be run from an NT shell: CMD.EXE; PROGMAN.EXE; or
EXPLORE.EXE. There was never any RPC [Remote Procedure Call] support for OS/2 executables under NT, AFAIAA.

I'm supposing that in this case, we are still talking about the
WIN2000/NT use of a default NetBIOS over TCPIP and blanket rights
which, I think I understand now exist courtesy of the Nimda.A
learning experience ...

That's simply a security hole in the NetBIOS shares set-up.

Is this a similar scenario, to what we know, as the early WIN-95
programs which will run under OS/2 vis the WIN32S.DLL if they do not require, for example, past version 1.25 of it?

Not really.

Under OS/2, Win32s programs need to be run in a WIN-OS/2 session. This means that a Win16 shell [typically PROGMAN.EXE or WINFILE.EXE] must already be running, or a WPS "program reference object" must be created to initiate WIN-OS/2. Neither of these is performed by Nimda, because it isn't coded for OS/2. [Yes, I know 4OS2 can start Win16 programs automatically, but Win32s programs are linked as PE, not NE, load modules.]

The only way you'll get a Nimda infection on an OS/2 machine is if you have an infected Win32 machine owning filesystem shares with write permissions to your OS/2 box.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

OK Dave ..

Under OS/2, Win32s programs need to be run in a WIN-OS/2 session. This means that a Win16 shell [typically PROGMAN.EXE or
WINFILE.EXE] must already be running, or a WPS
"program reference object" must be created to
initiate WIN-OS/2. Neither of these is performed by
Nimda, because it isn't coded for OS/2. [Yes, I know
4OS2 can start Win16 programs automatically, but
Win32s programs are linked as PE, not NE, load
modules.]

I've now made thta mental connection. I use almost no WIN programs at all,thus
don't thing about all this until prompted... (!)

The only way you'll get a Nimda infection on an OS/2
machine is if you have an infected Win32 machine
owning filesystem shares with write permissions to
your OS/2 box.

Oh that's true enough. But family executables could be written between WIN and
OS/2 if one worked hard enough at it. Coding Raiders of the Lost Vark would be
a larger job, sure. But coding a small bit of code as family wouldn't be quite
so much of a pigglet, one would think. Look at AEDIT, for example.

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001



--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Mike Luther wrote to David Noon <=-

Oh that's true enough. But family executables could be written between WIN and OS/2 if one worked hard enough at it. Coding Raiders
of the Lost Vark would be a larger job, sure. But coding a
small bit of code as family wouldn't be quite so much of a
pigglet, one would think. Look at AEDIT, for example.

Hi Mike,

The only true "family executables" are those between 16-bit DOS and 16-bit OS/2. Editors such as AEDIT and X/2 are good examples of these. [I am using
X/2 to edit this reply. It also runs just fine under DOS real-mode, or in
a VDM or VMB session of OS/2.]

Melding OS/2 and Windows executables is seriously tough. This is because neither uses the MZ header, which is how the DOS program shoehorns its way
in. The MZ header nominally introduces the stub module.

An OS/2 executable that has not been LXLITEd, or such, has a MZ header and
DOS stub module, followed by either a NE header (for 16-bit) or LX header
(for 32-bit), which introduces the protected mode code.

A Windows executable also has a MZ header and DOS stub module, followed
by either a NE header (for Win16) or PE header (for Win32 /API du jour/).
There is no room for another header, either NE or LX.

The inescapable conclusion is that Windows and OS/2 are mutually exclusive options when building an executable, even if they share source code.

Regards

Dave
<Team PL/I>

... Despite the high cost of living, it remains popular.
___ MultiMail/OS/2 v0.40

--- Maximus/2 2.02
* Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)

OK Dave ..

The inescapable conclusion is that Windows and OS/2
are mutually exclusive
options when building an executable, even if they share source code.

learning more here..

Thanks ...

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001



--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Greetings David!

Wednesday October 24 2001 22:54, Mike Luther wrote to David Noon:

learning more here..

That makes two of us. :-)

-Don



... PERL: Puny, Erroneous, Rubbish Language
---
* Origin: EI/2 [Carleton Place, Ontario, Canada] (1:249/176)

OS2.EXE
OS2.DLL
POSIX.EXE
(?) one more

PINBALL.SYS perhaps? That's the HPFS driver for NT.

It is more likely to have been PSXSS.EXE.

They are still idiots.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

He said that after close consultation (but not with whom!) they
removed I think he said four files from all their WIN-NT operations:

OS2.EXE
OS2.DLL
POSIX.EXE
(?) one more

Their reasoning was that in the early days of WIN-NT, any program
which was strictly a POSIX compliant code operation that originated
in OS/2,could, for example be run with OS2.EXE and the corresponding
.DLL! Their security analysis of the threat of OS/2 to them was so
great for simplistic programs which could be uploaded to them which
might be run under OS/2 shim in this way that it was un-acceptable!

They were idiots, with no clue about proper threat assessment. If that was a verbatim report of their rationale, they were also idiots with no clue about what the OS/2 and POSIX subsystems are, and how they do not relate to each other in the slightest.

Is this a similar scenario, to what we know, as the early WIN-95
programs which will run under OS/2 vis the WIN32S.DLL if they do not require, for example, past version 1.25 of it?

At one level of abstraction: yes.

OS2.EXE and OS2.DLL facilitate running 16-bit OS/2 programs (/i.e./ programs written to run on Microsoft OS/2 version 1.x) on Windows NT. There are a whole
load of things that such programs cannot do because the "OS/2 subsystem" in Windows NT does not support doing them, however. Several system API function calls simply return errors to the calling program. There is also no support included in Windows NT for 16-bit OS/2 programs that use (16-bit) Presentation Manager. Only textual 16-bit OS/2 programs are supported. There were, supposedly, aftermarket products from other companies that provided 16-bit Presentation Manager.

32-bit OS/2 programs, of any sort (graphical or textual), have *never* been supported by any version of Windows NT.

The "POSIX subsystem" is for support of POSIX programs. However, this does *not* provide the ability to take binaries from Unix systems and run them directly on Windows NT. This provides *source-level* POSIX compatibility. To run a POSIX program on Windows NT, one takes the source of the program and compiles it with Microsoft's C/C++ compiler, using a special set of headers, libraries, and compiler and linker switches, to generate a PE format executable
that classifies itself as a "POSIX" program (rather than a Win32 program).

The primary /raison d'être/ of the "POSIX subsystem" in Windows NT was marketing. It allowed Windows NT to meet the requirements imposed by various U.S. Government procurement regulations, which specified POSIX compatibility.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

All 16-bit OS/2 programs could be run natively under NT, as 16-bit, protected mode NT *IS* 16-bit OS/2.

Er, no. 16-bit NT isn't 16-bit OS/2.

There isn't really such a thing as 16-bit Windows NT /per se/. 16-bit OS/2 programs are run as co-routines within OS2.EXE processes. The "OS/2 subsystem"
maintains enough of an environment to load and to run 16-bit protected mode code as co-routines, and translates all calls to 16-bit OS/2 system API services (those services that are implemented, that is) to calls to underlying Win32 and native NT system APIs.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

Yes Johnathan!

JdBP> They were idiots, with no clue about proper threat
JdBP> assessment. If that was a verbatim report of their
JdBP> rationale, they were also idiots with no clue about
JdBP> what the OS/2 and POSIX subsystems are, and how they
JdBP> do not relate to each other in the slightest.

verbatim.

I found it curiously inconsistent too, but I have very little undersstanding of
all this. All I keep tyring to do is to learn more and more..

JdBP> At one level of abstraction: yes.

I was postulating it as a possible virus cross-platform mechanism.

JdBP> Only textual 16-bit OS/2 programs are
JdBP> supported. There were, supposedly, aftermarket
JdBP> products from other companies that provided 16-bit
JdBP> Presentation Manager.

Which certainly wouldn't be targeted, I would speculate, on the PM level.

JdBP> 32-bit OS/2 programs, of any sort (graphical or
JdBP> textual), have *never* been supported by any version
JdBP> of Windows NT.

I knew that.

JdBP> The "POSIX subsystem" is for support of POSIX programs. However, this
JdBP> does *not* provide the ability to take binaries from
JdBP> Unix systems and run them directly on Windows NT.
JdBP> This provides *source-level* POSIX compatibility.
JdBP> To run a POSIX program on Windows NT, one takes the
JdBP> source of the program and compiles it with
JdBP> Microsoft's C/C++ compiler, using a special set of
JdBP> headers, libraries, and compiler and linker
JdBP> switches, to generate a PE format executable that
JdBP> classifies itself as a "POSIX" program (rather than
JdBP> a Win32 program).

OK.

JdBP> The primary /raison d'etre/ of the "POSIX subsystem"
JdBP> in Windows NT was marketing. It allowed Windows NT
JdBP> to meet the requirements imposed by various U.S.
JdBP> Government procurement regulations, which specified
JdBP> POSIX compatibility.

That's what I faintly thought I understood. But I couldn't figure out why they
were so aggressively banishing 'dis and 'dat, unless it was in an effort to remove a virus entrancy point which could come in a new way via the above thinking..

Am I right to think that one could actually write a cross-platform simplisitic routine that had no screen I/O out of such a technique, or am I not correct, in
your opinion?

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Hi Jonathan,

Replying to a message of Jonathan de Boyne Pollard to David Noon:

All 16-bit OS/2 programs could be run natively under NT, as 16-bit,
protected mode NT *IS* 16-bit OS/2.

JdBP> Er, no. 16-bit NT isn't 16-bit OS/2.

JdBP> There isn't really such a thing as 16-bit Windows NT /per se/.

We are splitting semantic hairs here.

When Microsplat released NT 3.1 they offered a raft of software products available as proof that NT was the way of the future. Most of these products MS's own 16-bit OS/2 products: Word; Excel; MASM 5.x/6.0; C/C++ 5.x/6.x/7.0; FORTRAN 77; COBOL; etc. There were even DLL's for NT to support 16-bit PM available on MS's ftp servers around 1994 -- probably until MS Office 95 came out. So, it is really MS's nomenclature that these are 16-bit NT products, when
we all know that they are 16-bit OS/2 software.

However, it is true that there was never a 16-bit API for NT.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)