Can't We All Just Get Along? (Win/Mac)

Great Debates
81

Badtz:

Interesting. On every single occasion, I’ve found the “Help” facility to be sorely lacking and in some cases comical. For instance, once I needed to know how to do a screen shot.

I looked up “screen shot”… “0 topics found”

I looked up “screen capture”… It referred me to the Windows glossary which had highlighted every occurance of the words “screen” and “capture”, but none of these were any use.

I looked up “snapshot”… and it gave me the following:

Ahhh… now we’re getting somewhere.
So I looked up “screen dump”… and here’s where it get’s a bit comical… It referred me back to “snapshot”. No indication of how to execute this function…

I tried a bunch of other combinations, but never found out from “Help” how to do this basic function. Of course, now I know to use the “PRINT SCREEN” key, but “Help” was no help…

I can give you a bunch of similar excursions into the comical wold of Windows “Help”.
On the other hand, the Macintosh help facility goes too far the other way, in my opinion. It’s almost patronizing in the way it holds your hands, circles the thing you need to be looking at, and forces you to “DO” the thing that you’re seeking help on. Sometimes I simply want to know “how” to do something - I may not be ready to actually “do” it yet… For a computer novice, though, it’s excellent.

82

Um, when would you be wanting to do a screen capture in Windows outside of an application? I’ve never had a reason to…and if I want to do one in some application (i.e. SecureCRT, Homeworld) I look in the documentation for that particular program.

83

When writing that documentation. (I was sick of Mom calling me up and asking “Which buttons do I hit to get e-mail again?”) Screenshots are invaluable.

They’re also great for proving that you did get to the secret pornographic level of Tomb Raider 12.

Fenris

84

Badtz:

Two answers:

First, I want to point out that the PRINT SCREEN function operates at the OS level and therefore, technically is always outside an application…

Second, in that specific case, I was trying to overcome another Windows shortcoming: the inability to print a directory. I was trying to get a screen shot of a directory in Explorer, then depending on the format of the screen shot, I would open the appropriate application to print the result. It really is unfortunate that Explorer left off this very basic function. It’s something I used to have to do a lot (it had to do with software configuration management, government specs, and paper trails). For a while, I use the DIR command in DOS and redirected my output, but DOS really didn’t let me get to a suitable format, so I ultimately wrote a perl script to do what I needed…

85

How about when you are trying to illustrate a process that involves more than one running application (and its windows)? Real-life example-- “To send the ‘opener script’ file for the selected FileMaker solution to its authorized users, click the Send Opener Script button. If you are using Windows: Outlook will generate an email message which will come to the front, pre-addressed to the appropriate people and with the instructions in the body. Outlook is non-compliant with the attach-file subcommand of OpenURL so the file path to the correct attachment has been copied to clipboard. Click the paper-clip icon, go Ctrl-V to paste [cursor will be in the File Path field of the dialog box by default] and hit return and you are ready to click the Send button.”

The associated screen shot shows an Outlook email message on top of a FileMaker database screen, showing the appropriate buttons on both. I, too, had difficulty figuring out how to get screen shots from Windows, and used VirtualPC + my Mac screen shot capabilities for a long time until I learned the Alt-PrintScreen keystroke combo + pasting into the Paint accessory and saving as a file.

86

Hmm, I guess there are situations where a casual user might want to do a screen capture. It’s never come up for me though, which is why I don’t know how to do it (I know how to take screenshots in a number of my games but it’s often a different button, i.e. * on the Number Pad for Asheron’s Call).

Umm, I’m using Windows NT now, but just out of curiosity I looked in it’s help and I found the answer immediately - here’s what I found…

To copy the window or screen contents

To copy an image of the window that is currently active, press ALT+PRINT SCREEN.

Or, to copy an image of the entire screen, press PRINT SCREEN.

Tip

To paste the image into a document, click the Edit menu in the document window, and then click Paste.

That’s Windows NT help though, I’ll have to check Win98 when I get home.

