Posts by Dave Jewell

Vista – End of the Dream?

Spaghetti Code...

Don't think the leaked source was spaghetti code? Apparently Microsoft thought it was too. :-) Point your browser at the following:

http://online.wsj.com/article/SB112743680328349448.html

Of course, this raises the question of why Vista isn’t a whole lot better if the developers really started with a clean slate? The answer, of course, is that they didn’t start with a clean slate. I think this would have been impossible – all vestiges of backward app compatibility would have gone out the window. I think the bottom line is they probably made an effort to untangle some of the spaghetti, but not much. A complete rewrite? No way Hosay! And if they did spend all their time restructuring code, this also explains the lack of new goodies.

Dave

RE: The Author reads backward

Hi Clay. What does "reas" mean? ;-)

By the way, I *do* know a little Hebrew.

Shalom!

Dave

RE: Dishonest

Anonymous said: "Mr Jewell links to an article about the Windows 2000 code leak. That article actually says: 'Despite the [embarrassing comments], the quality of the code is generally excellent'. Mr Jewell obviously doesn't let the facts spoil a good argument."

I certainly have no intention to be dishonest. I'll admit it's been some years since I've examined the code. I found much it ugly and inelegant at the time. The same link also talks about the layers of hacks needed to support existing apps. I can only speak as I find. To you, it might be wonderful code...

One thing's for sure: "generally excellent" code can't be immediately equated with good design. An individual brick might be a great brick, but that doesn't mean you'll get a great house when you put a few million of em together...

Dave

RE: Nice article. Great article.

Eric A. Seiden said:

"It's so spot-on though my initial reaction was doubt and skepticism, I've actually blogged* your article and added some of my own comments. You're a bigger geek than me (I mean that as a compliment)"

Thanks for the blog entry Eric, and the compliment....I think! :-)) I checked your blog and I understand your comments r.e. Apple moving over to a completely new OS in the way they've done. MS haven't really done this since the move from W95/98/ME over to NT. That was the biggest platform transition for them, I think.

What surprises me is how many folks are latching onto the Apple v. Microsoft argument. I really only mentioned Apple as a side issue. Seems to me that if Apple had never existed, would that somehow make Vista more wonderful than it is? Nah.... ;-)

Dave

RE: Microsoft's Issue

Daniel Garcia said:

"Thought experiments aside, I think MS's problem is organization....."

I'd certainly agree that's a factor.

"But, with a modern commercial OS, that's not enough. You need the people organized as if their in the army preparing to fight a war."

Yes - you need strong organization, you need a shared vision of where you're going, and you need a very well defined goal in view.

Dave

RE: Vista end of a dream

Anonymous said: "Vista pretty much works out of the box on loads of different hardware doing just that."

Not with my Promise RAID controller it doesn't!

Dave

RE: Backward compatability

Giles Jones said: "Have a look at the pain the Mac world has had to ensure swapping processor families. Apple have done a good job and it's good to be able to boot Windows on a Mac laptop, but they couldn't have done so without having a smaller market and loyal fans."

What pain? :-) To be honest, there has been almost no pain in moving from PPC to Intel. The built-in Rosetta system (emulates PPC instructions on an Intel machine) coupled with the use of their "fat binary" architecture made it almost a non-event. The only real pain was in having to wait so long for a universal build of Creative Suite which - thankfully - is now here.

Dave

RE: CP/M OEM and MSDOS

Anonymous said:

"I still have the assembly listing written by Gates and Allen or those parts that OEM's had access to. Allen wrote the trancendental math for MSDOS. Apart from its historical value, is it worth anything?"

TBH, probably not. I think I've got that code as well, somewhere. ;-)

Dave

RE: Give us all the facts

Wayne Farnworth said: "And why do you think that is? Apple have half a dozen systems to make their software compatible with. Microsoft have the other billion. Stick to the facts please."

What "facts" are you missing? Linux installs are getting better and better and Linux has to work with many disparate hardware setups. You can't hide behind Apple's tightly focused hardware platform to justify Vista's crappiness.

