Slashdot Mirror

An operating system is not only the kernel and a bunch of device drivers! We didn't even start the most important project of them all: consolidating our manpower and our technologies. We could really use a component object model. The good news is: we have that technology. The bad news is we are working on more than one.. XPCom part of the Mozilla web browser project and ORBit part of the Gnome Desktop project. Speaking of desktops, like Doug said, we are working on two competing projects, Gnome and KDE. We already have all the technologies Doug thinks put Microsoft ahead in the game. Mainframe / AS400 connectivity? Linux-SNA. A kick-ass web browser? Mozilla vs. Internet Explorer. Word processor, spread-sheet, Business presentations? Star-Office. I could go on and on but I guess you get the picture. What we have to do now is to consolidate all that into a coherent system.. I want to be able to manipulate Star-Office spread-sheets using a system-wide scripting language (how about perl? python?..?).. I want to be able to embed that spread-sheet into any application, not only into Star-Office's word processor (XPCom? ORBit?) I want to be able to use the same printer driver from Star-Office and any other application on the system (anybody working on a printing subsystem for X? Or do we put it into GTK's GDK?).. There's still a lot of work for us to do before we can really kick their asses on the desktop. I'm looking forward to both.

AFAIK, the only things that have really happened on this day in history was the announcement of a certain endless OSS project three years ago, and the resignation of a certain lead on that project...

--

Opera? Mozilla? NetPositive? Lynx? That seems to be pretty good right there...

Done this way, it doesn't matter if the browser code has security holes because the browser code is not trusted. The mandatory security protections of the OS prevent it from doing anything. This is the right way to do it, and the only one that will work.

That works if you only use the web for fun and/or reference, but if you type your credit card number into any website, you should hope that other sites aren't able to read your cookie file or hijack your browser to send everything you type into other sites to the malicious site. I guess you could tell the user to restart their browser after visiting any questionable site and throw out the cookies file between each session, but I doubt it would be worth the effort and loss of functionality.

By the way, preventing the browser from mucking with your files wouldn't solve privacy problems such as bug 57351 (present in both IE and Mozilla).

I think doing cross-platform development is of critical importance both to the software developer and the public. Find out why at:

• Freeing the Developer from OS Vendor Shackles

You can find a list of many application frameworks in several languages, many of which are cross-platform, and many of which are free or open source, at the GUI Toolkit, Framework page.

Mike

* Security in *nix sucks

I'm hoping that you mean Linux security, since this isn't true at all for many other UNIX OSes. For Linux, I think the security is good enough for what it is, when it is used right. The problem is that many applications and servers don't use it right. POSIX.1e-style capabilities (see Linux-privs - POSIX.1e Capabilities for Linux, http://www.sourceforge.net/projects/linux-privs/) are probably the answer. A more legitimate qualm with the *nix model is that it is coarse-grained. I think at least a handful of UNIX OS's have responded with support for Access Control Lists, which provide more fine-grained file access (see Extended Attributes and Access Control Lists for Linux, http://acl.bestbits.at).

* X Windows sucks

The X Window System catches a lot of criticism, some of it well-deserved. Most of it, however, is purely inane. It works very well, all things considered. Most of the technological deficiencies (i.e., mainly rendering technology) are resolved with modern extensions. Naturally, there are better ways to do it. We could have a much better architecture. But that's all hindsight. What we're looking at is not a transition that would be based on advantages, but on disadvantages. Until the limitations of the X Window System outstrip the convenience of using what's already there and well-supported, we have X. But Xfree86 is good enough for now. There might be alternatives in the future (Berlin, http://www.berlin-consortium.org/).

* the xterm gui-cli interface sucks

I'm stumped. You determine that you need the CLI for some task while you're in the GUI. What better interface can you get than actually getting the CLI in the GUI? (Which is what Xterm does for you.)

* all the shells suck ...

They seem to have everything I need and want, and more. Filename completion (with cycling through potential matches), redirection (especially with file descriptors, as in bash), good line editing, conditions and looping, scripting, ... Maybe I'm thinking inside the box, but I can't think of anything that I've needed to do that hasn't been made easy (if not trivial) by some shell.

* file system in *nix sucks

Well, it's not as if every UNIX uses the same file system. I don't understand this claim, really. Are you arguing against heirarchical file systems or against the file systems themselves?

* netscape in *nix sucks

It performs very well for me, as do Mozilla (http://www.mozilla.org) and Konqueror (Konqueuror). There's a lot of hype around Opera (Opera), but I've never tried it. There are particular deficiencies in each of these, of course, but most of them perform the task of web browsing well enough. Not to forget, of course, Lynx (Lynx).

Anyway, there are legitimate issues. Standardized package management on Linux would be nice, ACLs/Capabilities would be nice... And I'm always up for a new Window Manager or Desktop Environment. I use Sawfish/GNOME (Sawfish, http://sawmill.sourceforge.net/; GNOME, http://www.gnome.org/). But, eh, keep complaining: anything that gets me new toys to play with can't be too bad.

I could make that list even longer with many more projects that Red Hat either funds, maintains, develops or contributes to, but I think I've already proven my point.

On the contrary, my personal site (which is built with compliant HTML 4.0 and CSS) looks just fine on a wide variety of devices. This includes Mozilla, iCab, WebTV, Lynx, and AvantGo. Separate content from style and you'll never go wrong.

Mozilla can be found at http://www.mozilla.org.

Bleck.. WinCE?!

I guess i cannot blame corporations for choosing (or being bullied..?) into using this POS OS, all i'm saying is: dont expect me to shell out any hard-earned dough for something as unstable/laughable as WinCE.

I actually saw one guy's WinCE-powered handheld freeze (Gray Screen of Death?) once.. *LOL* My Palm is worth 10 times anything WinCE powered i assure you.

Just a thought.. :-)
BTW: Mozilla 0.8 is mighty fly if you havent used it yet!

--

There are a few major issues to deal with before Mozilla is ready for a final release (in no particular order). These issues have recently received considerable Netscape engineering resources.

A new "outliner-widget" has been created (Thanks to Mozilla diety Dave Hyatt) to take care of mailnews performance. However, implementing it (under the MailNews_Performance_20010208_BRANCH branch) has been a huge undertaking. According to a recent newsgroup posting, the branch should land in around 2.5 weeks (Perhaps March 21st ?). For more info, see the Mailnews status page.

Necko (Mozilla's networking/cache component) is being redesigned as well.

In addition to these projects, the XSLT team plans to land their Transformiix branch by the mozilla 0.9 release, and the porkjockeys team is looking for ways to reduce startup time.

The added development cycle (mozilla 0.8.1) is going to give Mozilla QA 5 more weeks of testing after these changes land. It is these changes that will put Mozilla in a position to fully compete with other browsers.

Personally, I think that this delay is great! Mozilla 1.0 is going to be much more mature because of it.

There are a few major issues to deal with before Mozilla is ready for a final release (in no particular order). These issues have recently received considerable Netscape engineering resources.

A new "outliner-widget" has been created (Thanks to Mozilla diety Dave Hyatt) to take care of mailnews performance. However, implementing it (under the MailNews_Performance_20010208_BRANCH branch) has been a huge undertaking. According to a recent newsgroup posting, the branch should land in around 2.5 weeks (Perhaps March 21st ?). For more info, see the Mailnews status page.

Necko (Mozilla's networking/cache component) is being redesigned as well.

In addition to these projects, the XSLT team plans to land their Transformiix branch by the mozilla 0.9 release, and the porkjockeys team is looking for ways to reduce startup time.

The added development cycle (mozilla 0.8.1) is going to give Mozilla QA 5 more weeks of testing after these changes land. It is these changes that will put Mozilla in a position to fully compete with other browsers.

Personally, I think that this delay is great! Mozilla 1.0 is going to be much more mature because of it.

There are a few major issues to deal with before Mozilla is ready for a final release (in no particular order). These issues have recently received considerable Netscape engineering resources.

A new "outliner-widget" has been created (Thanks to Mozilla diety Dave Hyatt) to take care of mailnews performance. However, implementing it (under the MailNews_Performance_20010208_BRANCH branch) has been a huge undertaking. According to a recent newsgroup posting, the branch should land in around 2.5 weeks (Perhaps March 21st ?). For more info, see the Mailnews status page.

Necko (Mozilla's networking/cache component) is being redesigned as well.

In addition to these projects, the XSLT team plans to land their Transformiix branch by the mozilla 0.9 release, and the porkjockeys team is looking for ways to reduce startup time.

The added development cycle (mozilla 0.8.1) is going to give Mozilla QA 5 more weeks of testing after these changes land. It is these changes that will put Mozilla in a position to fully compete with other browsers.

Personally, I think that this delay is great! Mozilla 1.0 is going to be much more mature because of it.

There are a few major issues to deal with before Mozilla is ready for a final release (in no particular order). These issues have recently received considerable Netscape engineering resources.

A new "outliner-widget" has been created (Thanks to Mozilla diety Dave Hyatt) to take care of mailnews performance. However, implementing it (under the MailNews_Performance_20010208_BRANCH branch) has been a huge undertaking. According to a recent newsgroup posting, the branch should land in around 2.5 weeks (Perhaps March 21st ?). For more info, see the Mailnews status page.

Necko (Mozilla's networking/cache component) is being redesigned as well.

In addition to these projects, the XSLT team plans to land their Transformiix branch by the mozilla 0.9 release, and the porkjockeys team is looking for ways to reduce startup time.

The added development cycle (mozilla 0.8.1) is going to give Mozilla QA 5 more weeks of testing after these changes land. It is these changes that will put Mozilla in a position to fully compete with other browsers.

Personally, I think that this delay is great! Mozilla 1.0 is going to be much more mature because of it.

I noticed that the faq is down (blank). I have been using mozilla for over a year now (and at least 8-10mo as primary browser), relying on nightly builds for the latest-gratest.

When 0.8 was announced, I decided to go with it, downloading my first milestone since ...M16 probably. I noticed that it was VERY buggy. It now seems to me that the most stable builds of mozilla are the last nightly before a milestone. why? I thought the whole point of the nightly builds was to test out new features, not to wait for a milestone to churn them out... milestones are supposed to be the most stable, not the least!

I wanted to look in the FAQ for an explanation of when/why milestones are marked for release and what the process is as a whole. Since it isn't in the FAQ, could the /. community help me out here?

There is quite a bit of work going on to speed up the mailnews component. Dave Hyatt came up with a new "outliner widget" that will be increasing scrolling and such to NC 4.x speeds.

In case you are interested, see the Mailnews Status page.

According to a recent newsgroup posting, the new branch should be landing in about 2.5 weeks for testing in the nightlies.

This memory cache bug is (imho) worth voting for. Other worthwhile bugs: mozilla should not need write-access to binary directory, url box doesn't update after a theme switch, and best of all, XBL is killing babies and german tourists.

As a side note, voting for a bug will add you to the cc list for that bug. So be ready.

This memory cache bug is (imho) worth voting for. Other worthwhile bugs: mozilla should not need write-access to binary directory, url box doesn't update after a theme switch, and best of all, XBL is killing babies and german tourists.

As a side note, voting for a bug will add you to the cc list for that bug. So be ready.

This memory cache bug is (imho) worth voting for. Other worthwhile bugs: mozilla should not need write-access to binary directory, url box doesn't update after a theme switch, and best of all, XBL is killing babies and german tourists.

As a side note, voting for a bug will add you to the cc list for that bug. So be ready.

This memory cache bug is (imho) worth voting for. Other worthwhile bugs: mozilla should not need write-access to binary directory, url box doesn't update after a theme switch, and best of all, XBL is killing babies and german tourists.

As a side note, voting for a bug will add you to the cc list for that bug. So be ready.

This memory cache bug is (imho) worth voting for. Other worthwhile bugs: mozilla should not need write-access to binary directory, url box doesn't update after a theme switch, and best of all, XBL is killing babies and german tourists.

As a side note, voting for a bug will add you to the cc list for that bug. So be ready.

Of course, that's not to say that I don't like Mozilla. In fact, I make a point of downloading the nightly builds every day :)

PS For those Mozilla enthusiasts in the audience, you may find the daily build comments interesting. There, the page's author lists the various bugs that were fixed in the day's build.

Alex Bischoff
---

Of course, that's not to say that I don't like Mozilla. In fact, I make a point of downloading the nightly builds every day :)

PS For those Mozilla enthusiasts in the audience, you may find the daily build comments interesting. There, the page's author lists the various bugs that were fixed in the day's build.

Alex Bischoff
---

--

On http://truc.hypermart.net/, a "random" link exchange site, I see an iframe, not just image. Iframe ads are annoying for several reasons, although I doubt advertisers use them just to be annoying.

- IE4 (but not later versions) will replace an entire page with a placeholder page if you go to a site with a missing iframe.

- If you try to block the hoster of an iframe using a "hosts" file and you use Mozilla as your browser, you get an alert each time you visit a site with a missing iframe. Hopefully this will be fixed in bug 28586 by implementing placeholder pages for all missing pages.

- Iframes will probably allow cookies for a short amount of time after browsers fix a similar problem for images, simply because it takes more coding to fix the problem for iframes. (Have any major browsers fixed the cookies-on-images bug?)

- Iframes allow Java ads, such as the infamous punch-the-monkey ad. (Jason Kersey removed all ads from mozillazine.org, and I think he did that because people complained about that ad so much.) LE doesn't seem to use Java ads at this point, although I have seen several "fake dialog" ads there.

I also heard someone tell me that some linkexchange ads were <script src="something.linkexchange.com"> at some point in order to allow linkexchange to update the entire banner code whenever they needed to. I think this might have just been a rumor -- can you imaging what a cracking target that would turn linkexchange into? Can anyone confirm or deny this rumor?

Btw, why is it that when I click a linkexchange banner, the site linked to almost never has a linkexchange banner itself?

Well, if you're willing to try out Mozilla, they've added hidden preferences in release 0.8 that will let you turn that off. They say that there will be a UI for it soon. The description can be found here.

Trust me. It works great. I've been using Mozilla as my regular browser since 0.7 came out, and it's come a long way since the M## builds.

Well, my project is using OpenGL and OpenAL as the 3D library and audio library, respectively. For a 2D library, OpenPTC is always nice, but you can also try faking some 2D under OpenGL. That is the first step on getting your software cross-platform.

Input is not as problematic as you'd think and is relitively easy to port across platforms. Especially for joystick, mouse, and keys.

Right now I'm using GLUT to handle input and windowing for the actual game executable and wxWindows for the other tools. I'm tempted to switch entirely over to wxWindows, although it doesn't have an up-to-date Mac port. The problem with GLUT is that it isn't fast and isn't powerful, but it's great for getting things up and running quickly.

But as long as you just have to rewrite the program that popps up a window and sets up the OpenGL/OpenAL contexts, it's not as big as starting in DirectX and porting to GL. Just carefully architect the basic framework and there won't be any problems.

Also note that Mozilla's C++ Portability guide may prove to be useful. The goal is to think about portability from the beginning.

In the latest Mozilla-builds (at least it is in Moz 0.8), you can disable pop-ups by adding the line user_pref("capability.policy.default.windowinterna l.open","noAccess"); to your user-preferences. (See here for the details along with some other neat tricks to switch off animated GIFS.) Pretty soon these options should show up in the Mozilla preferences-menu so that one can switch them on without even opening a text-editor.

Since they seem to be citing specific sizes, this could work to our advantage. It's easy to use the The Proxomitron to filter anything by custom HTML matching rules, and easy to use KillAd to bock specific sizes of popups of Windows. And you can block popups from the browser level in Mozilla too.

But what does this tell us about advertisers? They're realizing that people are learning to ignore and block the standard banners. I'm sure that they see this as moving into something that's bigger and better. The 160 x 600 pixel ads should be interesting because they're really tall. People are used to seeing wide banner ads, and we haven't learned to instinctively ignore big tall images.

And what does this tell us about netizens in general? Most people are slow to react to ads and slow to try to block them...it's been what, almost a decade now since banners in their current form came into use? CNET's been using those humongous ads for a while now and I haven't added a filter to my Proxomitron yet to block them...and I'm a slashdotter! I just press the stop button in mozilla before the ads loads.

So what do we do know? If you like ads, the fine. Watch them and see them steal your the data you put into website forms and send it to doubleclick. And if you don't, the update your filtering proxys and promote junkbuster. I don't know about you, but I'm not going to let my tiny 31.2k modem connection (nothing else available here) be saturated by my personal info going upstream and their ads going downstream. That's just what I think anyways.

A side note: My finger got caught in a cheese slicer yesterday and as a result I might have made a few typos. I hope I corrected them all.

O'Toole's Commentary on Murphy's Law:

It has to work on Windows...

Apple has announced it has no plans to support a JVM later than 1.1.8 on the classic Mac OS so you can't use all those great collection classes in Java 1.2 and be cross platform! (See Apple's Java Developer page and scroll down to where it says "Mac OS Classic Java".)

Use a cross-platform application framework. That way you can program on Linux, Mac, BeOS, Windows or maybe even QNX and deliver for all those schoolkids running Windows ME on their parents' PC.

One such framework, for C++, is ZooLib. There are many others, as you can see from The GUI Toolkit, Framework Page.

Read about why it's important to write cross-platform code.

I'm most familiar with ZooLib, because I've been working with it on the products I write for my clients, and I helped ZooLib author Andy Green prepare it for open source release late last year under the MIT License.

ZooLib offers all of the following implemented as C++ classes:

• Multithreading, with cross-platform C++ thread classes and various kinds of locks (simple mutexes, reader/writer locks) - multithreading is important for something like a servent. For systems like the Mac OS that don't have preemptive threads it has a handrolled thread scheduler.
• GUI, with a uniquely flexible layout method. The widgets are rendered by platform appropriate renderers, and you can make custom widgets. There's a renderer that will call through to the Appearance Manager on the Mac OS, if it's running.
• platform-independent TCP networking, it's implemented in terms of sockets on Linux, WinSock on Windows, sockets on BeOS and MacTCP on Mac OS. I think Open Transport may be working too on the Mac, I'm not sure - but on all platforms you use the same C++ classes for your networking with no platform-specific client code needed.
• Thread-safe reference counted smart pointers, for quick, efficient memory management that's free of leaks.
• Extensive debugging support - assertions in core components and a debugging memory manager, handy macros for assertions and the like
• Single-file database format with C++ interface. Create ZDatabase objects with ZTables in them. Much zippier than SQL and more pleasing to the object-oriented soul.
• File objects - you instantiate a ZFile object from a ZFileRef object, then use its Open, Close, Read and Write methods
• Platform-specific file open and save dialogs with an API that's consistent with the rest of ZooLib. Filter by filetype on the Mac or filename three letter extension on windows. While ZooLib is cross-platform, it breaks out into platform specific code in cases like this where it's appropriate, in a way that's considered entirely sacreligious by the Java community.
• Streams that can be chained to provide filtering, somewhat like the iostreams classes in the C++ standard library but more appropriate for use with binary data. This is how you typically read or write to a file or network connection.
• Handy preprocessor macros to deal with platform specific code or selecting options like debug builds.
• Offscreen graphics buffers that may be manipulated directly via pointers or accessed in a manner that is transparent to the bit depth via GetPixel and SetPixel calls. All platforms have the same API that provide a wrapper around platform bitmap buffers. I believe there's a purely homegrown in-memory implementation, plus platform implementations bounds to the native GUI layer like GWorlds on the Mac OS.

ZooLib 0.81 is known to build with MetroWerks CodeWarrior on Windows and Mac OS, gcc on Linux, and gcc on BeOS for Pentium.

If you use CodeWarrior you can cross-compile and cross-debug; check out Thursby Software for some filesharing solutions that work well for this. (Tip - on Windows, select the "MacBinarize" post-linker in the target linker prefs when building a Mac target - you also need to derez all your resource files and include them as Rez text source).

While it should ultimately work, there are known build problems with BSD, CodeWarrior for BeOS PowerPC and Visual C++ on Windows. These are all being worked on and full support for all these platforms is expected before long.

Other cross-platform frameworks I'd like to note are:

• The Adaptive Communications Environment for cross-platform networking
• GTK - yes, that's right, GTK! but you must forgo using XLib calls and POSIX calls that are not in the ANSI C Standard Library
• The Netscape Portable Runtime for the non-GUI aspects of cross-platform development
• The Mozilla XPToolkit for cross-platform GUI
• Mozilla Netlib for network and file stream access
• Mozilla XPInstall for cross-platform installation, packaging and updating.
• Also check out AbiWord, a great cross-platform WYSIWYG word processor that's open source, with an open file format. As far as I know the only product coded in AbiWord's XP framework is AbiWord itself, but it's worth looking into for another look at how people architect these things.

People often mistake these problems for valid arguments that one should not do cross-platform development, or perhaps not render your own widgets when doing so but depend on platform specific ones (like AWT vs. Swing), but I think the lightweight, well architected, efficient and easy to use ZooLib answers those arguments very eloquently.

Help me teach the Free Software community to write quality code.

Mike

It has to work on Windows...

Apple has announced it has no plans to support a JVM later than 1.1.8 on the classic Mac OS so you can't use all those great collection classes in Java 1.2 and be cross platform! (See Apple's Java Developer page and scroll down to where it says "Mac OS Classic Java".)

Use a cross-platform application framework. That way you can program on Linux, Mac, BeOS, Windows or maybe even QNX and deliver for all those schoolkids running Windows ME on their parents' PC.

One such framework, for C++, is ZooLib. There are many others, as you can see from The GUI Toolkit, Framework Page.

Read about why it's important to write cross-platform code.

I'm most familiar with ZooLib, because I've been working with it on the products I write for my clients, and I helped ZooLib author Andy Green prepare it for open source release late last year under the MIT License.

ZooLib offers all of the following implemented as C++ classes:

• Multithreading, with cross-platform C++ thread classes and various kinds of locks (simple mutexes, reader/writer locks) - multithreading is important for something like a servent. For systems like the Mac OS that don't have preemptive threads it has a handrolled thread scheduler.
• GUI, with a uniquely flexible layout method. The widgets are rendered by platform appropriate renderers, and you can make custom widgets. There's a renderer that will call through to the Appearance Manager on the Mac OS, if it's running.
• platform-independent TCP networking, it's implemented in terms of sockets on Linux, WinSock on Windows, sockets on BeOS and MacTCP on Mac OS. I think Open Transport may be working too on the Mac, I'm not sure - but on all platforms you use the same C++ classes for your networking with no platform-specific client code needed.
• Thread-safe reference counted smart pointers, for quick, efficient memory management that's free of leaks.
• Extensive debugging support - assertions in core components and a debugging memory manager, handy macros for assertions and the like
• Single-file database format with C++ interface. Create ZDatabase objects with ZTables in them. Much zippier than SQL and more pleasing to the object-oriented soul.
• File objects - you instantiate a ZFile object from a ZFileRef object, then use its Open, Close, Read and Write methods
• Platform-specific file open and save dialogs with an API that's consistent with the rest of ZooLib. Filter by filetype on the Mac or filename three letter extension on windows. While ZooLib is cross-platform, it breaks out into platform specific code in cases like this where it's appropriate, in a way that's considered entirely sacreligious by the Java community.
• Streams that can be chained to provide filtering, somewhat like the iostreams classes in the C++ standard library but more appropriate for use with binary data. This is how you typically read or write to a file or network connection.
• Handy preprocessor macros to deal with platform specific code or selecting options like debug builds.
• Offscreen graphics buffers that may be manipulated directly via pointers or accessed in a manner that is transparent to the bit depth via GetPixel and SetPixel calls. All platforms have the same API that provide a wrapper around platform bitmap buffers. I believe there's a purely homegrown in-memory implementation, plus platform implementations bounds to the native GUI layer like GWorlds on the Mac OS.

ZooLib 0.81 is known to build with MetroWerks CodeWarrior on Windows and Mac OS, gcc on Linux, and gcc on BeOS for Pentium.

If you use CodeWarrior you can cross-compile and cross-debug; check out Thursby Software for some filesharing solutions that work well for this. (Tip - on Windows, select the "MacBinarize" post-linker in the target linker prefs when building a Mac target - you also need to derez all your resource files and include them as Rez text source).

While it should ultimately work, there are known build problems with BSD, CodeWarrior for BeOS PowerPC and Visual C++ on Windows. These are all being worked on and full support for all these platforms is expected before long.

Other cross-platform frameworks I'd like to note are:

• The Adaptive Communications Environment for cross-platform networking
• GTK - yes, that's right, GTK! but you must forgo using XLib calls and POSIX calls that are not in the ANSI C Standard Library
• The Netscape Portable Runtime for the non-GUI aspects of cross-platform development
• The Mozilla XPToolkit for cross-platform GUI
• Mozilla Netlib for network and file stream access
• Mozilla XPInstall for cross-platform installation, packaging and updating.
• Also check out AbiWord, a great cross-platform WYSIWYG word processor that's open source, with an open file format. As far as I know the only product coded in AbiWord's XP framework is AbiWord itself, but it's worth looking into for another look at how people architect these things.

People often mistake these problems for valid arguments that one should not do cross-platform development, or perhaps not render your own widgets when doing so but depend on platform specific ones (like AWT vs. Swing), but I think the lightweight, well architected, efficient and easy to use ZooLib answers those arguments very eloquently.

Help me teach the Free Software community to write quality code.

Mike

It has to work on Windows...

Apple has announced it has no plans to support a JVM later than 1.1.8 on the classic Mac OS so you can't use all those great collection classes in Java 1.2 and be cross platform! (See Apple's Java Developer page and scroll down to where it says "Mac OS Classic Java".)

Use a cross-platform application framework. That way you can program on Linux, Mac, BeOS, Windows or maybe even QNX and deliver for all those schoolkids running Windows ME on their parents' PC.

One such framework, for C++, is ZooLib. There are many others, as you can see from The GUI Toolkit, Framework Page.

Read about why it's important to write cross-platform code.

I'm most familiar with ZooLib, because I've been working with it on the products I write for my clients, and I helped ZooLib author Andy Green prepare it for open source release late last year under the MIT License.

ZooLib offers all of the following implemented as C++ classes:

• Multithreading, with cross-platform C++ thread classes and various kinds of locks (simple mutexes, reader/writer locks) - multithreading is important for something like a servent. For systems like the Mac OS that don't have preemptive threads it has a handrolled thread scheduler.
• GUI, with a uniquely flexible layout method. The widgets are rendered by platform appropriate renderers, and you can make custom widgets. There's a renderer that will call through to the Appearance Manager on the Mac OS, if it's running.
• platform-independent TCP networking, it's implemented in terms of sockets on Linux, WinSock on Windows, sockets on BeOS and MacTCP on Mac OS. I think Open Transport may be working too on the Mac, I'm not sure - but on all platforms you use the same C++ classes for your networking with no platform-specific client code needed.
• Thread-safe reference counted smart pointers, for quick, efficient memory management that's free of leaks.
• Extensive debugging support - assertions in core components and a debugging memory manager, handy macros for assertions and the like
• Single-file database format with C++ interface. Create ZDatabase objects with ZTables in them. Much zippier than SQL and more pleasing to the object-oriented soul.
• File objects - you instantiate a ZFile object from a ZFileRef object, then use its Open, Close, Read and Write methods
• Platform-specific file open and save dialogs with an API that's consistent with the rest of ZooLib. Filter by filetype on the Mac or filename three letter extension on windows. While ZooLib is cross-platform, it breaks out into platform specific code in cases like this where it's appropriate, in a way that's considered entirely sacreligious by the Java community.
• Streams that can be chained to provide filtering, somewhat like the iostreams classes in the C++ standard library but more appropriate for use with binary data. This is how you typically read or write to a file or network connection.
• Handy preprocessor macros to deal with platform specific code or selecting options like debug builds.
• Offscreen graphics buffers that may be manipulated directly via pointers or accessed in a manner that is transparent to the bit depth via GetPixel and SetPixel calls. All platforms have the same API that provide a wrapper around platform bitmap buffers. I believe there's a purely homegrown in-memory implementation, plus platform implementations bounds to the native GUI layer like GWorlds on the Mac OS.

ZooLib 0.81 is known to build with MetroWerks CodeWarrior on Windows and Mac OS, gcc on Linux, and gcc on BeOS for Pentium.

If you use CodeWarrior you can cross-compile and cross-debug; check out Thursby Software for some filesharing solutions that work well for this. (Tip - on Windows, select the "MacBinarize" post-linker in the target linker prefs when building a Mac target - you also need to derez all your resource files and include them as Rez text source).

While it should ultimately work, there are known build problems with BSD, CodeWarrior for BeOS PowerPC and Visual C++ on Windows. These are all being worked on and full support for all these platforms is expected before long.

Other cross-platform frameworks I'd like to note are:

• The Adaptive Communications Environment for cross-platform networking
• GTK - yes, that's right, GTK! but you must forgo using XLib calls and POSIX calls that are not in the ANSI C Standard Library
• The Netscape Portable Runtime for the non-GUI aspects of cross-platform development
• The Mozilla XPToolkit for cross-platform GUI
• Mozilla Netlib for network and file stream access
• Mozilla XPInstall for cross-platform installation, packaging and updating.
• Also check out AbiWord, a great cross-platform WYSIWYG word processor that's open source, with an open file format. As far as I know the only product coded in AbiWord's XP framework is AbiWord itself, but it's worth looking into for another look at how people architect these things.

People often mistake these problems for valid arguments that one should not do cross-platform development, or perhaps not render your own widgets when doing so but depend on platform specific ones (like AWT vs. Swing), but I think the lightweight, well architected, efficient and easy to use ZooLib answers those arguments very eloquently.

Help me teach the Free Software community to write quality code.

Mike

It has to work on Windows...

Apple has announced it has no plans to support a JVM later than 1.1.8 on the classic Mac OS so you can't use all those great collection classes in Java 1.2 and be cross platform! (See Apple's Java Developer page and scroll down to where it says "Mac OS Classic Java".)