87

JoeyBlades:

No… MS-DOS has interrupt handlers, but nobody would say that MS-DOS is a multitasking OS. Using interrupts doesn’t involve any kind of task switching.

Interrupt handlers don’t run simultaneously with applications; they interrupt the running application, do their thing, and then cede control back to the application.

Always? It didn’t have any multitasking at all until System 6 with the MultiFinder. Again, multitasking is the ability to run two or more tasks simultaneously, sharing CPU time between them.

It sounds good if you assume that all software is written perfectly… but we know that isn’t true.

I don’t see any advantages to leaving task switching up to the programmer, rather than having the OS switch tasks automatically. A preemptive multitasking OS is easier to develop for, since you don’t have to worry about when you’re going to give control to the next application. If an application is poorly designed or buggy, preemptive multitasking will let it run without slowing down the rest of the system.

Never heard of it. Cite?

88

You want to play games? Buy a PC.
You want to make stuff? Buy a Mac.

You are smoking crack!!

A PC kills a MAC in everything.

This is a fact so you can’t dispute it. There is nothing that shows that the Mac is faster. It never is. You can get a 1.2G T-Bird for less than a 500Mhz Mac. And the fact is that the T-bird will include a monitor. And it will still smoke any MAC.

Yhe 50Mhz Mac is unworthy.

89

Begging your pardon, but my 40 MHz accelerated MacSE kicked butt! Beat up your little 386 DOS box any time!

What? Oh…never mind!

90

:rolleyes: Uh-huh.

Hey, mx, could you follow me please? I’m involved in a few other debate threads and we’re having trouble discovering who is right. So, if you could just identify who is absolutely right and who isn’t, that would clear things right up.

You’re never wrong, huh?

I’ll bet you thought that your winning personality would make the entire SDMB population jockey for positions in line to get to know you better.

Ooops…

91

Mr2001:

True. My claim was not that interrupts = multitasking, that’s an oversimplification.

Not true. First and foremost, an interrupt is, by definition, a task switch. Second, how do you think preemptive multitasking works???

A: Clock driven interrupts AKA the task scheduler.

Woah Nellie… You aren’t under the impression that multitasking allows applications to run simultaneously, are you? That’s parallel tasking and is only possible with multiple processors. All single processor multitasking interrupts the current task, jumps to another task, interrupts that task, and eventually reenters the original task and resumes. etc. etc. There’s no simultaneity involved.

Oops! You caught me, however your correction is not entirely correct. Before MacOS 6 and MultiFinder, there was Juggler which did pretty much the same thing as MultiFinder. However, the original MacOS was designed with this cooperative multitasking in mind. I remember writing software for the Lisa (preMac) and seeing documentation about how vital it was to use ‘GetNextEvent’, ‘WaitNextEvent’, and ‘SystemTask’ in order to support future multitasking.

Also, not really what we’re talking about, but there was another OS that ran on the earliest Macintoshes. It was called OS9 and it was a preemptive, real-time multitasking OS. I mention it mostly for it’s trivia value since there was a lawsuit a while back preventing Apple from casually referring to “MacOS 9” as “OS 9”. I actually had the pleasure of using OS 9 on the 1984 “skinny” Mac. I used it on a “Trash80 CoCo” and a home brew 6809-based computer before that. OS 9 was originally developed for the highly underrated Motorola 6809 microprocessor. OS 9 was somewhere between DOS and unix in it’s power and usefulness.

Actually, there are many advantages. If all is written well, cooperative multitasking is more efficient and is more seamless for the user. Cooperative multitasking can result in smaller code and better memory utilization because the programmer can decide where his code needs to be reentrant. Of course, in these days of template-based programming, this can be less of an issue… but I digress. Cooperative multitasking generally doesn’t result in many of the sometime irritating user interface glitches I mentioned earlier. For instance, menus that die, before you can complete your operation, because a background task takes over… actually, that’s really an example of how difficult it is to make interactive software, such as GUIs, reentrant. Microsoft, with all their brilliant programmers, still can’t get it right.

