Christopher
Well-known member
Wait, seriously? What was the point of making that browser for "Classic" mac's if the 68k's aren't involved?
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
my vision for 68k/ early ppc macs
- Thread starter macintoshman
- Start date
- Status
LCGuy
LC Doctor/Hot Rodder
There's actually a lot of point in developing Classilla - any Mac running OS 9 these days could be called "classic", hell Apple even calls the Mac OS 9 environment in OS X "Classic". Classilla is the first web browser to developed in the past 5 years that supports any OS 9 system at all.
Mike Richardson
Banned
Actually, iCab 3.0 was released for Mac OS 8.6 and up within the past couple of years. This version greatly improved the renderer.
Unfortunately, with iCab 4.0, the unique iCab renderer was dropped in favor of WebKit.
Unfortunately, with iCab 4.0, the unique iCab renderer was dropped in favor of WebKit.
Scott Baret
Well-known member
You never know, someone may very well program one sometime (if any programmers are thinking of RetroChallenge ideas, here's one for you). After all, who would have expected Classilla to be released many years after Apple stopped selling Macs that boot into OS 9?
There is work on a 68k port of Haiku in the works, http://www.haiku-os.org/blog/mmu_man/2008-07-21/getting_to_the_kernel_68k_way .
I think some kind of NeXT like environment for 68k Macs would be really cool. I wouldn't know where to start. A long time ago when I looked at the source code for early Darwin before version 1, there were still alot of code references to 68k and I486.
As for as newer browsers and other software, if Atari and Amiga users can do it then we should be able to port it without having to write it from scratch. maybe we are spoiled as Mac users where as they have to keep going or they loose there entire platform.
I think some kind of NeXT like environment for 68k Macs would be really cool. I wouldn't know where to start. A long time ago when I looked at the source code for early Darwin before version 1, there were still alot of code references to 68k and I486.
As for as newer browsers and other software, if Atari and Amiga users can do it then we should be able to port it without having to write it from scratch. maybe we are spoiled as Mac users where as they have to keep going or they loose there entire platform.
Mike Richardson
Banned
I think one of the problems with 68K browsers now is that modern webpages are just too demanding of the computer.
Take a look at an average bank website, for instance. You will find the following features used:
- SSL/TLS
- JavaScript
- CSS
- Dynamic HTML (combination of JavaScript and CSS)
- AJAX (combination of JavaScript, CSS, and XMLhttpRequest)
We already have SSL on 68K, so that's not a big problem as long as sites continue to support SSL 3.
The next problem is interpreted JavaScript. Sites use thousands of lines of JavaScript now and interpreting this is slow.
CSS is another problem. Such things as: translucency, dynamically resizing boxes, etc. It requires thousands of inter-dependent calculations to lay out a page.
Basically - more and more work is slowly being shifted to the browser. Imagine a bank website in 1997:
- Basic HTML 3.2 or 4.0 design. Perhaps a simple table based layout. Complex text, etc. is probably loaded in as a GIF image.
- Basic SSL v2 40-bit may have been used.
- No JavaScript. The login form is sent to the server as-is. The server must determine if enough characters were entered, etc.
- You see your online check book and want to view more information about a transaction. You click the transaction and the server sends an entirely new page.
- You want to add a note to a transaction. Clicking add note loads an entirely new page using target _blank. Seeing the note in the transaction requires refreshing the entire page.
Compare to the modern bank site:
- XHTML 1.1 with CSS2. No tables used in the design. The appearance may even be similar to or the same as the 1997 version, but it's much harder to render due to the used of CSS.
- Banks have disabled 40-bit and SSL v2 for security reasons. Minimum is now 128-bit SSL v3 or TLS.
- Heavy JavaScript used. Pre-validate all forms on the entire site.
- Transaction information is shown in-line using a hidden CSS box and AJAX to retrieve the information.
- Adding notes is done with AJAX.
Take a look at an average bank website, for instance. You will find the following features used:
- SSL/TLS
- JavaScript
- CSS
- Dynamic HTML (combination of JavaScript and CSS)
- AJAX (combination of JavaScript, CSS, and XMLhttpRequest)
We already have SSL on 68K, so that's not a big problem as long as sites continue to support SSL 3.
The next problem is interpreted JavaScript. Sites use thousands of lines of JavaScript now and interpreting this is slow.
CSS is another problem. Such things as: translucency, dynamically resizing boxes, etc. It requires thousands of inter-dependent calculations to lay out a page.
Basically - more and more work is slowly being shifted to the browser. Imagine a bank website in 1997:
- Basic HTML 3.2 or 4.0 design. Perhaps a simple table based layout. Complex text, etc. is probably loaded in as a GIF image.
- Basic SSL v2 40-bit may have been used.
- No JavaScript. The login form is sent to the server as-is. The server must determine if enough characters were entered, etc.
- You see your online check book and want to view more information about a transaction. You click the transaction and the server sends an entirely new page.
- You want to add a note to a transaction. Clicking add note loads an entirely new page using target _blank. Seeing the note in the transaction requires refreshing the entire page.
Compare to the modern bank site:
- XHTML 1.1 with CSS2. No tables used in the design. The appearance may even be similar to or the same as the 1997 version, but it's much harder to render due to the used of CSS.
- Banks have disabled 40-bit and SSL v2 for security reasons. Minimum is now 128-bit SSL v3 or TLS.
- Heavy JavaScript used. Pre-validate all forms on the entire site.
- Transaction information is shown in-line using a hidden CSS box and AJAX to retrieve the information.
- Adding notes is done with AJAX.
Charlieman
Well-known member
Alas, a responsive *nix GUI on a 68K Mac is an unlikely proposition. Mac graphics cards are designed to display QuickDraw and have drivers (in ROM or INIT) that accelerate QD. 68K Macs have used literally dozens of graphics processors, most of which are proprietary. The NeXT family have graphics interfaces and drivers that optimise Display PostScript. PowerMacs sometimes get reasonable X11 graphics, but only if they the right graphics card.
A modern X11 Server for 68K and low power PPC Macs, that uses all of the wonderful goodness of classic Mac OS, makes more sense to me.
sastevens59
Member
I have NetBSD running on one of my SE/30's. Here is a page with pictures of it from a number of years back:
http://sasteven.multics.org/MacSE30/MacSE30.html
The 68K port of NetBSD is alive, if not very active.
I put a current copy of NetBSD on one of the slot-loading G3 iMacs I bought a few weeks ago. It's nice, with a modern browser, etc.
http://sasteven.multics.org/MacSE30/MacSE30.html
The 68K port of NetBSD is alive, if not very active.
I put a current copy of NetBSD on one of the slot-loading G3 iMacs I bought a few weeks ago. It's nice, with a modern browser, etc.
- Status
