Re: On-line Review of "Art of Assembly"

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 01/17/04 

Date: Sat, 17 Jan 2004 06:35:13 -0000

JGCasey wrote:
> Beth wrote:
> Great read Beth. I only vaguely knew some of the stuff you cover.
> Have you ever thought of writing for computer magazines?

You know, I might have written something for that "ASM Programming
Journal" but it seems to have stopped or something...

> But I still don't understand why some brilliant group of programmers
> can't write a program that can translate programs written for M$ to
> work with another PC OS, including the hardware drivers? Can't
> software be written to behave like M$ from the point of view of
> hardware drivers?

Yes and no; Under Linux, there's "Wine" which "emulates" DOS / Windows
(as best as it can :) so that this stuff can be run on Linux...under
Windows, you can use "CygWin" where the Linux kernel has been written
as a Windows DLL and, therefore, you can compile your Linux
applications (luckily, most come with source code ;) as PE files
against the CygWin DLL (some "tweaking" may be necessary :) and then
use them under Windows...

But these are _large_ projects and they never can claim a 100% success
rate...plus, these things simply _run far slower_ in most
cases...that's because the application uses the "virtual OS" and then
those calls have to be "intercepted" and "translated" over into
appropriate calls for the native OS...and, well, that requires
_time_...and it's not a particularly easy thing to do...for example,
with that CygWin DLL, it simply provides the Linux kernel _C_
functions as "exports"...if a program is using the lower-level "INT
80h" interface then there's going to be problems...if the program
depends on "side effects" then the emulator needs to match those up
perfectly...if the program tries to do "something clever" and directly
access a certain memory location or something else "non-standard" (but
which actually works in practice on the "real thing"), then this is
particularly difficult to manage...

Doing it more direct, we have the ReactOS project, which is attempting
to clone NT as close as possible so that the MS stuff works directly
with it...of course, that'll mean that ReactOS will basically _be_
practically identical to NT that, other than being free, what's the
difference between this and the real thing?

And none of these projects are particularly easy...remember, though
Microsoft are lazy sods at times, Windows has been _decades_ in
development and, despite some of the "hype" making you think that they
re-write it from scratch every single time, they don't and it's the
_accumulation_ of decades of development...

Plus, on this score, stop to think about _why_ Microsoft insist on
literally tens of thousands of API? Yes, tens of thousands of API
calls to "emulate"...and they keep throwing out new ones and changing
over to COM then .NET then...then...they have the advantage of being
at the front of this race, where everyone else must "catch up"...so,
they simply just "tread water" slightly ahead of everyone else all the
time - nice and easy for them to do - while everyone else is tearing
their hair trying to copy it or emulate it or whatever...and, by the
time they've reached that goal? Well, ReactOS was to emulate
_NT_...there's 2K, there's XP...they've not got NT yet...by the time
they get there, we'll all probably have XP2...by the time they reach
2K, Microsoft will have "XP3.NET" which has had radical changes added
(delibrately to piss off the ReactOS people while their lawyers
scramble to sue it out of existence or whatever is available to
them)...by the time they catch up with that, Microsoft - fearing the
"threat" - has signed special "deals" with hardware manufacturers to
use special "security encrypted" drivers...MS's claim being that this
is for "security" but, really, it's done delibrately so that no-one
can follow them...you can't ask hardware manufacturers what the "keys"
are because "for security reasons" these are not given out to anyone
but MS and their own employees...

Always three steps behind whatever they do, always playing "catch
up"...and in this game of "Simon says", Simon can say "using millions
of dollars forge exclusive deals with hardware manufacturers for total
obedience"...oops, that's one thing Simon says that _can't_ be copied
by definition...this is why I tend to think that the "imitating" idea
is ultimately doomed...you can have "fun" scaring Microsoft, perhaps,
but then the better you do at that, the more likely Microsoft are to
"clam up" in reaction and use non-copyable means...