Dave

Don't forget the ‘C’ in Objective-C

RE: Lovely <rubs hands>

Richard said: "I make my money taking 'performance is not a priority' systems, and making them work. So please dear programmer readers, don't listen to this guy. It doesn't apply to you. Systems scale vertically forever and ever. Piss-poor performance never harmed a system. Thank you."

Get back to Redmond where you belong! ;-)

Dave

RE: Fix your article

Paul said:

"I don't do much Win32, so I'm not sure about the Unicode issues brought up, but if the strings involved could be more than plain ASCII, you've got a whole other issue to deal with."

Paul -- under what circumatances do you anticipate that glGetString() will return something other than plain ASCII? Kristian Walsh points out that encoding issues are a red herring here -- I tend to agree. Worrying about getting non-ASCII strings from glGetString is a bit like writing your program so as to cope with the fact that strlen() might sometimes return a float! Do you program that way? ;-)

"...you could put the strstr in a loop, with each pass checking that the character preceding the match is either out of bounds or a space, and the character after the match is either a space or a NULL."

And if I were writing production code, I might do that, though, as I pointed out elsewhere, using gluCheckExtension() would be better. Let's try and remember that we're talking about code which might break if some hypothetical OpenGL extension gets added at some point in the future. It's rather a side issue to the main point.

Dave

RE: Understanding the Hardware Rant

Blain Hamon said: "*I was told about one VB-laden applicant who was given the test of making a function that counts the number of 1s in an int. Given 52, you'd return 3 because 52 is 110100b. He had the function convert the int into a string representation, i.e. "00110100" and then loop through the string, comparing character by character to '1'!"

LOL - I guess that's the sort of approach that I was arguing against.... ;-)

Dave

RE: At which point did efficiency become irrelevant?

Matt Kemp: "The attitude that 'I don't have to bother making my code efficient, so I won't' seems to be perpetuating through a lot of projects - which, as someone mentioned, is probably the reason that Vista needs 1GB of memory. When a Java program that requires a 60MB memory footprint which a lower-level language can do with 120KB at most, does it not make sense to use the more efficient version?

Well said, Matt; you're right to bring in the issue of memory footprint. Thus far, we've only been talking about execution speed but memory footprint is also important. I've spent some time digging around inside a lot of Cocoa apps over the last few months and I reckon that in many cases the code size could be very significantly reduced with a little thought -- see Part 2 of my article coming soon! :-)

So what, a lot of folks will cry? Nowadays, we've got gigabytes of cheap RAM, blah, blah, bah. But here again, lots of little code savings add up to big code savings.

Dave

RE: This book may be worthwhile

Tom Hall said: "I stumbled across this the other day.

http://www.oreilly.com/catalog/1593270658/. Write Great Code Volume I: Understanding the Machine. Write Great Code, Volume II: Thinking Low-Level, Writing High-Level.Cant give a full blown recommendation as I'm just starting as a programmer."

Thanks for that Tom - interesting. The title "Thinking Low-Level, Writing High-Level" fits in with what I was trying to get across.

Dave

RE: A blast from the past

Anonymous poster said: "I feel this is a great example of where the industry has moved on from in the past 30 years. Thankfully modern software developers now have a user focus rather than some ill-founded notion that they must write the most efficient code possible in the shortest number of lines."

There are really two things we seem to be talking about here. On the one hand, I'm talking about writing good efficient code (not necessarily in the shortest number of lines, BTW, although that does seem to be a characteristic of much Cocoa source!) On the other hand, you're talking about focusing on the end user.

Now, can you explain to me how you reckon these two things are mutually exclusive? Thing is, I like writing code that doesn't run like a one-legged dog in treacle. Why? Because I've got the end user in mind. Sorry, but not everybody has a dual-core Mac Pro you see....

Dave

RE: Speed?

