CompuServe Thread

#3.1 worth it?

15 messages in this thread
#159670From: NathanAug 14, 1994 9:52 AM
>>I could never face those black menus again What exactly is wrong w/em? And what does 3.1's menus look like, hmm? BTW: If I were to upgrade to WB3.1, there are a few features that would have to be in it to make it worthwhile… 1. Threads [maybe?] (I realize coprocessors r faster, but threads r good 2 2. The ability to _FORCE_ any program to run in a window, including any games on AmigaDOS disks. 3. The ability to disallow the closing of WB by any app running. (WB2.1 can screens to be pulled down, but they've closed WB!) This would really spiff up the already great multitasking. If it has just one of these, it's worth it (disallowing the WB closing is the most important feature 2 me) Can any 3.1 users please tell me whether it has this stuff? (I sorta feel stupid pumping hundreds of $$$ worth of life into a possibly dead computer, but as I've said at least a hundred times already, I plan to stick with it!) Intel Overdrive…off a cliff! Nathan Jones, via amiga autopilot. –FLAME ON!–
#159690From: Soft-Logik Tech SupportAug 14, 1994 3:13 PM
3.x's menus are black on white; similar to Mac and Windows. They are legible no matter what color mode and colors are in use. 2.x menus can be very illegible when a command is highlighted. Michael @ Soft-Logik Publishing Corp.
#159732From: Paul HigginbottomAug 14, 1994 10:31 PM
You can get around the app closing WB problem by running any program on WB that opens a window on it, e.g., shell, clock, etc. WB won't close if there's an open app window on it.
#159921From: NathanAug 16, 1994 1:01 PM
Thanks a bundle for that, I need to multitask as effeciantly (and cheaply) as possible! MicronSlump, the company I love to hate! Nathan Jones, via amiga autopilot. –FLAME ON!–
#160474From: E.R. BujtasAug 20, 1994 6:42 AM
I hate, no I love to say this, but the Amiga OS has always allowed multiple tasks per process. Only they are called Tasks, not Threads. They are actually the same thing-They both use the same memory space of the parent and they both create their own stack. The only difference is that OS/2 calls them Threads while Amiga calls them Tasks. It is interesting how close they operate, even in their invocation: DosCreateThread in OS/2 vs CreateTask in Amiga OS. But the term Task came first, that is why such systems are called MultiTasking and not MultiThreading. ..Andy from Harding, NJ The more complicated they make the plumbing, the easier it is to stop-up the drain. ….Scotty
#160534From: Jim ButterfieldAug 20, 1994 4:56 PM
We may get into terminology confusion here. Amiga makes a distinction between TASKS and PROCESSES: a task is quite easy to create from another program but has some trouble with DOS operations; a process is a heavier-duty version which comes with full DOS superstructure. If a user starts something via CLI/Shell or Workbench, that something will be a process. That process in turn can spawn "children" – most often child tasks, because they are easier to create. But a process can indeed launch another process if it needs to do so. When the parent program terminates, it can send a message to its child processes and tell them to terminate, too. But it doesn't have to: the children can survive the parent, and often do so. I'm not sure this distinction exists outside the Amiga environment. Microsoft Press Computer Dictionary: TASK: a stand-alone application or a subprogram that is run as an independent entity; PROCESS: a program or part of a program; THREAD: a process that is part of a larger process or program. So a thread is defined as part of a task/process (a "child task"?). PROCESS and TASK are not clearly distinguished (application=program? subprogram=part of a program?). MULTITASKING: (long definition) .. in which a computer works on more than one task at a time. There are several types of multitasking… MULTIPROCESSING: (definition indicates multiple processing units). But heck, the Microsft dictionary is almost 3 years old now. I'm sure the words have changed meaning since then. –Jim
#160552From: Chris LesterAug 20, 1994 8:15 PM
I'm sure Billy-Boy revamps the definition weekly to make sure is Environment of the week looks good! <g> Chris – Fast and Low on my '020! Anyone know where I can get some old "Paper Lace" 45's?
#160593From: E.R. BujtasAug 21, 1994 7:19 AM
Jim: The terminolgy you present is correct, by definition, but not wholy true in implementation. For example, it is true that an Amiga OS PROCESS is a superset of an Amiga OS TASK. Both utilize the same TASK structure. This works the same way in IBM OS/2, where a PROCESS is a THREAD which can launch other dependent THREADS. An Amiga OS PROCESS is a TASK which can launch other dependent TASKS. I have done this. Each of these OS PROCESSES (Amiga and OS/2) can also launch other independent PROCESSES as well. This is unlike UNIX which can only launch PROCESSES by 'forking'. Thus a UNIX process can terminate leaving the daughter process to become a ZOMBIE process adopted by the INIT process. Whereas, an Amiga PROCESS with a dependent TASK or an IBM OS/2 PROCESS with a dependent THREAD, will terminate all dependent TASKS/THREADS when the parent is terminated, alone with any PORTS or IPC mechanisms. I write programs in UNIX, Amiga OS and IBM OS/2, and I can tell you that the general process is basically the same between Amiga OS and IBM OS/2, but not UNIX. They are created basically the same way, but controlled somewhat differently. ..Andy B.
#160601From: Jim ButterfieldAug 21, 1994 10:32 AM
Thanks for the note, Andy. These terms sometimes get thrown around in discussions, and since it seems that each machine has its own terminology for similar items, I thought it would be worthwhile to toss in a note. –Jim
#160616From: Don Curtis/SYSOPAug 21, 1994 11:51 AM
Andy, It's the multi-user nature of UNIX that all processes end up as children (grand-children, great-great-grandchildren, etc.) of init. Don
#160617From: Don Curtis/SYSOPAug 21, 1994 11:59 AM
Andy, BTW….a 'zombie' process in UNIX is one where it dies, but refuses to go away. They often show up in process lists as '<exiting>' or <defunct> and don't respond to a kill (including -9) signal. It's most often caused by failing to close all open file descriptors or controlling terminals when attempting to write a daemon. Using the same family-type terminology, when a parent process dies, the child process is 'adopted' by init or the parent's parent. Don
#160576From: Peter M. D'AngeloAug 21, 1994 12:44 AM
Hey all, I have but one question to ask. I have upgraded my CD32 into a full fledged HD installed computer. If I by WB 3.1, will I need to make any ROM changes, or is the 3.1 ROM in the CD32 the same ROM? Thanks in advance. Peter M. D'Angelo Cruising Over NY on AutoPilot
#160599From: Dale LarsonAug 21, 1994 8:13 AM
From the WB, hit the "about" menu item, or from shell, do "version." What does it say that your CD32 has for a KickStart revision? If that is about the same as the KS being shipped as 3.1, then you don't need a ROM upgrade. Let us know what you find. Dale L. Larson Intangible Assets Manufacturing (info@iam.com) "That's the best part about being crazy. You see things no one else can see."
#160619From: Mark D. ManesAug 21, 1994 12:14 PM
CD32 already has the 3.1 ROMs. -mark= Otto Pilot Engaged..
#160791From: Ron LegroAug 22, 1994 10:30 PM
PMJI but good point. In "threads" OS/2ers think they have leapfrogged everyone else who *merely* multitasks, but here's the Amiga, right in the thick of things. As most Madison Ave. types know, taking an old product and renaming it does wonders, sometimes. "He tasks me." — Kahn (STII)