I disagree. Your position is commonly stated, but it actually invites programmers to write bad code. I will counter that preemptive multitasking is much harder to develop for because you have to assume that your code will get preempted anywhere at anytime. It forces good programmers to guess at worst case scenarios and make sure their software will play nicely in those scenarios.

I’ll give you that, however that’s never really a problem in the Macintosh world because any programmer with enough saavy to get a decent user interface that will invite users to try his/her software is probably bright enough to put in the necessary system calls to make his/her application multitasking friendly. In any event, Mac users have zero tolerance for poorly written software, so it’s rarely a problem. Windows users seem to be much more accepting of poorly written software, as evidenced by the abundance of the stuff…

Sorry, I don’t have a cite. I did see a reference to it a while back, but I don’t remember where that was. However, I know of it from direct experience. A developer friend of mine was given a copy by Apple to evaluate. It was many years ago. I couldn’t tell that much about it except to note that it exhibited some of the same user interface problems that I see in Windows. I’ll see if I can track down some info on it.

Personally, I find it a bit comical to hear people defend Windows’ preemptive multitasking as something meaningful and good. If you’ve ever used unix, then you know what true preemptive multitasking can be like. Windows misses the mark - it’s half-assed. In fact, the only good reason for Windows to have preemptive multitasking is because there’s so much crap that tries to pass itself off as software in the Windows domain. If Windows application software were well written then Windows’ preemptive multitasking would be a very bad thing.

92

JoeyBlades,

Man, don’t you ever shut up?:smiley:

'Kay, I’m kidding. You sure know a lot about programming!

I just wanted to chime in with a gripe about Windows MultiTasking:

Sometimes I run more than one browswer window at a time (when I’m doing ummm… research!). So, I finish reading a thread and head up to hit the close button, but the thread loading in the background finishes just as I get there, and pops into the foreground. So, what happens? I end up closing the new thread that just finished loading!

GRRRRRRRRRR…

93

Ok…everyone pretty much agrees that Windows is the primary cause for people disliking PC’s, am I correct?

So what happens if (hopefully) PC’s get an OS that is just as good or better than MacOS? What cause for complaint would Mac users have then? (I know it’s a large stretch of the imagination, and it sure caused my brain to hurt).

94

JoeyBlades:

An interrupt isn’t a separate task, it’s basically a function call that can be triggered from an outside source. The application stops, the interrupt handler runs start to finish, and the application resumes. The interrupt handler only runs when the interrupt is triggered.

Of course not. But the idea is to pretend that they’re running simultaneously, by switching back and forth between tasks.

An interrupt handler doesn’t operate under such a pretense. It interrupts the active task, and then it’s done.

Heh, I still have a copy of OS-9 for the TRS-80.

That hasn’t been my experience, either under Windows 3.1 or MacOS. It’s always been very obvious when an application is refusing to give up control.

Preemptive multitasking doesn’t require applications to be reentrant… reentrancy is only an issue if a function will called at unpredictable times (like a callback or an interrupt handler). Preemptive multitasking simply pauses the application and resumes it later.

Look at the source of any Unix application; chances are it won’t deal with multitasking or reentrancy all. Preemptive multitasking allows it to be written as if it owns the entire system. With cooperative multitasking, every application would need to be written with cooperation in mind.

That’s a problem with Windows, not preemptive multitasking. X and BeOS don’t have those problems.

As I mentioned above, this isn’t true in practice. Preemptive multitasking is typically invisible to the programmer.

Unfortunately, that’s not always the case. Netscape is one example. Sure, you might say “blame it on bad programming”, but that “bad” programming would be perfectly acceptable if the OS could decide when to switch tasks.

Care to explain this further?

95

Badtz:

Yeah, I noticed that too, however I believe that’s a recent addition. I’m pretty sure back when I was originally searching, I was using service pack 4 and that ‘copy window’ help reference wasn’t in the help database at that time.
sdimbert:

Occasionally… I just don’t feel like it today… [wink]

Well, that can happen on the Macintosh, as well, but I wouldn’t classify that as a multitasking idiosyncrasy. That’s really a case of bad programming. The programmer should insure that new windows don’t precisely overlap old windows (you’ve probably noticed the staggered tiling used by many programs). This approach isn’t foolproof, but does reduce the risk of clicks intended for one window taking action in a newly created foreground window. Of course, if you use the Microsoft MDI (Multiple Document Interface) you’re more likely to experience this kind of problem. Another thing about Windows that precipitates this problem is another one of those things that I find frustrating about Windows, in general. You have to open the new window that you’re about to work on before you close the one you’re done with. Otherwise, the application quits. In the Macintosh world there’s a definitive distinction between closing windows and closing applications. I often “task switch” between jobs and want to leave an application open, but close all of the current windows. If I do this in Windows, the application quits. Often, this doesn’t matter, but for applications that take a long time to load or require some sort of login process (like a browser through a firewall) this is damn inconvenient. On the other hand, because Windows menus are tied to the application windows, I’m not sure how it could be handled any differently.

In fairness, long time Windows users’ most frequent complaint is that they closed all of the windows of an application, but didn’t realize that the application was still alive…

In any event, because of my natural work style, I find the Windows way to be counter intuitive and a detriment to my productivity.

96

Monster:

I only complain because, as a user I expect more. If Windows suddenly got better or I started using linux or (insert favorite non Windows OS here) and found that better, then you’d hear fewer complaints from me. However, I do think that some of Windows limitations are due to (1) legacy architecture and (2) unpredictable hardware configurations. As we’ve already noted, some Windows users like to build their own boxes and it’s very difficult for Microsoft to make their OS bulletproof without more rigid hardware configuration standards. It’s back to the old argument that the MacOS works better with a Mac because Apple produces both, where Microsoft has to cater to a wide variety of hardware manufacturers. There is certainly some truth to this argument…
Mr2001:

I think you’re operating under a very narrow minded definition of interrupt service routines, especially those running under modern, multitasking OSes. Also, as I pointed out earlier, your statement is equally valid if I susbstitute the word “application” for “interrupt handler” and recognize that it is, in fact, an interrupt that ‘triggers’ the context switch by the scheduler.

Not necessarily. In a well designed preemptive OS many of the activities that you may historically be associating with one shot interrupt service calls are managed as background tasks in more modern OSes. They don’t quit until they are done, however they may, themselves be interrupted by other priority interrupts or sometimes the task scheduler.

I really think the distinction you’re trying to draw is no longer valid.

Cool! I knew there was something about you that I liked…

I just wanted to note that, with the exception of some really, really bad software that I saw for the Mac back in the very earliest days of the Mac and a joke application that I once wrote, I’ve never seen an application that dominated the MacOS. I’m sure it’s possible and I’m sure that such attrocities do exist out there, but I think they are very, very, very rare. So rare that it makes no sense to worry about them. So one might ask, “Why does any one care about preemptive multitasking for MacOS X, then?” The answer is that, in some cases, preemptive multitasking can lead to better CPU utilization. The most often cited case is when an application is trying to read data from a disk and has to wait because the hardware is relatively slow. A smart task scheduler can preempt the application and let another process use the CPU during this wait time. If control is returned to the primary application before or as soon as the disk has provided the data, the application will suffer no degradation in performance. Another reason that preemptive multitasking is good for OS X is that processes can be assigned priorities (and these priorities can be changed dynamically). This allows a user to decide which process or processes get the lionshare of the CPU resources.

The Windows’ implementation of preemptive multitasking benefits from neither of these, BTW. More on this later.

The task scheduler does interrupt the application at unpredictable times. Perhaps I’m missing your point, but reentrancy is a requirement for any multitasking scheme. They only differ in their implementations of reentrancy.