Rik Hemsley said: "So, you've just 'optimised' some code which - from the sound of it - runs once, at application startup. Did you measure how much time you save at application startup? I'd be willing to bet you can't measure it because it'll be statistically insignificant."

Try reading the whole article Rik. In particular the bit which says: Determining the capabilities of the OpenGL system is something that you’ll typically do once only, in the initialisation part of your program. But looking for one string inside another is something that you might do tens of thousands of times inside a text crunching application.

Dave

RE: C isn't dead and C is at the core of Objective-C

Ian Michael Gumby said:

"Wow. Only in a mac centric world would I see this type of argument. Note: I guess I'm one of those old guys because I was a certified NeXTStep developer in '92. The point of the article was that developers should think about their task at hand and during the development process don't ignore the core of the language. Objective C has C at the core of the language, and if you really wish to be proficient at Objective C, you need to grok C."

Thank you Ian. It's nice to know that some folks understand the point I'm trying to get across. <wry grin>

Dave

RE: Bad Example

Anonymous Poster said: "Your replacement code doesn't check that the string is the entire extension name, so any string beginning with GL_EXT_texture_rectangle would be matched (for example, if a future GL_EXT_texture_rectangle2 extension was supported, the check would erroneously assume the earlier extension was present when it might not be)"

That's a good comment, although it's something of a side issue. The essential point was that doing the thing in C was a lot more efficient.

However, to address your point, I did a little googling and it turns out that a lot of folks do use the 'strstr' technique to check OpenGL extensions. There's a good example here:

http://www.koders.com/c/fid0577FFB7F9B63AEC5943E5354993FE6CC313B656.aspx

If you want to focus specifically on OpenGL extensions, I believe the *correct* approach is to use the gluCheckExtension routine which is documented here:

http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man3/gluCheckExtension.3.html

As Apple's documentation states, "Cases where one extension name is a substring of another are correctly handled."

Dave

RE: No, C really is dead

Anonymous Poster said: "There you "C guys" go again."

I don't really think of myself as a C guy. I'm also a Delphi guy, a C# guy, a Cocoa guy. Heck, I'm even a VB.NET guy sometimes, but I keep that one fairly quiet. ;-)

"As you hinted at at the very end of your Article, This is a different age. The text world is now UNICODE, it's far better to be experienced in how to handle Unicode the to save a few nanoseconds finding and using the C string library."

True, of course, but since glGetString doesn't return a Unicode string....

"ONLY if the "C" code was inside a LOOP would it save anything."

Which is why I cunningly mentioned looping tens of thousand of times inside a text crunching app. Except I didn't actually use the word loop - it was 'kinda implied. :-)

"In a higher level language like Objective-C it's Not Worth the Effort to optimize by using C."

Totally agree. Last thing I'd want anyone to do is go through a finished, well-written Cocoa app and intersperse the code with lots of C routines. The point is to think about what you're doing and -- for each specific case -- use the most efficient API routine (whether Cocoa or stdlib) based on the data types you're working with. 99.9% of the time, a Cocoa programmer will be working with NSString instances, so it makes sense to use the Cocoa API's in those cases.

"You C guys go to extremes to keep C relevant, it isn't, except for OS development, or when you can be sure you will never touch Unicode."

Methinks you didn't really grasp the point I was trying to make. Mea culpa....

"In your example, the programmer may have loaded an array to more easily view the properties in the debugger. And then kept it there because TIME is more expensive then processor cycles( outside a loop )."

See earlier comments about loops.

Dave

Uncle Mac takes A Cup of Cold Cocoa...

RE: Doing it the hard way

Thanks for that, Tim - lots of good comments there.

> Sure you can use the documentation for NSTableView

> and suporting classes to work out how to populate

> a table with data and sort it. But it would be a

> whole lot easier to use Cocoa Bindings.

Briefly, I'm deliberately *not* using Cocoa Bindings because I want to get to grips with 'barefoot Cocoa' itself first. I appreciate that some of this stuff can be simplified with CB, but - on a personal level - I want to thoroughly understand Cocoa itself, and how it's built on top of Carbon, before introducing an additional level of abstraction.