Like, for instance, the Linux people actually have major "issues"
regarding DVD players...the problem is that stupid "regions"
nonsense...Linux is "OpenSource" so whatever encoding / decoding
algorithm is used for each "region", it could be read straight out of
the source code...but that, of course, ruins "regions" as a
"protection" so the DVD people say: "No way, hose!"...I read some
really interesting "open letters" about this where the Linux people
worked on making the case that the entire "regions" concept of
"protection" was totally flawed from beginning to end and only hurt
_legitimate consumers_, anyway...it's a very good read and makes the
"no such thing as an uncrackable safe" points very, very
well...professional pirates will break through any new protections in
days and then simply disable them (or "convert" something from one
region to another so the "protection" ends up being
pointless)...Windows "activiation" was apparently cracked within a day
or two of release...all that fuss and for only about 48 hours was
Windows actually "protected" from piracy...what was the bloody point
in even trying? The professional pirates are called "professional" for
a _reason_...you bring out some "smartcard" and they'll have the thing
reverse engineered in an eyeblink...note, these people aren't poor
because they make _tons_ doing this so they _can_ afford to match up
technologically with anything the big companies
"mass-produce"...literally taking chips apart _physically_, if needs
be...and the argument here, of course, is that if this stuff doesn't
stop professional pirates at all (and "casual pirates" can get the
professional's "cracked" version without protections and simply copy
it) then all it actually does, in the end, is really piss off someone
who buys a DVD on vacation in Japan and then realises that it won't
work on their machine at home...of course, most people would just
learn to avoid buying those DVDs and, oh dear, this thing that's meant
to "protect sales" has just lost them masses and masses of legitimate
sales...and they can stick "digital rights" on whatever they like but
what'll happen is that someone will connect the speaker socket to a
microphone socket and press "play" on one and "record" on the other,
then convert it to MP3 and stick it up on one of the hundreds of file
share programs out there (which are peer-to-peer and there's literally
hundreds of these things...and when they close Napster, everyone goes
over to Morpheus and when they close that they go to...and then they
go to...remember what I was saying about everyone being "one step
behind" Microsoft? Well, the shoe is on the other foot for the music
people with their attempts to bring things down via the law
courts...it's way too slow...they are, in fact, simply attempting to
"scare" people with the possibility and Hoping that's good
enough...but, of course, we all know that it won't be...Napster's
users were in the _millions_ at its peak, after all)...

Anyway, back to the main point...emulating is hard and isn't good
enough, copying is hard and doomed if those you're copying decide to
get "awkward" (plus, if you manage to copy NT perfectly then, oh, what
you've got is _still_ NT...it's free, true enough, which'll really
piss off Microsoft but it's not "new"...and, in a sense, the hardware
manufacturers are _still_ writing drivers for Windows and Windows -
even if now "FreeWindows" - will still be in control and Microsoft are
still calling the shots...it's like we joke at Rene...as his RosAsm is
for ReactOS and ReactOS copies NT using the PE file format, then
imagine ReactOS succeeds in destroying Microsoft...well, Rene will be
_still_ using _Microsoft's_ PE file format...he'll be keeping it alive
as some sort of "detached zombie"...other people may try to extend it
but, just like Microsoft, they keep the "core" the same for "backwards
compatibility"...you simply change who Microsoft are, so to speak,
they still - even in death - control everything with monopoly...new
Kings, yes, but same old crap Monarchy system ;)...

And writing a "conversion" program is very difficult...in fact, it's
basically reliable disassembly and then re-assembly, so to
speak...like Rene's "two-clicks" ideas but for a much more complicated
procedure of actually _changing_ a fully-functional Windows driver
into a Linux driver...I draw your attention to what Randy says about
the first part of this problem equating to the "halting problem",
which has been _proved_ to be impossible in the general
case...converting the semantics of one API set to equal semantics of a
completely different API set (and memory model to another memory model
and so on and so forth) sounds like a pretty complex AI
problem...although, at least the re-compilation after these two
next-to-impossible things has been done will prove nice and easy...you
can try this and might get some good results with "simple" predictable
programs...but, in general, you can't do it for all possible things
put in front of the "convertor" because that's got both a "halting
problem" _and_ complex expert system AI involved...

