Revisiting Apple Copland (D7E1 Build) Info/Tour - Paul's Old Crap #9
HTML-код
- Опубликовано: 19 окт 2024
- This is my second video about Apple Copland and today we jump into build D7E1 which I only recently managed to get running due to the very specific boot requirements. This is a very unstable system and not much of it is actually usable.
Copland info:
wiki.preterhum...
Paul's Old Crap info:
wiki.preterhum...
IG: / pauls_crap
#copland #applecopland #vintageapple #macos8 #coplandOS #vintagemacintosh #retromacintosh #applecomputer #powermacintosh #powerpc
It's fascinating, after all this time, to finally see Copland in action (if one can call it that). It's also fascinating how fragile the system actually is, with the first debug breakpoint being in the middle of boot! With Copland's back story of disparate half-baked projects all being folded into the product at once, I'm not that surprised at the result, but it's still amusing to see. I assume this build was never intended to be seen by peasants and requires an actual Copland team dev at the debugger, who has the insider knowledge of its internal workings and how to recover it, to demonstrate it properly. I wonder how far one could get in a demo with that resource on hand, assuming such an individual still exists. And as we've seen, the actual DR builds aren't much better.
Please continue with the videos. This is something I've wanted to see for, well, about 25 years!
The funny thing as well is whenever they did demonstrations for the press, it was all fake. If you watch the episode of Computer Chronicles on Copland, they weren't actually running one of these builds but instead simply moving through a pre-rendered presentation mockup. I think most of what was visible there wasn't even in the last Copland build before the thing was nuked. Going over a bunch of the architecture docs from the D9 developer CD it looks like they were headed in the right direction on the tech side with the microkernel, but they didn't have the right people to actually get things done.
@@netfreakcanada Yeah, I'm familiar with those demos and remember them from back in the day. They were a bit maddening since they were so obviously faked. On CC, they don't actually show the presenter controlling it to prove it's a slideshow, but it's obvious that the screen animation is scripted rather than recorded, and when they cut back to the presenter, he always has his finger on one key. I've never been through the architecture docs, though.
I do wonder what would have happened if Copland and Gershwin had shipped somewhat on schedule. I think they could have kept the old Apple afloat for a while, but they probably wouldn't have been great. Apple likely would not have had a compelling reason to acquire NeXT and would have missed their window to do so, and their decline may have continued.
Great video! As an "old-hand" Mac user who's been through it all (I had the 128k "Vanilla" Mac in college), I really appreciate the nostalgia. Copland seems like the absolute sum-total of everything that was bad about 1986-97 Apple...everything that we die-hard fans had to deal with all the time (and kept insisting would all work out; would all be fixed...soon...once Scully or Spindler or Amelio or Ellen Hancock finished doing their important work). We bought the Magazines (MacWorld; MacUser) and read the breathless articles and loaded the demos from the included CD-ROMs...we pored over reviews of the DuoDock series and the newest Newtons and the Quadras....waiting for the magic moment that it would all start working. Every single thing wrong with the Apple of that period is distilled into this one video.
I always enjoy seeing these types of videos showing what could have been.
I think they had a lot of interesting ideas, but 90s Apple was too big of a mess to get things done. There's a lot of other neat/strange things they were coming out with around that time which I hope to mess around with soon (QTTV, OpenDoc, Cyberdog, etc etc).
It was incredible that they even let us see the beast
Looking forward to your video on D9 and D11 builds. Remember, the ‘d’ means development, which truly weren’t supposed to be run outside of Apple - they’re not even alpha-quality and meant to be unstable as a subset of engineers were basically looking for the massive crashers, documenting them, and getting those bugs resolved for a workable alpha. As a kid, I was so fascinated by Copland and what Apple was trying to do, so it’s great to see these videos. I’m actually surprised at how much working code Apple had at this point, given how dysfunctional the project was billed. That they had anything built that could boot is surprising in and of itself. We also have to remember that it was a completely different era of software expectations. Incremental upgrades delivered frequently was a hard model all around as the primary distribution points were floppies and CDs for average folks. From a marketing perspective, Apple had to jam a lot into one release as the market didn’t know how to deal with incremental OS releases.
We joke about Copland but on the tech side it is very neat what they were trying to do... Unfortunately I'd say they aimed too high and didn't have the resources to effectively build it. For the most part it seems like it was a "build from scratch" type of deal and slapping in existing Mac elements where possible, but everything was going to be different from the existing systems. Some of these old documents show simple things like driver extensions would have to be rewritten. When we see how many years it took for OPENSTEP -> Rhapsody -> Mac OS X to become a final OS, there was probably no hope for Copland.
I like these "tour" videos. They take me back. Thanks.
Please do videos on the builds! I love them! Thanks for all you do. :)
51:08 ^0 was usually replaced by a parameter string (in the old Macintosh Toolbox ParamText() ) so it's code missing.
Sorry for the tech commentary. It reminds me of a lot of old stuff.
It's good information to have as this sort of stuff probably isn't easily found anymore.
22:45 Oh my God! I have vague memories of seeing that theme in a magazine article about Copeland back in the 1990s. Never seen it actually in action before.
"I'll just double click this and oh, again" 😂
22:24 - The name of that theme was ''Gizmo.'' There were three unreleased Apple developed themes: Gizmo (Z Theme), Hi-Tech, and Drawing Board. They were nixed for MacOS 8, then brought back to potentially be included with MacOS 8.5, but were dropped yet again. If you install Appearance Manager from MacOS 8.5 or newer into MacOS 8, you can re-install the themes. They also had sound sets to accompany them. The only theme + sound set that was even remotely tolerable was Drawing Board. The other two are so obnoxious you'll use them for about 4 seconds then switch.
You can download the original beta themes from the various online Macintosh software repositories.
I think I also read something about how the decision to not implement those themes had something to do with potential legal issues if the OS interface was to change that much. Can't remember where I saw that though.
What happens at 15 minutes 5 seconds is that you get and assertion.
As a developer one uses assertions to find bugs. The assert is standard part of the C programming language and derivates (C++ and the Objective C that Apples seems to like). One asserts that a certain condition is right; a pointer is valid, a size is valid etc. The asserts normally terminates the process when it fails but I have not used them for OS development so that might be different in this case. It is normally a macro that is used extensively in the code. During development and debugging the macro expands to "if condition is not fulfilled, print location and terminate process". In release builds those are normally completely removed and users rarely see them.
If asserts was activated in releases you would probably get them more often than you might think. Despite the termination during development it does not imply that the same bug would mean any actual harm in release.
The "About this mac" assert on row 5889 in ListWindow.cp (15 minutes, 5 seconds). This is a specific location and the developer can look there a see what was wrong. On the location there is a test, like an if-statement and the developer know that this returned false and the developer can evaulate the situation and take proper measures.
I would guess that in this case the call is made to a funktion that either returns something unexpected or is just a stub. A stub function is part of the code where the function is there but it contiains nothing, it just returns a standard value. A stub. That is very common in early stages of development to create the foundation.
Once released (or compiled without the assertion) it is likely that nothing would happen what so ever and the system would likely be able to survive. This build is for testing and development and one would want it to scream "bug" when there is one.
Exception is another story. Exceptions are part of the error handling strategy that is also part of the release. If something goes wrong and the process are unable to survive it might generate and exception. A process that is terminated due to an assertion might also generate an exception. Other common exceptions are invalid pointers in C/C++/Objective C. Those are a bitch and the inner core OS or even the CPU might raise an exception, at least around that period of time. Dos did not raise exceptions, I havd had pointer bugs that totally fucks up the OS where the exception would have been welcome - then I would known I made a bug :)
Yeah I'm not much of a programmer so most of the debug side is foreign to me. In the later Copland releases they also had different system files you could drop in which supposedly cut down on the number of debug stops the OS made. I've got a lot of future messing around to do on this stuff anyway.
Great comment, thanks for sharing these explanations around asserts & exceptions. It's stuff that I think would be valuable to understand for a lot of ppl dabbling in the old Mac OS betas :) I agree probably most of the asserts are likely just stubbed out stuff that wasn't yet implemented. I bet we'll find far less asserts in D11E4 if Paul does a video of it :) Probably just as many exceptions though hahah
Assertions and breakpoints don’t necessarily mean the program has crashed as they are often used to signal an unusual but not necessarily serious condition.
Not knowing the source code, the best strategy is to continue the execution of the program with Control/Run until the next break/assertion or it crashes.
Without knowing the source code, propagating the exception doesn’t usually help because it moves the execution point down through the call stack in a different place that is quite likely to be affected by the interruption of the normal execution path...
I always thought Longhorn was absolutely disaster-rific, but now I'm not so sure...
Copland may have to take the cake for the most unstable beta/alpha/test release OS ever! 🤣
it wasn't in those stages at all - none of what was shown in this video was ever allowed in the public and there wasn't a public-beta program at the time. Copland in its early stages was never meant to be seen let alone used on anyone's computer int hat stage - this copy is a perfect example of Why Apple pulled the plug on it.
33:48 That reminds me of the early versions of Sherlock. Maybe they thought of Viewers as a kind of proto Saved Search. Open this Viewer and all your XYZ files appear.
It's possible. It doesn't seem overly convenient to store then randomly around the filesystem instead of in a central search.
I love your Copland series, are you going to make a revisit video of D9 and D11?
I am indeed but I need to dedicate much more time to messing around with them first and seeing if there's more stuff to cover that I haven't considered yet. I put D11 back on the testing machine and was poking around random system files with ResEdit, and I'm hoping to try getting more apps running to demo.
More copland is always interesting. I always love seeing unfinished left as is work like that.
They had big plans for Copland...
Speaking of Which, d'you ever intend on covering the Rhapsody project or the DP and the public beta version of OS X?
Yes I've been meaning to try the developer releases of Rhapsody, especially the x86 version. I'm not sure if I currently have any compatible hardware for it. I never used the OS X public beta but at some point I should try that too.
@@netfreakcanada the x86 developer build runs well in vmware if you're okay with virtualization.
I don't mind testing things in virtualization but I need the physical hardware to appreciate the result.
@@ryaxnb2 I'd recommend running the x86 builds under 86Box.
Paul, I like your old Mac crap!
I sure enjoy these videos, keeps me entertained!
Protected memory was the only feature I cared about when I owned my Mac. It crashed and lost my work way to much, and Apple had plenty of time to add it before I decided to switch to Linux.
Already by the time 040 was introduced Apples OS could not take full advantage of the CPU feature set. Going to the PPC was even worse, as even less of the CPUs capabilities were utilized. Speed was the only feature that was used.
Yeah if there's one thing I don't miss about those days it was application crashes that took down the whole system.
35:40 Suitcase is a the term for files containing collections on Font (or desk accessories). It should have an icon though (dev build)
LOL, at least this isn't a main computer to use cause this was hilarious.
Z Theme looks like a simple demo of how flexible Copland was in terms of theming. I can't imagine anyone thought even at the time that it looked good enough to ship in the final product. That's probably also why it doesn't have a real name.
cool! i was hoping for a revisit
50:00 I think "DesktopServer" may be a prototype of the thing you played with in D9 around 57:30 in the June 2019 video - those weird "worm" and "fruit fly" animations on the desktop. No idea how to actually launch it in this build though. The empty "Modules" menu suggests that the engine is there but there are no actual animations included.
Ah the 6100. Wrote many a product on that machine in the early 90's.
39:50 the whatever reason is that it can't find the proper Open Transport "CFrag" (that's a Code Fragment, aka DLL)
40:45 The memory is likely including the "virtual memory"
49:30 Likely the file was corrupted, the same way the filesystem could have been corrupted. "Illegal instruction" is usually a good sign of that.
Surely to be an operating system it has to operate the system ?
have you tried pressing “step out” in the debugger when issues come up? step out skips to the end of a function’s execution, so it may help when it seems like the OS is stuck in a loop of executing the same command continuously
At some point I think I did try that but I don't recall it working out too well.
30:10 I would have selected "Stop" to stop the program. But "Run" a few times may have worked if it was just doing the same thing many time (each string to be displayed). It was just an assertion.
30:36 bad PSN mean "Bad Process Serial Number". I suspect he is trying to terminate the process but it is already gone. And that's badly handled at that point.
Thanks!
No wonder they says that the Copland crash every 30 min..
If you never touch the computer it might go longer than 30 minutes without a crash. Possibly.
Was Copland built new entirely from the ground up, or was is simply System 7 with new features?
Best I can tell the core system was all new and they were porting the toolbox and the gui over to run on the new microkernel. This probably explains why it was taking forever and nothing ran on it.
My guess about Propagate Exception is that it propagates the exception to the parent process, which is going to be the kernel(or maybe something else?). And then system will probably try to kill the crashed process, and then it horribly fails.
For example, 42:05 says “Unhandled user exception”, which probably means the exception was propagated from the user process to the kernel.
Is there one who actually worked on this project that could give us their account of life inside the Copland project?
31:25 Holy wow... I mean, just imagine trying to debug Copland.
"Oh, better open this log file to see what went wrong."
*OS crashes*
"...Guess we'll never know."
Lol call me strange but I love Copland ;) Have the source and 3 releases and a stable stand-alone version I whipped up ;)
You should online archive anything that isn't up in the usual places. I think I've only ever seen just the 3 leaked copies but nothing else.
@@netfreakcanada Will do :) If I recall, it all came from Hotline Servers, the SRC and Leaked Copies. But still, have it all :) Not sure if you have your server still up on Higher Intellect or not, but could post it there as well :)
Yep still running :)
@@hye181 Will be on www.macintoshrepository.org and The Higher Intellect Hotline Server :) Been looking for everything in my old CD archives and will be posting the System 7 and 8 Src with it :) Just be patient it will be up ;)
Just a quick update: I have everything found and gathered into a directory, just have to take it all over to my MacBook, to image and archive :) Will be leaving links here. Also, I will be segmenting it into 500mb files to go on the Higher Intellect servers. Should be up in the next couple of days ;)
If I recall correctly “Maxwell” was the internal code name
yay another mini Copland WWDC lol
Apple Copland is more unstable than my mental health fr
23:37 LOL
ugh, Copland was such a mess to actually do any development with.
This OS puts Windows 98 (first edition) to shame in terms of (un)stability.
Actually reminds me of that early demo video that blue screened while Bill Gates was on stage.
ruclips.net/video/IW7Rqwwth84/видео.html