cg@myrias.UUCP (Chris Gray) (06/10/88)
Oh yes, ideas for 1.4 (or 1.5):
How about some tooltypes in the CLI icon that will control the appearance of
the new CLI window opened? E.g. size, position, title, FgPen, BgPen, etc.?
How about a standard "intuiTools" library, containing a set of tools to help
use Intuition. E.g. a CBM standard file requester, a general palette editor
(I'll send you source to this if you want), routines to simplify menu
creation, etc. Make it the usual AmigaDOS shareable library.
How about a shareable library with IFF tools? Reader, writer, ILBM stuff, etc.
If the library can handle arbitrary streams, this could make clipboard support
a snap.
How about some simple way to put scroll arrows inside scroll bars?
And now the blue sky: I've heard a weak rumor that 1.4 will be able to use the
68851 MMU to provide protected address spaces. Any form of this, even if it's
not the default, would be great. I've heard people that can be classed as
"Unix fiends" say that they would prefer a protected AmigaDOS to UNIX on the
Amiga. I think that this IS doable. Lots of programs wouldn't work, either
because they reach outside their own address space, or because they don't use
MEMF_PUBLIC when they should. That's fine, let them run unprotected. A new
hunk type here could help, along with a little program to change hunk types to
the new "run me protected" forms. How much would an A2000 with the 68020 and
4Meg of RAM, an ethernet card, and the new hi-res monochrome monitor cost? If
running a protected AmigaDOS, I suspect it would outperform a Sun 3/50. Note
that no disk drive is needed, but I think a single floppy would be desireable.
--
Chris Gray Myrias Research, Edmonton +1 403 428 1616
{uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cgblandy@marduk.cs.cornell.edu (Jim Blandy) (06/10/88)
In article <611@myrias.UUCP> cg@suncg.UUCP (Chris Gray) writes: >And now the blue sky: I've heard a weak rumor that 1.4 will be able to use the >68851 MMU to provide protected address spaces. Any form of this, even if it's >not the default, would be great. [ stuff ] Do we REALLY want protected address spaces? It seems to me that a lot of the most interesting ideas out here (ARexx, something about Message Brokers, etc) involve fiddling with other people's address space. It's one thing to insist that messages and message ports be public; that's easy. But everything a message refers to needs to be public as well, so the receiver can access it. And gee, libraries need to be public, and if a program patches itself into library vectors then it would need to be public (assuming we don't add lots of deprotection baggage to library calls), and... I strongly agree that one haywire program shouldn't crash the system. You should be able to crash as much as you like, in any way you like, without disturbing other tasks (well, I don't LIKE crashing... :-). But boy, do we get a lot of mileage out of our open address spaces.. While memory protection would be nice, it seems that a lot of the power and simplicity of the Amiga would become restricted. I'm not talking about combatibility with old programs; I'm asking - do we want to give up the advantages of an open address space? Or is there a neat way to get around these problems (wouldn't that be superb) that I'm missing? -- Jim Blandy - blandy@crnlcs.bitnet "insects were insects when man was just a burbling whatsit." - archie My opinions are my own, not Cornell's.
cunniff@hpfcdc.HP.COM (Ross Cunniff) (06/11/88)
In article <18191@cornell.UUCP>, blandy@marduk.cs.cornell.edu (Jim Blandy) writes: >In article <611@myrias.UUCP> cg@suncg.UUCP (Chris Gray) writes: >>And now the blue sky: I've heard a weak rumor that 1.4 will be able to use the >>68851 MMU to provide protected address spaces. Any form of this, even if it's >>not the default, would be great. [ stuff ] >Do we REALLY want protected address spaces? >It seems to me that a lot of the most interesting ideas out here >(ARexx, something about Message Brokers, etc) involve fiddling with >other people's address space. It's one thing to insist that messages >and message ports be public; that's easy. But everything a message >refers to needs to be public as well, so the receiver can access it. >And gee, libraries need to be public, and if a program patches itself >into library vectors then it would need to be public (assuming we >don't add lots of deprotection baggage to library calls), and... >Or is there a neat way to get around these problems (wouldn't that be >superb) that I'm missing? Instead of making the address space of processes completely hidden from each other, would it be possible to mark them as read-only to other processes? I don't really care if a program is peeking around at messages that I'm passing (or even looking at my text or data or whatever); I just don't want to be scribbled on without my permission. >Jim Blandy - blandy@crnlcs.bitnet Ross Cunniff Hewlett-Packard HP-UX DCE lab ...{ucbvax,hplabs}!hpda!cunniff cunniff%hpda@hplabs.ARPA
ewiles@netxcom.UUCP (Edwin Wiles) (06/12/88)
In article <18191@cornell.UUCP> blandy@crnlcs (Jim Blandy) writes: >In article <611@myrias.UUCP> cg@suncg.UUCP (Chris Gray) writes: >>And now the blue sky: I've heard a weak rumor that 1.4 will be able to use the >>68851 MMU to provide protected address spaces. Any form of this, even if it's >>not the default, would be great. [ stuff ] > >Do we REALLY want protected address spaces? > >It seems to me that a lot of the most interesting ideas out here >(ARexx, something about Message Brokers, etc) involve fiddling with >other people's address space. ... >I strongly agree that one haywire program shouldn't crash the system. >You should be able to crash as much as you like, in any way you like, >without disturbing other tasks (well, I don't LIKE crashing... :-). ... >Or is there a neat way to get around these problems (wouldn't that be >superb) that I'm missing? I think so. The only reason for crashing a system is if you cannot guarantee that the operating system, and its associated *critical* information, is uncontaminated. Thus, the only part of memory that must be protected, is that which is used by the OS. (Anything else is on it's own.) Even better would be a mechanism where you can tell the OS/MMU to protect a program and its data, or can tell it to leave it open. Is this possible? -- ...!hadron\ "Who?... Me?... WHAT opinions?!?" | Edwin Wiles ...!sundc\ Schedule: (n.) An ever changing | NetExpress Comm., Inc. ...!pyrdc\ nightmare. | 1953 Gallows Rd. Suite 300 ...!uunet!netxcom!ewiles | Vienna, VA 22180
cmcmanis%pepper@Sun.COM (Chuck McManis) (06/15/88)
In article <62300007@hobbiton> choinski@hobbiton.prime.com writes: > The reason I gripe about this [forced reboots] is because of the > immense start-up time involved to re-boot. >Burton Choinski Prime Computer Inc. Well there are many ways to streamline the time it takes to reboot your system, many can improve system booting performance 100 - 200 % ! Some suggestions : o Make your boot floppy special - Format a new blank floppy (NOICONS) and then make (but don't copy) the following directories on to it : s, c, libs, devs, l. Then copy startup-sequence, devs:system-configuration, c:assign, c:stack, c:run, and any other commands in c: that you use in the startup script. Then copy any handlers you mount (AUX, PIPE, etc) into the l: directory. Then copy the rest of c: the libs: directory and then devs: the rest of s: the rest of l: all of fonts, system etc. What this does is move all of the files that you access intially to the same couple of cylinders. That cuts down the grind, grind, grind considerably. o If you are using ARP compress your assigns by doing multiple assigns at once : assign lc: sys:lc foo: mydir dpaint: :dpaint t: ram:t o If you have a hard disk do the minimum stuff you need to on the floppy and then transfer control to the hard disk startup sequence. Similarly if you have a recoverable ram disk and you know it has recovered successfully. o If you are using a shell that allows resident commands such as MetaCompCo's or have Jim Goodnow's REZ command, then make frequently used commands resident such as assign, path, if. Doing these things will really make a difference in reboot time. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (06/16/88)
In article <56624@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) makes several suggestions for streamlining the boot process: > o Make your boot floppy special... > o If you are using ARP compress your assigns... > o If you have a hard disk do the minimum stuff on the floppy... > o If you are using a shell that allows resident commands... use them Another real simple trick is to change your Startup-Sequence file so it first copies frequently used commands to ram:, then executes the commands from ram:. For example: copy assign ram: ram:assign c: MyDisk:c ram:assign l: Mydisk:l --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3
dpvc@ur-tut (Davide P. Cervone) (06/17/88)
In article <256@laic.UUCP> darin@laic.UUCP (Darin Johnson) writes: >wIconify comes up with its own menus in the Workbench menubar. Does anyone >know how this was done? Yup. I wrote it. >Does it involve patching into the workbench image, Yuk! No! I may be desperate, but not that desperate! >or is there a simpler (undocumented or poorly documented) hook to do >this? The method used is simple, reasonably effective, and almost "safe". It's still illegal, so it's not really safe, and there are still things that can break it, but not many, and they would be illegel themselves. How does it work? Well, finding the WB menu strip is easy once you have the pointer to the WB window (which is not THAT hard to find). Once you have the menu strip, you can ClearMenuStrip(), chance the menu pointers (like add additional items), and SetMenuStrip() the monified menu. At his point, the new menu items appear when you hold down the menu button. That's the easy part. Now you have to intercept the MENUPICK events that the WB would get. This is the trick. To do it, you patch into the UserPort of the WB window. This isthe illegal part. Those of you who have seen my old MonIDCMP program, don't worry, I do NOT use that method of trapping IntuiMessages. I have a more robust method now that allows multiple evesdroppers on any message port. (I have a new version of MonIDCMP that uses it). I won;t go into the details of patching into the port here (I can send the new MonIDCMP code to anyone who is interested). The basic idea is to create a new port structure, and intertwine it with the WB port: link the head pointer of one to the tail pointer of the other. Messages posted to the one will actually arrive at the other. New messags sent to the WB port will not be available to the WB until after you read them from your new port and then re-post them to the port. This lets you "see" all the messages before WB gets them. You don't have to worry about priority and timing like the old MonIDCMP method. Once you have access to the WB IntuiMessage stream, all you have to do is look for MENUPICK events, and when you find one, look for the items that were chosen. If the item is one of your menus, then do what you have to do and remove it from the list of items chosen. Otherwise, pass it on to the WB. Note that you never REPLY to these messages, you simple read them from your port and re-post them as they are. When the WB replies to the message, it is returned to Intuition (not to you). I hope this gives someone some ideas of how to do this. it sounds like a neat approach to "pop-up" programs. I'd do it myself, but I'm already behind in my project list. >If so, I could write such a menu package, but without being able >to use workbench menus, it would be a kludge (such as having to click in >a mini window first - but then browser allows this sort of thing). Well, the approach I described is still a kludge, but it's a proven one (wIconify uses it). It's still illegal, though, and may break in a future release of Intuition. Provided that GetMsg and PutMsg check for end-of- message-list in the same way they do now, however, it should continue to work. >Darin Johnson (...pyramid.arpa!leadsv!laic!darin) > (...ucbvax!sun!sunncal!leadsv!laic!darin) I hope this was interesting to someone! Davide P. Cervone dpvc@tut.cc.rochester.edu dpvc@ur-tut.UUCP DPVC@UORDBV.BITNET P.S., I'm interested in how awful people think this kind of sneakiness is. Will you give up using wIcoinfy now that you know it "cheats"? Has anyone figured out how it gets rid of the windows yet?
cunniff@hpfcdc.HP.COM (Ross Cunniff) (08/10/88)
This thought just struck me, after struggling with DeadKeyConvert for
the n'th time:
Why not add the feature to Intuition that, when both
RAWKEY and VANILLAKEY are specified in an IDCMP port's
flags, VANILLAKEY events are sent for those keys which
have mappings and RAWKEY events are sent for all other
keys?
For those of us who just want to grab the HELP and arrow keys as
well as standard keyboard keys, this would be a great timesaver
in programming (I'll bet that the number of programs that do
incorrect key mapping will decrease, as well).
Ross Cunniff
Hewlett-Packard Colorado Language Lab
...{ucbvax,hplabs}!hpda!cunniff
cunniff%hpda@hplabs.ARPA