It would be easier and quicker to take the Linux approach and simply
write them all one by one from scratch..."diminishing returns", as
they say...Linux does reasonably well at this kind of thing exploiting
the "thousand eyes" that while you're still working ten years from now
on this "can convert anything to anything else" superior AI program,
they'll have hand-coded hundreds and hundreds of drivers from
scratch...

Also, there's the implicit problem...how do you "defeat" Windows by
totally _depending_ on it to exist to have all these drivers for
"conversion"? The "ReactOS paradox", so to speak...in fact, it's this
continual "acceptance" of Windows as "always there" in people's
attitudes and comments which is probably the very thing that's worst
of all...like using war to try to prevent war and then there's a
continual cycle forever of war after war...each one apparently suppose
to "prevent" the last one...

The lasting solution - if there is one - is for everyone to be
_determined_ to strike out alone (Linux-style) and for the hardware
people to come on-side...and that is, unfortunately, the _most
difficult_ thing to achieve: agreement and co-operation...

"Freedom comes when you learn to _LET GO_
Creation comes when you learn to _SAY "NO!"_

Pain is a _warning that something's wrong_...
I pray to God that it won't be long...

Do you want to go higher?"

[ "the Power of Goodbye", Madonna..."Ray of Light" ;) ]

Also, one suspects whether people really, deep down, actually want to
succeed:

"Every artist is a cannibal,
Every poet is a thief...
All _KILL_ their inspiration,
And then sing about the grief!"

[ "The Fly", U2..."Achtung, Baby!" :) ]

> Does this mean that Java can never be platform independent when
> it comes to hardware support?

Java is a virtual machine...its hardware support is "hidden" behind
method calls...this stuff is delibrately "abstracted" out of the
equation in order to get the "portability"...but, at some point, some
piece of code somewhere needs to send specific hardware-dependent
commands to an nVidia card to draw polygons in a certain way...

_UNLESS_ we write Java applications on a Java CPU that uses Java
hardware...but, then, that's just a case of inventing
"standards"...this stuff would then be "incompatible" with anything
else...

The problem is _inherent_...a _physical_, not merely "logical",
problem...if my hardware accepts certain device-dependent commands and
those commands are different to another piece of hardware which uses
different commands, then an application can't just spit out a single
set of commands because the two pieces of hardware work in different
ways...there needs to be some "bridge"...either by "standards" to make
all hardware the same (all VGA cards, for instance, are "compatible"
with each other and so any VGA code posted up here will work without
change on any "100% compatible" VGA card...the problem with
"standards" is that it holds back innovations..."standards" get
decided by committee and committees notoriously choose bloody awful
decisions full of compromise between them)...or by using some "bridge"
between "independent" and "device-dependent", which is the "device
driver", basically (note that the BIOS also acts as such a "bridge"
for things like disk access and these are effectively "device drivers
in ROM"...what would be nice, actually, is if Intel CPUs could finally
make the transition and boot up in protected mode and BIOSes were all
similarly updated to work in protected mode...though there are "memory
model" issues there but some "standard" could be worked out, I'm sure,
like VESA's VBE protected mode interface...now, _that_ would make a
_big difference_ in levelling out the competition...just as anyone can
easily write a "DOS" in real-mode - it's not too difficult as DOS
doesn't do all that much more than provide a file system and then call
through to BIOS calls - then a protected mode boot-up and protected
mode BIOS would go a long way...the problem? "Backwards
compatibility"...an x86 booting up in protected mode and a protected
mode BIOS would be totally incompatible with how things currently
are...it won't happen, unfortunately)...

Beth :)