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