> You don't need properties. Allowing direct access

> to object data breaks the concept of encapsulation.

> Otherwise they are just accessor methods to the data.

Properties don't break encapsulation. But they are a more convenient way of doing things, if only from a syntactic sugar point of view. This is why Apple are introducing properties in ObjC 2.0 with Leopard. That said, I doubt that Apple will retrospectively "propertize" (for want of a better word!) the existing Appkit framework.

> The inspector palette is the equivalent of a

> property palette. If you create your own custom

> controls then you can also create a IBPalette plug-in

> so others can easily configure and use it within IB.

Yes - that's all understood. My point was that XCode/IB are not oriented towards component-based design. With Delphi or C# (for example), you create your new custom control and the job is done. With XCode/IB, you create your control, and you then *THEN* have to go through the completely separate process of creating an IB plug-in for it.

Why is this extra step needed? In one word, metadata. XCode/IB does not have a reflection mechanism whereby the properties/events of a new control can be interrogated and automatically displayed on the component palette. It is incredibly crude compared to .NET or VCL technologies.

> IB has many shortcomings, it hasn't had the major

> overhaul that ProjectBuilder -> XCode had, but I'd

> still take the Apple supplied controls over the

> Windows ones. Try creating a table view that has

> ruler bars in Visual Studio/.Net.

IB is being overhauled (somewhat) in Leopard. But it is still miles away from what it should be. When you say "Windows controls", which ones are you talking about? Check out the stuff available from www.devexpress.com (both VCL and .NET) and then try implementing that under Cocoa. You may be gone some time! :-)

> I've not used Delphi so I can't comment on that, but

> .Net and Visual Studio I do use regularly. Personally

> I prefer the NeXT way.

Personally, I don't. ;-)

> Using Visual Studio in the way you describe results

> in disorganised code and duplication. Two buttons

> that perform ultimately the same action must still

> have their own handler, even if it's only a wrapper

> to a worker method.

It sounds like you need to get deeper into VS.NET. It is actually dead easy with .NET and Delphi to have multiple buttons pointing at the same handler, and use the sender method to perform disambiguation in the code.

> ProjectBuilder and InterfaceBuilder were way ahead

> of the times when they were produced in 1986. Since

> then other tools caught up, and even bettered

> them in some areas.

I'd agree with that, though I'd tend to replace "some" with "many". ;-)

> XCode 2.0 will make live even easier for the developer

> to do cool stuff. CoreAnimation is amazing. If you

> want to have a play with the precursor in Tiger,

> open up the Quartz Compositor app installed as part

> of the Dev tools and play.

No disagreement that Quartz and CoreAnimation are awesome compared to what's on the PC. I already have Leopard, by the way :- I have ADC membership.

> Garbage collection is added to Objective-C, if you

> like that sort of thing.

I do. ;-)

> In all I think Cocoa is still strong in all the areas

> it was originally. Other advances have happened in the

> developer world and XCode will have to play catch up.

Agreed.

> But I feel better working with a very well designed

> framework with tools that aren't the best in every way,

> than working with an inferior framework in better tools.

I don't believe that .NET and VCL are inferior frameworks to Cocoa. Quite the reverse. I would prefer to use the best tools with the best framework but unfortunately, neither is available for the Mac right now. Hopefully, that will change....

> From what I know of Delphi, it's basically object pascal. > I can't imagine any of the magic implemented in the

> Cocoa frameworks being implemented in such a strongly

> typed language.

Strongly-typed languages are not necessarily a bad thing - you would be surprised how much magic can be achieved. ;-)

Uncle Mac

Frameworks...

> The Nexties definitely arrived at Apple in their own

> RDF and have shown little signs of looking outside

> since to realise the rest of the world has moved on

> a bit in the last decade.

Very true. I'm a huge fan of Delphi and their VCL framework which effectively puts an elegant, OOP wrapper around the bizarre Win32 API. Apple need something similar.