Agreed, but that is because the reentrancy at this level is handled automagically by the compiler. Sometimes, especially when dealing with GUIs, managing the reentrancy at the compiler level isn’t adequate.

Well, it’s a problem with Windows’ implementation of preemptive multitasking. Again, I’ll try to address this in a minute.

Personally, I believe that many of Netscapes flaws have less to do with ‘bad’ programming and more to do with anticompetitive practices at Microsoft. Netscape is much more robust and polished in the MacOS and unix domains, even though there are more resources applied to the Windows domain.

It’s only acceptable if it doesn’t impact the user in any way. My point has never been that preemptive multitasking is a bad thing - only that Microsoft’s implementation of it is very weak.

Where to start??? I could probably go on incessantly on this, but I’ll spare you and just highlight a few points.

First, let’s start out by being clear on what Microsoft’s implementation of preemptive multitasking is. Fundamentally, Microsoft’s preemptive multitasking is a simple timeslice scheme. This means that an application’s operation is partitioned into discrete sequential executions. All tasks get an equal slice. In the unix world, all timeslices are not created equal. Each task has a priority and that priority can change dynamically, depending on environmental factors, ‘ambient’ user behavior, and upon specific request to change a process priority (possibly some other factors, but those are just off the top of my head). The task scheduler knows what’s going on in the application, to a certain extent, and can preempt a task if it’s waiting on slow hardware and lower it’s priority. Conversely, the scheduler is ‘aware’ of GUI operations and can assign these very high priorities so that they are less likely to get preempted causing user interface grief. I know this is why X is so responsive, I can only assume that BeOS fare better for the same reason. That, coupled with attention to detail in the reentrancy of their GUI code.

BTW, I’m not saying that Windows doesn’t prioritize tasks and threads. It certainly does. Just not as effectively as unix and there’s virtually no user control. Why would you want this? imagine the following scenario. You’re sitting in your office downloading mp3s in the background. You boss walks in and wants you to quickly rerun your financial report numbers. You know that this is a process intensive activity and you really want your boss to leave as quickly as possible. Wouldn’t it be ‘nice’ to supress or suspend your download process and get the financial report done more quickly? After your boss leaves, it would be ‘nice’ to bump your download process back up to make up for lost time…
(Note: the unix command to voluntarily change a process priority is called ‘nice’ - sorry for the cute wordplay)

I won’t continue to bore you, but there are other problems in Windows’ preemptive multitasking that have to do with very low priority activities being given arbitrarily high CPU access when non critical faults occur and poor handling of the semaphore mechanism for “critical sections” of code.

And that’s just talking about the scheduler, there are problems with Windows’ protected memory implementation and more… But I’ll shut up now… in deference to sdimbert…
BTW, in reference to my earlier claim that I had seen a prototype of a preemptive MacOS, here’s a relevant link:

http://bondiboard.macpublishing.net/1995/07/features/1044.html

I’m pretty sure that what I saw was an alpha prototype of this and the timing is about right.

97

JoeyBlades:

The authors of the article you mentioned might disagree:

Yes, but the task doesn’t know that. The scheduler just pauses and resumes the task.

Reentrancy is only a problem when a function might be called recursively at unknown times; for example, if you write an OS callback that makes system calls itself, it’s possible that those system calls might cause the callback to be run again. So your callback needs to be reentrant.

Perhaps we have different definitions of reentrancy.

I’ve never heard of this, and I’ve never noticed anything special in the assembly output listings. Cite?

What does that have to do with Netscape’s lack of cooperation on MacOS?

Windows NT has task priorities, and they seem to be more detailed than Unix’s - each process has a priority class, each thread has a relative priority (with regard to the process’s other threads), and the two combine to form a “base priority” for the thread. The actual priority is raised above the base priority when certain events occur that are important to the thread.

I’m not sure about Windows 9x, but the documentation doesn’t mention any differences.