Use a cross-platform application framework. That way you can program on Linux, Mac, BeOS, Windows or maybe even QNX and deliver for all those schoolkids running Windows ME on their parents' PC.

One such framework, for C++, is ZooLib. There are many others, as you can see from The GUI Toolkit, Framework Page.

Read about why it's important to write cross-platform code.

I'm most familiar with ZooLib, because I've been working with it on the products I write for my clients, and I helped ZooLib author Andy Green prepare it for open source release late last year under the MIT License.

ZooLib offers all of the following implemented as C++ classes:

• Multithreading, with cross-platform C++ thread classes and various kinds of locks (simple mutexes, reader/writer locks) - multithreading is important for something like a servent. For systems like the Mac OS that don't have preemptive threads it has a handrolled thread scheduler.
• GUI, with a uniquely flexible layout method. The widgets are rendered by platform appropriate renderers, and you can make custom widgets. There's a renderer that will call through to the Appearance Manager on the Mac OS, if it's running.
• platform-independent TCP networking, it's implemented in terms of sockets on Linux, WinSock on Windows, sockets on BeOS and MacTCP on Mac OS. I think Open Transport may be working too on the Mac, I'm not sure - but on all platforms you use the same C++ classes for your networking with no platform-specific client code needed.
• Thread-safe reference counted smart pointers, for quick, efficient memory management that's free of leaks.
• Extensive debugging support - assertions in core components and a debugging memory manager, handy macros for assertions and the like
• Single-file database format with C++ interface. Create ZDatabase objects with ZTables in them. Much zippier than SQL and more pleasing to the object-oriented soul.
• File objects - you instantiate a ZFile object from a ZFileRef object, then use its Open, Close, Read and Write methods
• Platform-specific file open and save dialogs with an API that's consistent with the rest of ZooLib. Filter by filetype on the Mac or filename three letter extension on windows. While ZooLib is cross-platform, it breaks out into platform specific code in cases like this where it's appropriate, in a way that's considered entirely sacreligious by the Java community.
• Streams that can be chained to provide filtering, somewhat like the iostreams classes in the C++ standard library but more appropriate for use with binary data. This is how you typically read or write to a file or network connection.
• Handy preprocessor macros to deal with platform specific code or selecting options like debug builds.
• Offscreen graphics buffers that may be manipulated directly via pointers or accessed in a manner that is transparent to the bit depth via GetPixel and SetPixel calls. All platforms have the same API that provide a wrapper around platform bitmap buffers. I believe there's a purely homegrown in-memory implementation, plus platform implementations bounds to the native GUI layer like GWorlds on the Mac OS.