I suppose you could say that Carbon equates to the Win32 API, but in my opinion, Cocoa is no match for the VCL library or the .NET frameworks.

Uncle Mac

Giving some Juce to cross-platform tools

RE: Thanks very much!

Hi Julian - glad you liked the review. The idea of a beer sounds good. The idea of several sounds even better. Just need to figure out where the Reg's local hostelry is located.... :-)

Good to hear the Apple menu bug is fixed already. I expected nothing less!

Cheers,

Dave

RE: GTK & Gnome please

It's on the to-do list. As I think you imply by mentioning all the available bindings, it would be good to cover GTK++, GTK#, etc, at the same time.

Cheers,

Dave

Cross platform development for Windows and Mac OS X

The Catch with Qt [Reply]

As someone else has said, it's perfectly possible to use STL alongside Qt. In fact, the standard 'configure' script will build the libraries with STL support *by default*. If you don't want STL support, then you have to use the -no-stl flag when configuring the system.

Implementing exceptions in a cross-platform manner is, I believe, more challenging, but if you want to throw/catch exceptions in your own code, it's not a problem.

Dave

Agree about Interface Builder [Reply]

Nice to know I'm not the only one who feels that way.

For what it's worth, I'm quite looking forward to Leopard and Objective-C 2.0. From what I can see, there are some big improvements not only to the language (at last ---- properties!!!) but also to XCode and Interface Builder.

Yeah, I'd still prefer Delphi on the Mac, but.... :-)

Dave

X-Platform Design [Reply]

Hi Julian. For years, I was equally unconvinced about cross-platform dev. Many of the available tools used a 'lowest common denominator' approach and looked uniformly awful no matter what platform they were running on. But that's not true of Qt or other modern toolsets such as wxWidgets.

> I remain unconvinced about the notion of

> cross-platform development, in that there is a lot

> more than separates Mac, Windows, KDE and Gnome

> than their widget set. For instance, on OS X you've

> got AppleScript and Automator as front ends onto OSA,

> and as far as I understand it there is no bridge

> from Qt4 to the OSA events.

True, of course, and Qt does try to implement platform-specifics where it makes sense to do so. For example: http://doc.trolltech.com/qq/qq18-macfeatures.html.

> And of course there is the issue when you drag a file

> into a window and find that it doesn't accept it, even

> though the program can edit it if you open via the

> File menu. (To be fair, that can happen on native > applications too).

On the Mac, Qt uses Carbon to receive drag/drops from the Finder or other applications. On Windows, it uses OLE. You get a "native" experience whatever platform you're using. More here: http://doc.trolltech.com/3.3/dnd.html

> Looks indistinguishable is one thing, feels

> indistinguishable is another.

Feels pretty indistinguishable to me... ;-)

Dave

Not So Weird [Reply]

I have Hillegass' book which -- I agree -- is better than the O'Reilly book. But....I still think Objective-C is weird. Even when it's not being weird, it's always being verbose. By the time I've finished typing "NSMutableString", I've forgotten what I was trying to do in the first place. :-)

Language aside, the same is true of the Apple dev tools. In Delphi, or C++ Builder or even [whisper] .NET, I can double-click a button on a design-time form and -- bang! -- there I am sitting in a freshly created event handler; all I have to do is type the code that I want to execute when the button clicks. Easy-peasy.

In fairness, I don't think the Qt Designer is as smooth or intuitive as Delphi, etc, but I do find it a lot more "obvious" than Apple's own tools.

Dave

What you're not telling us... [Reply]

Hi Drarok - thanks for the comments. Applications created with Qt do indeed run natively on all the platforms of interest. There is a X11 version of Qt available (Qt/X11) but I've never used it, and nor do I wish to. :-)

As you say, one of the key things for Mac users is to be able to just take an app, double-click it from the Finder and have it run. Or drag it into the Applications folder, and it just works. I can confirm that you can do exactly that with a Qt-built application.

Dave