Subj : Translating Case From Ba
To : Murray Lesser
From : Mike Luther
Date : Sat Feb 17 2001 12:35 am
Smiling here, Murray..
ML> Due to the coincidental initials, I have transliterated the code
ML> that identifies things of mine that you quoted in yours, to "ml."
we'll get to see a proper caste relationship this time!:
ML> Murray Lesser
ml> Mike Luther
grin.
ML> ... Once, I rewrote one of
ML> my DOS compiled BASIC utilities in C; both the new source code and the
ML> executable code files turned out be be about double the size of their
ML> BASIC equivalents, which taught me that C was a lousy language for
ML> data-processing applications. When C++ came along, I read a couple of
ML> books about it and decided that it was not for me.
It really becomes attention grabbing when a translator goes to work. With no
offense to our Spanish culture friends, it's much like comparing romance to
technology in language use. 'Cuidado con el serpeinte de hiero que marcha en
frente del aeropuerto senor.' By then the pilote has hit the train.
ML> Gates bought the origin of MDOS from a Seattle outfit called Seattle
ML> Computer Products. It was a 16-bit port from Digital Research's 8-bit
ML> CP/M. Letwin glides gracefully around this fact in his book on OS/2. Do
ML> not believe much, if any, of the Microsoft propaganda about "Microsoft
ML> Innovations!"
I said that wrong. Gordon wrote HDOS. Once I'd posted, I went back and read
it again .. discovered I'd used MDOS or whatever instead of HDOS.
ML> The Forward to Gordon Letwin's "Inside OS/2" (ISBN 1-55615-112-9),
ML> signed by Bill gates, carefully states that Letwin was "Microsoft's
ML> architect for OS/2." The only place in that book that says that IBM
ML> personnel contributed to the design (architecture) of the product is in
ML> the Introduction. In spite of what you may have heard, or understood
ML> from what you read in that book, Microsoft did not write OS/2 1.0 all by
ML> itself. After MS picked up its marbles and left the game, IBM wrote
ML> OS/2 1.3, and all following versions, without any help from Microsoft.
ML> (Next time you boot Warp 4, note that "OS/2" is a registered IBM
ML> trademark!)
Thinking about what I've thought about it all, I now realize that all along
I've really understood Microsoft wasn't the soul (sic intended!) source for
OS/2. However, since I am too young to know the animosity on a more personally
educated basis, I never really focused on the above, until I read your post.
Of all honor tarnishment, I suspect intellectual dishonesty is, perhaps the
worst. The distinguishing facet which establishes the human animal at the top
of the chain is reasoning and emotional connections to that; it's the reason
for my opinion.
I'll amend my comments about Gordon and OS/2 suitably in the future.
ML> I don't want to denigrate Letwin's contributions. After all, the
ML> patent for HPFS was issued to Letwin and assigned to Microsoft. (It is
ML> too bad that Microsoft has abandoned it for its own products.)
Obviously .. perhaps Gates was just being too forward in that forward.
Of 'original sin', chuckle,
ML> .. supported by OS/2 for "system integrity" reasons. You can find out
ML> which DOS constructs are not supported in an OS/2 VDM if you can find a
ML> copy of the out-of-print "OS/2 2.0 Technical Library" manual
ML> "Application Design Guide" (IBM p/n 10G6260).
foggy memory says they might also be documented in the printed books for the
PD7 compiler. Note the below is more appropriate syntax!:
ml> Because of the way that PDS 7.1 was written to integrate the
ml> assembler operations for the HEX21 interrupt work so well into
ml> BASIC, we got two very,very important things cross-referenced to
ml> both OS/2 and DOS!...
ML> One could "integrate" assembly-language subroutines into programs
ML> written in the original MS BASIC compiler for CP/M, by linking them as
ML> called subroutines.
Sorry, Mikey is too young.
ML> Similarly, you could link assembled subroutines
ML> calling INT 21h functions in the first MS compiler for DOS. (To my
ML> knowledge, the later "MS Business BASIC" was the first MS BASIC compiler
ML> that let you call separately-compiled, as well as assembled, procedures,
ML> as either functions or subroutines.)
Ah so. So corrected here... ;)
But, OPEN ... for SHARED .. plus PUT and GET are easier, if they do the
necessary things you'd have to code in assembler, than without them. In looking
at the assembler stuff, it just seemed obvious how the compiler got written,
that's all.
ML> You are too young :-).
Already admitted. Also, correctly analyzed by my Dad, may he rest in peace;
too lazy and stubborn. ""But I don't WANT to do it that way.""
ML> .. Variable-length string arrays were available
ML> in CP/M BASCOM 7, as was built-in garbage collection. PL/I (and a few
ML> other languages other than C) also provide for variable-length strings,
ML> although you may have to specify the _longest_ string length you expect
ML> to see.
Does PL/I have automatic garbage collection? Is the fact that you don't
consider PL/I to be a "modern" language, the reason you didn't include it?
M> The only "modern" language (other than BASIC) I know of that
ML> provides for automatic garbage collection is Java.
After being forced to take out the trash, and recalling all the bandwidth I've
seen consumed discussing it in C discussions, life seems just simpler with a
Data Disposal in the programmer's workbench! (Bad pun but whatever!)
I'm studying Java trying to make sense of all this. I wasn't pleased at the
recent Microsoft - Sun settlement. It seemed to forecast yet another
fractionated toolset, another log thrown in the road. Just more embrace,
embellish and exclude for us poor OS/2 folks.
ml> Can REXX, for example, and PL/1, in one easy common source
ml> code caper,provide me with full support for OS/2, WIN-ugh,
ml> and DOS, for these?
ML> Of course not. There is no such thing as true cross-platform
ML> compatibility at the source-code level unless the language is simple
ML> enough to not call on any operating system (or hardware) constructs that
ML> are not available in all of the platforms under consideration, and
ML> unless all the platforms use the same word length for arithmetic
ML> operations.
Of course yes. I look at the issue of threading and DOS as probably the worst
problem in going forward in OS/2 and so on, yet having to provide back-support
DOS. There is no way to support it, that I can see, except for writing
separate executables called in separate sessions, which pass data as disk
related data, and include privately constructed semaphores to provide for
proper synchronization of the disk data. Fortunately, what's currently of
major importance to what I want, is pretty much sequential in nature - not
speaking of the file operations, but pure logic ..
ML> You probably don't remember the anguish expressed by some
ML> users when they learned that their Fortran programs, when run on the new
ML> 32-bit (numeric word length) System/360 machines, produced different
ML> results from when they had been run on the 36-bit 700/7000 series
ML> machines. (This is largely a result of doing arithmetic in floating
ML> point.) If you want more-or-less cross-platform capability, write
ML> your application in Java. If you want arithmetic operations to be
ML> independent of hardware word length, use REXX. Otherwise, you are on
ML> your own.
I don't know that specific illustrative example. I am familiar with more
recent similar incidents. Appropriate parallel understanding comes from what
was told me to be the key issue in focusing the current FDA thinking on medical
device licensing by Dr. Tom Shoppe. I think that name spelling is correct.
He noted FDA didn't really think about what really had to be addressed for pure
computer system use in medicine until the fatal accident cluster up in Tyler,
Texas. A dosage calculation program for figuring out radiation levels needed
for cyclotron treatment of cancer patients was coded for use with a numeric
co-processor. Run on a box without one, the resulting errors in the math
produced and overdose script which killed a number of patients. Obviously
that's not exactly the same thing as the above differences, but perhaps it even
more sharply illustrates why I'm both concerned about all this, and at the same
time, torn about where to go in going forward to the next step.
The application here is used, among other test-bed scenarios, in medical
environments. If I get trapped in the business of licensing anything as a
medical device, we'll have to not only proof each line of source, but also the
full operating system down to the CPU level, so told me. From what I've been
told, I see a very dark cloud still waiting for a number of folks writing
toward medical use. I think they may be vastly under-estimating the real
down-the-road intent to force the AMC-X12 new Federal transmission and
communications standard, PKI, into what you will and will not be allowed to
code as functional for such use.
You are far better at all this than Mikey. But I don't think you would argue
that if we *HAD* to stand on operating system certification, we sure could do
it with OS/2. We'd, I think, never be able to certify on the basis of actual
LINUX, since an open source compile operation would likely never be issued that
approval. Nor would we ever be able to certify on the basis of a Microsoft
platform. Heck, you'd never be able to get the code past everyone in the
certification game before it all changed and everything had to start all over!
But maybe I'm mis-thinking all this..
To corrupt Gamov ... 2001, 2002, 2003, 200oo .. ?
I've never been there, but I think it would be a priceless experience to be
able to take the 45 minutes that Einstein took to climb the spire at Ulm, look
out, as he did to survey all he saw of dimensions, and look over it not only in
that sense but with the language and experiece in dimensions of hardware
interfacing that you have seen.
Mike @ 117/3001
--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)
