Subj : Family executables again
To : Jonathan de Boyne Pollard
From : Mike Luther
Date : Sun Oct 28 2001 04:11 am
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)