kbad@atari.UUCP (Ken Badertscher) (08/18/88)
in article <8143@cup.portal.com>, Jinfu@cup.portal.com says: > > I have an idea, why not provide both 'fixed' Malloc and the > old Malloc ... provided the new TOS ROM has enough space to put > both versions of Malloc in. > > Jinfu Chen Jinfu has hit the nail squarely on the head. There isn't enough room for both versions of Malloc in the ROMs unfortunately. Believe me, folks, these ROMs are packed full o' goodies. The french ROM, for example, has less than 100 bytes free! (sizes vary because of differing desktop and AES resources) I also wanted to mention that I have really enjoyed the discussions on the net of late regarding why or why not to break old software. A special thanks for letting me read the newsgroup without having to put in eye drops to soothe eyes burning from the flames! I personally am more of a TOS "purist" -- I want to see things fixed. Momma taught me: "If it ain't worth doing right, it ain't worth doing at all." Unfortunately, with a consumer product like the ST, things aren't so black and white. Compatibility is a *major* concern for most end users, so it must be a concern for us. There's no easy answer. But the views of all of you in net-land really do help. -- Ken Badertscher | Hey, umm, the stuff I said up there Atari R&D Software Test/Support | is, like, what _I_ think, okay? {portal,ames,imagen}!atari!kbad | So, y'know, don't bug Atari about it.
gaz@apollo.COM (Gary Zaidenweber) (08/22/88)
From article <1123@atari.UUCP>, by kbad@atari.UUCP (Ken Badertscher): > Jinfu has hit the nail squarely on the head. There isn't enough > room for both versions of Malloc in the ROMs unfortunately. Believe me, > folks, these ROMs are packed full o' goodies. The french ROM, for example, > has less than 100 bytes free! (sizes vary because of differing desktop and > AES resources) Ken, I'm really with you--anything worth doing is worth doing right. Unfortunately, "right" is subjective. In my opinion, fixing broken code is the most "right" thing to do in this case. The next most right thing to do is maintaining backward compatibility (hey, I develop and support software for a living, too!) Further down the list of "right" things to do is adding new features. We all love them but making (and keeping) programs working is more important--features can be added by giving coding examples in books and on disk. This is my opinion, I hope you and the management at Atari will agree. -- UUCP: ...{umix,mit-eddie,uw-beaver}!apollo!gaz ARPA: gaz@apollo.COM AT&T: (508)256-6600 x6081 Its never too late to have a happy childhood!
gert@nikhefh.hep.nl (Gert Poletiek) (08/23/88)
In article <1123@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: >in article <8143@cup.portal.com>, Jinfu@cup.portal.com says: >> >> I have an idea, why not provide both 'fixed' Malloc and the >> old Malloc ... provided the new TOS ROM has enough space to put >> both versions of Malloc in. >> >> Jinfu Chen > > Jinfu has hit the nail squarely on the head. There isn't enough >room for both versions of Malloc in the ROMs unfortunately. Believe me, >folks, these ROMs are packed full o' goodies. The french ROM, for example, >has less than 100 bytes free! (sizes vary because of differing desktop and >AES resources) > > I also wanted to mention that I have really enjoyed the discussions on >the net of late regarding why or why not to break old software. A special >thanks for letting me read the newsgroup without having to put in eye drops >to soothe eyes burning from the flames! > I personally am more of a TOS "purist" -- I want to see things >fixed. Momma taught me: "If it ain't worth doing right, it ain't worth >doing at all." Unfortunately, with a consumer product like the ST, things >aren't so black and white. Compatibility is a *major* concern for most >end users, so it must be a concern for us. There's no easy answer. > But the views of all of you in net-land really do help. >-- > Ken Badertscher | Hey, umm, the stuff I said up there > Atari R&D Software Test/Support | is, like, what _I_ think, okay? > {portal,ames,imagen}!atari!kbad | So, y'know, don't bug Atari about it. Now if you need more room in the ROMs how about this: - Kick the desktop and AES resources out of the rom - same goes for the bios keyboard translation tables - Even kick out the desktop program itself. And supply these on disk, to be read at boot time. What you gain is substantial (I think): 1. Lots of valuable ROM space, which can subsequently be used for a real part of the OS. (And a user interface is NOT part of an OS). 2. You don't need different ROMS for different countries. This will yield a substantial costs cut. 3. The desktop resources can be modified to everybodies liking 4. And it provides a way to easily upgrade the desktop. (or users can even directly replace it with a command line shell, if they like that better) I'm sure everybody can think of additional advantages... Gert Poletiek NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet From september 1st 1988: Gert Poletiek Dept. of Math. and Computing Science, University of Amsterdam, Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!uva!gert bitnet: uva!gert@mcvax.bitnet, U00025@hasara5.bitnet
maverick@cl2devy.SGI.COM (Steve Whitney) (08/24/88)
In article <527@nikhefh.hep.nl>, gert@nikhefh.hep.nl (Gert Poletiek) writes: > > Now if you need more room in the ROMs how about this: > > - Kick the desktop and AES resources out of the rom > - same goes for the bios keyboard translation tables > - Even kick out the desktop program itself. > And supply these on disk, to be read at boot time. > This is a _great_ idea! Then puntaes would work again too. There would be lots of room in the ROMS for OS and you could put GDOS right in the AES. Have you thought about this, Atari? --Steve - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steve Whitney ARPAnet: maverick@portia.stanford.edu UUCP: ..!decwrl!portia.stanford.edu!maverick No room for a quote Bitnet: maverick%portia.stanford.edu@stanford GEnie: S.WHITNEY
ripley@netmbx.UUCP (Hans-Ch. Eckert) (08/25/88)
In article <527@nikhefh.hep.nl> gert@nikhefh.hep.nl (Gert Poletiek) writes:
=>Now if you need more room in the ROMs how about this:
=>
=>- Kick the desktop and AES resources out of the rom
=>- same goes for the bios keyboard translation tables
=>- Even kick out the desktop program itself.
=>And supply these on disk, to be read at boot time.
=>
=>3. The desktop resources can be modified to everybodies liking
=>
=>4. And it provides a way to easily upgrade the desktop.
=> (or users can even directly replace it with a command line shell, if they
=> like that better)
=>
=>I'm sure everybody can think of additional advantages...
=>
=>
=>Gert Poletiek
Probably, it'll be enuf to push all Resource-Code from the Desktop out onto
Disk (perhaps DESKTOP.RSC) and loaded at boottime.
I DISLIKE the PC/GEM-behaviour of loading DESKTOP.APP every time after a
program has finished and am glad not to have to wait until the desktop is
active again after a ST-program terminates !
Having the possibility of patching the desktops' resources makes the machine
more personally, I suppose (Just like Icon-Patchers, DESKEDIT.ACC e.g. :-)
--
== Greetings from : == Hans-Ch.Eckert, Regensburger Str. 2 ==
== *** ripley@netmbx.UUCP *** == 1000 Berlin 30 [Tel: 030/246292] ==
==============================================================================
== Superkalifragilistikexpialigetisch ! (Mary P.) ==uace0@uhnix2.uh.edu (Michael B. Vederman) (08/25/88)
Atari:
Just how many Mallocs could one expect to have before running out of
the static area where the block descriptors are? And can they be freed in any
order.
I know it will be hard to say how many blocks for sure (depends on
disk drives connected and folders I'm sure), but give us some scenarios,
could you?
- mike
--
for (;;) : Use ATARINET, send an interactive
do_it(c_programmers); : message such as:
: Tell UH-INFO at UHUPVM1 ATARINET HELP
University Atari Computer Enthusiasts : University of Houston UACE