ZooLib 0.81 is known to build with MetroWerks CodeWarrior on Windows and Mac OS, gcc on Linux, and gcc on BeOS for Pentium.

If you use CodeWarrior you can cross-compile and cross-debug; check out Thursby Software for some filesharing solutions that work well for this. (Tip - on Windows, select the "MacBinarize" post-linker in the target linker prefs when building a Mac target - you also need to derez all your resource files and include them as Rez text source).

While it should ultimately work, there are known build problems with BSD, CodeWarrior for BeOS PowerPC and Visual C++ on Windows. These are all being worked on and full support for all these platforms is expected before long.

Other cross-platform frameworks I'd like to note are:

• The Adaptive Communications Environment for cross-platform networking
• GTK - yes, that's right, GTK! but you must forgo using XLib calls and POSIX calls that are not in the ANSI C Standard Library
• The Netscape Portable Runtime for the non-GUI aspects of cross-platform development
• The Mozilla XPToolkit for cross-platform GUI
• Mozilla Netlib for network and file stream access
• Mozilla XPInstall for cross-platform installation, packaging and updating.
• Also check out AbiWord, a great cross-platform WYSIWYG word processor that's open source, with an open file format. As far as I know the only product coded in AbiWord's XP framework is AbiWord itself, but it's worth looking into for another look at how people architect these things.