I don’t know of any system where this is the case - X isn’t part of the kernel; the X server is just an application. While the OS might be aware that the server is drawing to the screen, it doesn’t know which X applications are performing graphics operations, or what kind of graphic objects are being manipulated (menus, buttons, etc.).

Yes… right-click on the taskbar, start Task Manager, right-click the financial program, choose Set Priority, then choose High.

In Windows 9x you may need to use an external program like WinTop.

Ah… Copland? I wouldn’t doubt it had problems. Perhaps that’s why they never released it. :wink:

98

No way.

If you want to make pretty pictures, sure, go buy a Mac. If you want to make industrial control software, buy a PC.

In other wors, it all depends on what you mean by “stuff.”

99

OK, I guess I’ve kept you in suspense for long enough.

The thing that makes ME crash is an AT&T dial-up service application. It doesn’t crash Win98, WinNT 4.X, or Win2K. Everytime he dials in to check his e-mail or surf, it crashes WinME when he closes it.

100

Mr2001:

Actually, in hind sight, I disagree. Just last night I was doing several things at once and I had a modal dialog up in a graphics program, tweaking some settings. I wasn’t ready to dismiss the dialog, but my mp3 playlist had just completed and I wanted to fire up another one… no can do. I had to live for nearly 3 minutes without music… dreadful!

Yes and no. You are clearly using the term in it’s purest context (and I was too). However, I was also using the term rather loosely to refer to a much higher level concept.

If we haven’t already driven everyone away from this thread, I’m sure I’m about to push this over the top…

On the lowest machine level, reentrancy can be maintained with proper stack maintenance. The compiler generally manages much of this reentrancy invisibly to the programmer. Let’s call this level 0. Since physical resources are often shared between programs, there’s another level of reentrancy required. Programs share network access, serial ports, modems, etc… Some level of reentrancy is derived from the device drivers associated with these resources. Let’s call this level 1. At an even higher conceptual level, in windowing environments, programs share the virtual display. Windows overlap. Backgrounds are displayed. Menus pop up and down. The curser moves about, interacting with everything. A certain level of reentrancy can be hidden from the typical programmer, depending on what APIs are available to the programmer. Let’s call that level 2. There may be other levels in there, as well, but this is enough to illustrate my point.

At level 0, programmers usually rely on the compilers to do all of the dirty work. It is possible for another job to dink around with the stack and generate a stack frame error or corrupt another program’s data on the stack, but this would have to be almost intentional, so it’s typically not worth worrying about.

At level 1, things start to get a bit trickier. People start to get creative with their use of these shared resources, sometimes even bypassing the drivers. A good programmer will never trust that the previous job put everything back in the right state or that the drivers were able to maintain their control state. Therefore, it is often necessary to have special reentrancy code to put everything right.

At level 2, things really get interesting. Practically anything can and does happen. The programmer typically needs to provide reentrancy code to redraw his/her windows, menus, and other graphical elements etc…

Sorry, I misunderstood your point - I assumed you were talking about Netscape’s lack of cooperation with Windows. I find Netscape on the Mac to be very cooperative, so I’m not sure what problems you’re referring to. In Windows, however, Netscape fails to play nicely with other software with great frequency.

Well, I might just take back some of the things I said about Windows’ priority system. I was unaware that this was possible… and it’s not for lack of looking. I’ve been wanting to do this for ages and all my “experts” told me that Windows didn’t support this. Thanks for pointing this hidden feature out - I’m forever in your debt.

Well, what I saw was probably a precurser to Copland. I’ve seen Copland and it is distinctively different from what I was talking about. The version I saw was of the version 6 genre and it was maybe a year before the article I referenced was written. I was only trying to show you that Apple did, indeed, have preemptive versions of it’s OS that it was trying out and that these were a matter of public record.

A lot of modern PC-based industrial control is done with HP VEE (AKA LabView). Care to guess which platform LabView got it’s start on? Hint: It’s not Wintel-based and it’s not unix-based… Macs certainly are use in industrial control appliactions, just as PCs are used in graphics generation.