Slashdot Mirror

As far as a web browser goes, you're looking for OmniWeb. Lynx is also available. Didn't OmniWeb come with OS X though? For Darwin, only Lynx is available.

As far as a web browser goes, you're looking for OmniWeb. Lynx is also available. Didn't OmniWeb come with OS X though? For Darwin, only Lynx is available.

I don't think id will be too hurting without Zoid there. His contract is coming to an end, maybe they weren't going to renew it anyways? With John Carmack doing things like writing an X windows port for Mac OS X and doing a lot of work on the Utah-GLX project I'm sure he can handle doing the concurrent Linux/Mac development himself easily enough that Zoid was responsible for. I don't know Robert Duffy very well but he seems to be doing a good job for id so far, he could possibly also take over this responsibility.

I've met Zoid before and he was a great guy, I hope him the best of luck.

-idealego

Go check www.stepwise.com for the blurb.

IIRC, he's waiting for XFree86 4.0 to create patches to merge them back in.

>But, to be positive, as long as Mac OS X's fancy animations don't bring the cpu to a grinding halt, I'm sure
>the BSD-based kernel will lend quite a bit of stability to the system (unless Linus's warnings about putting
>graphics in the kernel come to haunt them!)

OS X is based on Mach, which is a microkernel. Drivers are layered on top, sort of as 'services'. There's a new API for drivers (NeXT had the DriverKit) called IOKit. I don't know much about it, but I'd be extremely suprised to see it patch into the microkernel...

BTW:, Check out: Carmack's port of XFree to OS X!

There are three API's supported in MacOS X:

1) Classic (basically the old MacOS 9.x API)

2) Carbon (a modified offshoot of Classic)

3) Cocoa (the enhanced & updated OpenSTEP API)

Programs using the Classic API will not benefit from the "new" features such as memory protection or pre-emptive multitasking; essentially, it's a MacOS 9.x emulator (with a performance hit?). Carbon apps will reap the benefits of the BSD stuff underneath, and porting from Classic to Carbon tends not to be too difficult. Even better, Carbonized apps will also run on MacOS 9.x machines, albeit without the memory protection, etc. So developers can maintain one codebase for both 9.x and X. Lastly, the Cocoa API is the evolved and improved version of the OpenSTEP API, and does AFAIK support Objective-C and Java. Cocoa and Carbon apps will be "equal citizens."

More information can be found at Apple's OS X site and its developer site. I suspect StepWise will have more information on MWSF before long.

RFC959 wrote: I don't know what graphics system OSX uses, but I suspect it's either X-like or MacOS-like. We're talking about multi-user machines here, remember? X is what you wanted to get rid of, and MacOS is built with the assumption that you've got one machine, one framebuffer, and one user (and one GUI!) in your "computing environment", none of which is necessarily true anymore, making it an unsuitable starting point.

You're right. You don't know what graphics system Mac OS X uses. It uses a lightweight window server (which runs as it own process) with multiple rendering engines, including Display PDF, Quickdraw, and OpenGL. This is not like the graphics system on most other OS's. It relies on high speed IPC to implement a client/server graphics solution.

See Mac OS X Graphics for a newbie and shallow overview, and a technical overview from Stepwise's WWDC '99 Graphics Coverage

This system has some real tangible end user benefits. For example, even when an app is busy waiting, an end user can still move that app's windows and panels and the refresh of the window still happens (unlike Windows where you start getting lots and lots of white space). Since the lightweight window server maintains the backing store, you get great UI performance even with sluggish apps. This model may have performance benefits compared to the overhead of lots of threads... it's a different approach as compared to the BeOS approach... both have their strengths and weaknesses and both are superior to most other graphics systems available.

As for age, this system is an evolution of the Display Postscript window server model introduced in NeXTstep in 1988. It's not new, but it is significantly enhanced and competitors still haven't achieved the 2D graphics user experience given in the original NeXTstep 1.0

As soon as I do some more testing, I'll get a Mac OS X Server .pkg package up on next-ftp.peak.org. My Samba 2.0.4b and 2.0.5a packages are already up there, including instructions for compiling it yourself.

Another place to look for software for Mac OS X Server is Stepwise's Softrak service.

If you are in a hurry, the just copy the config.guess and the config.sub from /usr/libexec to replace the ones given in the Samba distribution. Configuring the smb.conf and other Samba issues are pretty much the same as other platforms.

People use BASIC because they don't know any better and/or they are lazy. The same thing goes for using the proper 'Too' and punctuation. ;-)

I think Apple is finally doing the right thing in letting Yellow Box sell itself. Most long-time Apple developers were freaking over the prospect of having to recode for Yellow Box. Voila, we get Carbon and they are happy. Check out StepWise though to see just how many quality Yellow Box Apps are already shipping for Mac OS X, an OS not even due to be delivered until early 2000. Too bad on the Yellow Box for NT licensing front though. I will personally bet that the problem there is Adobe and not Apple.

Even if Yellow Box should tank the API is alive and well, getting stronger each day. Check out
GNUStep or the GNUStep NewsWire for details. At bare minimum the fellow asking the original question needs to take a look at this.

"The Debian packaging system has been adopted for the Darwin distribution, and should be fairly easily moved to Mac OS X Server if someone were inclined to try"

many thanks Mr. Andre Werthmann. linux-heretic-0.9, and source, it works great here. And it works also on FreeBSD as noted in previous thread. Is GGI working on other platforms than Linux?

what does it require for 3DFx to allow a GLIDE port? Do you get source code? Is there a different software project going free source to provide, replace, or work like GLIDE and, or support for not just Voodoo cards, but also cards like Matrox?

I think this is very nice of Raven, and Andre Wertmann, even without sound, hardware acceleration missing (or without Glide API), network play, multiplayer...ie. use the source Luke!

Is there Glide for FreeBSD and also for NetBSD, or OpenBSD? It is out for Linux, it works even....

And if you have Rhapsody, or Mac OS X Server, read from Stepwise OS Report: January 17, 1999 under

Quick Notes

Eric is hoping to release both Heretic and Hexen for Mac OS X
Server when CR1 ships, and promises to provide Stepwise with some screenshots shortly.

Now if we could get Omni's GLIDE API support into Eric's Heretic and Hexen ports, we'd be
killing aliens and demons left and right.

I hope Eric talk with "Omni's" on GLIDE API on Mac OS X Server. Thanks Eric, and Omnigroup for doing Quake on Mac OS X.