People often mistake these problems for valid arguments that one should not do cross-platform development, or perhaps not render your own widgets when doing so but depend on platform specific ones (like AWT vs. Swing), but I think the lightweight, well architected, efficient and easy to use ZooLib answers those arguments very eloquently.

Help me teach the Free Software community to write quality code.

Mike

Crashes and bugs greatly reduced since 0.7.

Get Mozilla

I personaly think that the open source movement will never die(as long as their are lazy people and there are non lazy programmers).

That's an interesting take on the community. I don't see why the general populace needs to be lazy to support the open source movement. I mean, really...wouldn't it be better if NO ONE was lazy?

If everyone did diligent bug-squashing for the lizard, if everyone contributed to Darwin, wouldn't that be better than a few non-lazy programmers doing the work?

That's just my opinion. And I almost forgot to mention, ALL YOUR JON KATZ ARE BELONG TO SATAN . Thanks for your time.

--

User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; 0.8) Gecko/20010217

Have no fear. In Mozilla, it's possible to customize your user-agent string, in order to fool obnoxious web sites into thinking you have a different browser.

You'll have to edit prefs.js or user.js in your Mozilla home directory. According to http://mozilla.org/unix/customizing.html, the relevant preference is:

user_pref("general.useragent.override", "Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5");

I've tried to upgrade to Netscape 6.0

