It sounds like an updated version of Peopleware, another excellent book you'd like your manager to read. - Rich

I don't know about ignorance, and I don't care about apathy, but I simply will NOT put with intolerance!

Chris Losinger wrote: 5,379,129 Thanks. I took a look at it, and I think Apple would have a VERY difficult time defending this one. It really doesn't claim much more than the equation result = ((1-mask)*source)+(mask*destination) which is so painfully obvious to anyone with a background in image processing (or mathematics in general) that it isn't even worth thinking about. I'm sure this patent could be fought on three grounds: (1) obviousness, (2) prior art, and (3) flaws in the patent itself. (For example, the above equation is repeatedly referred to as a "boolean expression", and a figure which shows the use of the algorithm to draw patterned text couldn't possibly result from an application of the algorithm.) For the record, I am not opposed to software patents in principle, but I think we need far stricter standards for what is and isn't patentable. Part (most?) of the problem also lies with the fact that the patent office simply isn't equipped to properly evaluate software patents. - Rich I don't know about ignorance, and I don't care about apathy, but I simply will NOT put with intolerance!

Navin wrote: You can try converting your app to a cross-platform C++ library, such as wxWindows (which has good Windows and Linux support, and improving Mac support). It is in many ways similar to MFC, but if you have a large app of course this will take some time. The good thing is, it can coexist with MFC, so you may be able to do it in pieces. I have a fair amount of cross-platform (Windows/Mac) experience, and IMHO the best way to write a cross-platform application is to abstract out the user interface, and write the rest as portably as possible. Then implement the UI portion using a good platform-specific class library for each platform (e.g. MFC on Windows, PowerPlant on the Mac). Yes, it is more work, but it won't scream "THIS IS A PORT" to savvy users. BTW: separating the UI from the core functions of the app has plenty of other advantages, like making it easier to add scripting. - Rich I don't know about ignorance, and I don't care about apathy, but I simply will NOT put with intolerance!

Chris Losinger wrote: this formula appears about one 'page' down in the patent spec (claim 8): result=((1-mask)*source)+(mask*destination); There are two basic ways of fighting a patent, and this is subject to both. First of all, a patent cannot be something which would be obvious to any practitioner in the field. This is a simple linear combination of two values, and would (IMHO) be the obvious way to blend two values using a mask in the range [0.0 .. 1.0]. Second, a patent must be original. I'm guessing I could find prior art for this in no time flat. The way I see it, this was a lack of foresight on Apple's part. Why stop at a simple linear combination of two values? There may be situations where a non-linear combination is appropriate, and I would think that a patent involving a non-obvious non-linear function that is useful in particular circumstances _could_ be patentable. BTW: does anyone have a patent number for this? I'd like to look it up to see if what they're claiming really is this simple. - Rich I don't know about ignorance, and I don't care about apathy, but I simply will NOT put with intolerance!

I'll see what I can come up with. Unfortunately, since I wrote my original message, it occurred to me that at least 2 of the 5 examples I had in mind are probably proprietary to the company I work for, and 2 others might be. I may have to think of some others. But hey, I gotta have _something_ to think over this long weekend.... I don't know about ignorance, and I don't care about apathy, but I simply will NOT put with intolerance!

I first came here awhile back looking for information on MMX programming, and found none. Now that I've been working with MMX for a bit, I was wondering if people here would be interested in a tutorial article. If so, I may be able to find the time to write one. Let me know. (BTW: If you're interested in MMX, blow the bucks on Intel's compiler. It implements MMX support VERY nicely.) - Rich I don't know about ignorance, and I don't care about apathy, but I simply will NOT put with intolerance!

Nish [BusterBoy] wrote: Colin Davies wrote: Or did you think this Post was about that singer chappie. Duhhhh. Yeah, I did..... That's odd, I assumed he was talking about the guy who does the beer reviews. :) I don't know about ignorance, and I don't care about apathy, but I simply will NOT put with intolerance!

All rise for a reading from the C standard. In section 6.3.13, we read: "Unlike the binary & operator, the && operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares equal to 0, the second operand is not evaluated." You may be seated. (BTW: I'm not a language lawyer, but I play one at work.) There is similar wording for the || operator. Any compiler that wishes to call itself a C compiler must implement short-circuit evaluation for && and ||. Stroustroup's ARM has similar wording, though I'm not sure if short-circuit evaluation still applies to an overloaded operator&& or operator||. Getting back to the use of goto: personally, while I'm not manic about avoiding it, I also have never used one since I started using exceptions. (I used to use them a lot for jumping to appropriate clean-up code.) - Rich I don't know about ignorance, and I don't care about apathy, but I simply will NOT put with intolerance!