Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.programmer Subject: Re: Short Hello World Message-ID: Date: 17 May 91 19:40:38 GMT References: Sender: news@pa.dec.com (News) Followup-To: comp.sys.amiga.programmer Organization: Missionaria Phonibalonica Lines: 90 In-Reply-To: jsmoller@jsmami.UUCP's message of 16 May 91 23:50:49 GMT In article jsmoller@jsmami.UUCP (Jesper Steen Moller) writes: > Nope, we're not joking. With 2.0, there are lots of replacements for > "old" library entries, and CBM is universally telling people not to > use the old version of the call. I don't think CBM would remove OldOpenLibrary, as programs written for pre-1.2 should continue to work without recompilation if properly designed. Also, as OldOpenLibrary is in the very middle of the exec.library vector table (6 bytes) and probable does: moveq.l #$00,D0 JMP _LVOOpenLibrary(A6) it would be plain silly to remove it - they could win only 6 bytes... No, it's _not_ just six bytes. It's ~six bytes for _every_ backwards compatable function. There's also all the code spent on supporting various hacks. There's various things that support BCPL. Any piece of it may be small, and can be justified just like the above. Taken as a whole, it's _not_ small. Pulling any of it will break old code; pulling all but OldOpenLibrary will probably break nearly everything. Why leave in OldOpenLibrary for the small percentage that don't break because of some of the other things? I think deleting or changing functions radically like above is rude and in conflict with the original design. Rude? Yes - but it's not as rude as not doing OS updates because you can't break old programs. In conflict with the original design? Immaterial. There's a new design, and the people who control the code think it's better (I agree, but that's also immaterial). If you like the old design better than the new one, don't run the new version of the OS. That way, _nothing_ breaks. > That kind of software is > either 1) run by someone who's not fallen for the "have to have the > latest and greatest" trap, and so probably won't upgrade their OS, or > 2) been orphaned for at least five years. The latter is part of life. Or 3) run by someone who written something really great but somehow deleted the source and forgot the hexadecimal values of the 680x0 instructions (I still what the 6510 opcode $A2 was used for...) That's orphaned code. Orphaned code is code with nobody who's willing to fix bugs or make enhancements, and that's what you've just described. In article <1991May16.042906.4763@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: So should we expect to recompile our code every 5 years?! Because CBM will remove some function we used and dont support anymore! No, you don't have to recompile your code every 5 years. You can always opt not to upgrade to the new OS. Of course, for anything non-trivial, some time during that five years you should have changed the code to take advantage of the features of the new OS. Me, I recompile with new compiler releases (unless it's in assembler, of course), or when I upgrade processors (Hmm - I guess if you code in largely in assembler, that doesn't win anything without a rewrite anyway...). And the size 'excuse' is pretty funny when you think the major part of what is in ROM is written in C. Yeah - we've just seen it demonstrated that the obvious C code is less than 10% larger than hand-tweaked assembler code (check out the first few notes under this subject) that provides the same functionality, and _much_ smaller than untweaked-assembler. I guess CBM should spend all their time tweaking assembler to make it smaller rather than fixing bugs... BTW, one of my critical applications is an orphan. If it hadn't run under 2.0, I would have lost. If CBM breaks OldOpenLibrary, I may lose (given the code quality, I probably don't, but I should check that). And I'll still be plugging for OldOpenLibrary to go away. If OpenScreen and OpenWindow go away, I'll lose. I'll still be pushing for CBM to do that. I expect that all the people who've been crying for demand paging or resource tracking or a protected environment will also be doing so. Those broken eggs are the cost of the omelette they want.