So use Mozilla brand NS6 instead of Netscape brand NS6. Mozilla 0.8 is already several proverbial kilometers ahead of NS4 in terms of HTML/CSS/DOM standards conformance and stability.

Last time I looked, there wasn't an NS6 that had email and newsgroups built-in. If I was up to NS6, I'd have to put up with more Netscape commercialism, and I'd have been exposed to some security problems that didn't hit 4.76.

Have you looked at Mozilla 0.8 (NS6 without the commercialism and with more bugfixes) yet?

But with a 4+ year old computer and only 128 MB

(I wish I could fit that much RAM in my 4+ year old computer.) Mozilla 0.8 should work just fine for you.

See:

http://www.mozilla.org/releases/mozilla0.8/

It's under the "what's new", as the very last item. Put the code fragments there in your

~/.mozilla/defaults/prefs.js

file.

http://lxr.mozilla.org/mozilla/source/modules/libp r0n/

Nice thought, but please verify anti-rumors before spreading them.

Am I the only person who things SSL is the most screwed up thing about this program?

No, you're not. Take a look at bug #60912 and bug #31174, for starters.

Am I the only person who things SSL is the most screwed up thing about this program?

No, you're not. Take a look at bug #60912 and bug #31174, for starters.

It's actually in the preferences ui.

