dougp@sbphy.ucsb.edu (03/03/89)
This one should be easy, I want to see Realloc() implemented in the
exec. This one is so obvious I expect it has already been done, but
then it wasn't done in 1.0, 1.1, or 1.2.
By the way, are these suggestions too late? Has 1.4 been frozen yet?
Douglas Pealejdutka@wpi.wpi.edu (John Dutka) (03/24/89)
How about this for another wish list for 1.4?
1.) Keyboard shortcuts for the Workbench pull-down menu commands.
Personally, this would make MY life much easier (I don't know about
everyone else here on the net...)
2.) The ability to lock hard drives or hard drive partitions/directories
from reading/writing/executing inherent on the INFO screen (pull-down
menu command). After all, we can write protect disks rather easily by
flipping the shutter [except, maybe, for my disk drive (until I can
afford to have it repaired).].
3.) A visual task control program, similar to TaskX.
+--------------------------+----------------------+--------------------------+
| John A. Dutka (jdutka) | . . . .____. . | jdutka@wpi.bitnet |
| Worcester Polytechnic | | | | | | | | jdutka@wpi.wpi.edu |
| WPI Box 2308 | | | | |____| | | |
| 100 Institute Road | | | | | | +--------------------------+
| Worcester, MA 01609-2280 | |__|__| | | | WPI - Home of the |
| (508) 792-1949 | | ever-growing tuition (& |
| U.S.A. | (C) 1989, Chris Moir | Freshman failure rate.) |
+--------------------------+----------------------+--------------------------+dtsteen@dahlia.waterloo.edu (06/01/89)
I'm not sure if this has been hashed out here before, but for 1.4 I would really like to see the stack size which a program requires encoded right in the executable file. I know ARP does this, but unfortunately, a lot of programs don't get launched by ARP. I think the stack size should be encoded in executable files in some reasonably transparent way, and then the loader in ROM (LoadSeg?) should detect it and cause the right amount of stack to be allocated. No more wasted memory because a program which needs 100 bytes of stack got 20K, and no more crashes because of 4K default stacks like mine. Think about it! You could have a HUNK_STACK just like a HUNK_BSS, and the loader could allocate the stack along with the other memory areas. The load could fail if not enough room for the stack was available. Deeply recursive programs could allocate a minimal stack (like 100 bytes) and then set up the stack they really need themselves. No more StackSize entries in Mountlists! And so on. The key is that this should be officially built into the system, not kludged on by a third party. So what is wrong with this picture? I'd like to hear if 1.4 will address this issue, and if not, what I've missed. Markus Wandel (519) 884-9669 Help eliminate space wasting .signat
sparks@corpane.UUCP (John Sparks) (06/02/89)
In article <14218@watdragon.waterloo.edu> dtsteen@dahlia.waterloo.edu writes: >I'm not sure if this has been hashed out here before, but for 1.4 I >would really like to see the stack size which a program requires encoded >right in the executable file. I know ARP does this, but unfortunately, >a lot of programs don't get launched by ARP. > I agree! This would be a great feature. It's very frustrating trying to set the stack just right, so that the program has enough stack without giving it too much so that you don't waste memory. Right now it's just set stack, run program, crash progam, raise stack, run program, .... until the stack is large enough. -- John Sparks | {rutgers|uunet}!ukma!corpane!sparks | D.I.S.K. 24hrs 1200bps [not for RHF] | sparks@corpane.UUCP | 502/968-5401 thru -5406 When everyone is out to get you, Paranoid is just good thinking. --Johnny Fever
MROBINSON@wash-vax.bbn.com (06/05/89)
[dtsteen@dahlia.waterloo.edu wishes that the stack size become part of the executable] Hey, yeah! But this makes me wonder why the people who were bright enough to include shared libraries and a message-based OS didn't do it this way. I wonder whether I'm just provincial, thinking all OSes should be like the ones I've used.... So, what are the advantages of having it separate, anyway? --Max mrobinson@wash-vax.bbn.com
dale@boing.UUCP (Dale Luck) (06/08/89)
In article <16905@louie.udel.EDU> MROBINSON@wash-vax.bbn.com writes:
=
=[dtsteen@dahlia.waterloo.edu wishes that the stack size become
= part of the executable]
=
=Hey, yeah! But this makes me wonder why the people who were bright
=enough to include shared libraries and a message-based OS didn't do
=it this way.
Because they were different people. And the people that were managing
the software as well as the company that was responsible for AmigaDos
had an ( atleast to us programmers at amiga) unreasonable bias against
unix.
It was a battle that many of us did not want to fight since we had our
own fires that were blazing out of control. ;-)
--
Dale Luck GfxBase/Boing, Inc.
{uunet!cbmvax|pyramid}!amiga!boing!dalemcp@ziebmef.uucp (Marc Plumb) (06/14/89)
In article <16905@louie.udel.EDU> MROBINSON@wash-vax.bbn.com writes: >[dtsteen@dahlia.waterloo.edu wishes that the stack size become > part of the executable] > >Hey, yeah! But this makes me wonder why the people who were bright >enough to include shared libraries and a message-based OS didn't do >it this way. I wonder whether I'm just provincial, thinking all OSes >should be like the ones I've used.... So, what are the advantages of >having it separate, anyway? You get the code to do it ported in 6 weeks flat is the advantage. That decision was made in BCPL-land, so it doesn't have to be good, 'cause it was there thursday. I agree it's rather a kludge. -- -Colin Plumb
usenet@cps3xx.UUCP (Usenet file owner) (06/16/89)
>In article <16905@louie.udel.EDU> MROBINSON@wash-vax.bbn.com writes: >[dtsteen@dahlia.waterloo.edu wishes that the stack size become > part of the executable] I've had a neat idea about how do to this. I think it would be a simple (I don't actually know) thing to do to add an extra block type to execuables. Call it an extra block or whatever. This block could contain standardized info about stack size (like BSS blocks), virtual or protected memory support and the like. Once the loader knows about such blocks, then somebody should be about to write a utility to tack that block on to existing executables, so that regular users could fix their existing software immediatly. You could also use this block to store other application specific information, like TOOLTYPES sort of info for CLI only programs. This is an example of a short .signature jap@frith.cl.msu.edu
dtsteen@dahlia.waterloo.edu (06/17/89)
In article <3418@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes: >>In article <16905@louie.udel.EDU> MROBINSON@wash-vax.bbn.com writes: >>[dtsteen@dahlia.waterloo.edu wishes that the stack size become >> part of the executable] > >I think it would be a simple (I don't actually know) thing to do to >add an extra block type to execuables. Call it an extra block or >whatever. This block could contain standardized info about >stack size (like BSS blocks), virtual or protected memory support and >the like. That's what my original suggestion was: add a hunk type, like HUNK_BSS, except that it is HUNK_STACK. I can see the problems though; the new hunk type would break the loader in 1.3 and previous versions of the system, so 1.4 programs could only be loaded on machines running 1.4 - not very appealing. But it could still be kludged the way ARP apparently does it. But the people in whose power it is to make this kind of change have not responded... Markus Wandel (519) 884-9669
bryan@geo-works.UUCP (Bryan Ford) (06/22/89)
In article <3418@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes: >>In article <16905@louie.udel.EDU> MROBINSON@wash-vax.bbn.com writes: >>[dtsteen@dahlia.waterloo.edu wishes that the stack size become >> part of the executable] > >I've had a neat idea about how do to this. > >I think it would be a simple (I don't actually know) thing to do to >add an extra block type to execuables. Call it an extra block or >whatever. This block could contain standardized info about >stack size (like BSS blocks), virtual or protected memory support and >the like. Good idea. Too bad the Amiga's executable file formats aren't forward compatible like IFF. Hmmm...I wonder if it would be feasible to create a new executable file format that uses an IFF standard for executables. Maybe 'X68K'? Who knows. Probably wouldn't be practical, unless C-A is planning to put IFF stuff in ROM. Oh well, nice idea while it lasted... Bryan -- ____________________________________________ _/ Bryan Ford - bryan@geo-works.geo-works.com \_ _/ ..!utah-cs!caeco!i-core!geo-works!bryan \_ / ..!uunet!iconsys!caeco!i-core!geo-works!bryan \