Edit->Preferences->Appearance->Show Tooltips

Unfortunately, doing this also disables the displaying of title attributes as tooltips. There's a bugzilla entry about this.

2001-03-16 19:04:01

Actually Mozilla is now released under a dual MPL/GPL license. So RMS should be quite happy with it.

Check it out!

it's great to see Mozilla shaping up. i've been trying out Mozilla on a regular basis since M4 (yeah, i'm a glutton for punishment), but it's only recently that i've been able to use it on my Windows machine at work as my primary browser.

at home however, i run the MacOS, and while IE 5.0 on MacOS 9 is still the best browser i've ever tried, i now run a later build of MacOS X for development purposes. IE 5.1 on MacOS X is severely lacking (a very poor carbon port), and i'd really like to make the switch to Mozilla on this platform. does anybody know what's going on with Fizzilla, the MacOS X port of Mozilla? specifically, i'd love to be able to run FizzillaMach that uses the UNIX code as a back end and a carbon port of the Mac code as the interface.

right now the latest build of Fizzilla is based on an early January nightly build, and while that's good, it still has some pretty nasty bugs that keep me from using it on OS X. it's a shame because the recent builds of Mozilla have been so good. does anybody know if there is there active development of Fizzilla? are they planning on releasing a new build, perhaps based off of 0.8? on March 24th a lot of people are going to be looking for a Mac OS X-native web browser, and IE is already going to be included in the dock by default. it's going to be important to have the Mozilla alternative available at that time. :I ..

- j

it's great to see Mozilla shaping up. i've been trying out Mozilla on a regular basis since M4 (yeah, i'm a glutton for punishment), but it's only recently that i've been able to use it on my Windows machine at work as my primary browser.

at home however, i run the MacOS, and while IE 5.0 on MacOS 9 is still the best browser i've ever tried, i now run a later build of MacOS X for development purposes. IE 5.1 on MacOS X is severely lacking (a very poor carbon port), and i'd really like to make the switch to Mozilla on this platform. does anybody know what's going on with Fizzilla, the MacOS X port of Mozilla? specifically, i'd love to be able to run FizzillaMach that uses the UNIX code as a back end and a carbon port of the Mac code as the interface.

right now the latest build of Fizzilla is based on an early January nightly build, and while that's good, it still has some pretty nasty bugs that keep me from using it on OS X. it's a shame because the recent builds of Mozilla have been so good. does anybody know if there is there active development of Fizzilla? are they planning on releasing a new build, perhaps based off of 0.8? on March 24th a lot of people are going to be looking for a Mac OS X-native web browser, and IE is already going to be included in the dock by default. it's going to be important to have the Mozilla alternative available at that time. :I ..

- j