|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Jabbernaut for m68k new attempts (Read 64854 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
on: April 22, 2024, 00:49
So correct me on any of this, or if any newer info is known: https://jabbernaut.sourceforge.net/ https://macintoshgarden.org/apps/jabbernaut 5.6b1 was the last version, ppc only. 5.5 was the last m68k version. Jabbernaut_src.zip from MG is likely a snapshot of the last version from the author. Jabbernaut_src_with_deps.sit from MG was an attempt to build it, including all dependencies that could be found. ---- Despite what the readme says, it looks like the included CW project files in Jabbernaut_src.zip are for CW6, not CW5. From the source, it looks like the original author had started working on a Carbon port, but may never have finished it. (At least the 5.6b1 binaries I've found do NOT include a "carb" resource). It doesn't look like the source to 5.5 is "easily" available...probably the only way to get it is via sourceforge's creaky cvs. ---- So the goal is to get a "stable" version for m68k. I'm assuming either an m68k build of 5.6b1, and/or fixing bugs in 5.5? (Which are two separate things). Are the problems you guys have run into due to 5.5 not being stable? Or does 5.6b1 include features you'd like on m68k? What I'm angling at is: Just how stable was 5.6b1 on PPC? Being a "beta" (going from the version number), possibly abandoned in the middle of development. Is it a good source base to build on? ---- So my first goal is getting a binary of any kind from the available source...which should be 5.6b1 PPC...but, since the source may have been a snapshot of the author's work in progress, may be newer than that, and/or not actually be stable. If we're lucky, the author didn't REMOVE anything necessary for an m68k build, but just didn't bother to supply a binary, and/or maintain it as buildable...ie adding new features that may or may not have broken the m68k build. If we're unlucky, the source snapshots are from the middle of moving it to Carbon, and even that may not have been finished. Hence finding the stable 5.5 sources and doing global diffs to see what changed would be a very good idea. ---- Finally, I am a Clueless Newbie(tm) as far as instant messaging goes. Could one of you tell me how to basically set it up to connect to a useful server and actually test the available binaries? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Knezzen
|
Administrator 512 MB  Posts: 608 Village idiot
Reply #1 on: April 22, 2024, 10:14
|
They are all buggy and sort of alpha grade material. The sources where dug up by the original developer after a few years of back and forth over email with both myself and Bolkonskij writing. The Sourceforge CVS servers are long gone and the Jabbernaut sources where not preserved anywhere (Internet Archive, Wayback Machine, Sourceforge etc). So the sources posted on Macintosh Garden is what we have. Jabbernaut_src_with_deps.sit was put together by me after searching far and wide for the dependencies. So I don't think there's much of an option going forward. We have what we have, so to say. There's no other sources to diff the ones we have against. I have spent a lot of time trying to find any fragment of source code online, to no avail. You can test it through our IM Gateway. See this guide here: http://macintosh.garden/ga/6/en/13/1
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #2 on: April 22, 2024, 16:55
|
Well, dang. I was afraid of that. I have good news and bad... Good: I have something building. Bad: It doesn't work. In Sheepshaver 9.0.4, it throws a strange Zoop error of some kind, but on my TiBook 9.2.2 native, it crashes into MacsBug. ---- There is a chance (but not necessarily a good one) I have something stupid going on with OpenSSL. The Jabbernaut source came with built 0.9.6a lib binaries, with GUSI support, but no headers. I used the 0.9.6f headers, without GUSI, from my Goliath build. I just tried building Jabbernaut with my 0.9.6f lib binaries, but can't link since it is missing GUSI, which I left out since Goliath didn't need it. I'm going to see about building OpenSSL 0.9.6f with GUSI...there is a chance that will work. I'm not sure how good of one it is. I thought it was safe to mix the libs and headers, because I'd get compile errors if things didn't match. But if there were enough differences between 0.9.6a and 0.9.6f... Cross fingers...if THAT doesn't work, I'll see about building 0.9.6a from scratch, which I'd like to avoid, since I had so much fun with OpenSSL in general while getting Goliath building...
Last Edit: April 22, 2024, 16:57 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #3 on: April 23, 2024, 02:18
|
(I have somewhat goofy bolding in the hopes of making this monster at least a little readable...) Uploaded my build folder to the "Uploads" folder in Hotline files as "Jabbernaut_build4.sit" (4th attempt, will increment with each major change/undertaking). Feel free to grab it and take a look, but it is still error'ing and/or crashing...so only useful if you're really curious, or want to help fix it. Will create github repo soon. The included "vers" resource says it is "0.6d1". My guess is the source is a snapshot right before the author abandoned it (as there are included .mcp project files that do not work, see below). It may be a "post Jabbernaut 5.6b1", which means there's a possibility it may have never been finished and may be broken as-is. It is definitely from after he moved to Zoop 2.5, abandoned m68k support, and at least started Carbon support. ---- What I did... Rebuilt OpenSSL 0.9.6f with GUSI support, but it didn't seem to help...so if I'm doing something stupid with OpenSSL, it isn't obvious! The included "Jabbernaut.mcp" looks like it is for a version of Zoop pre-2.5, as the source itself clearly requires 2.5 features, and the project includes files that are no longer present or whose names have changed. Renamed to "Jabbernaut.mcp.old" as it is not useful for anything but reference. Renamed "Jabbernaut Zoop 2.5.mcp" project file to "Jabbernaut PPC.mcp", to make clear it is the only working one. This project file only includes a debug PPC target, another clue that this was an in-progress snapshot...ie there is no "final" non-debug target. It builds to a runnable app "Jabbernaut/Zoop 2.5 DEBUG", but shows a strange error via the Zoop error handling class at startup when run on Shapeshifter. The error is a (modal dialog) alert, so it is not (easily) possible to jump into the CodeWarrior debugger from it. It seems to get a way in as the menus have visibly been set up, but are disabled due to the alert. I was able to build a "final" non-debug version, by using Prefix.h instead of DebugPrefix.h and found English text (ie not C/C++ and NOT inside comments!) in many places with "FIX ME" labels...obviously the compiler throws errors in those places, derp. By commenting them out, I was able to get a runnable app, but it behaved no differently than the debug build, and is probably useless...for now... When run on real PPC hardware it crashes at startup. If you have MacsBug installed you can do an "sc" stack trace and see it is crashing in the init/startup/setup...more about this as we figure out where it is crashing. Knezzen was able to build his own (fresh) copy of the app using his CW6 install. He tweaked some of the application build config and was able to get a different number for the strange Zoop error when run in ShapeShifter. We don't know what the numbers mean, but think they are specific to Zoop and/or Jabbernaut and not standard Mac error numbers. On his real PPC hardware it crashed, same as it does on mine. ---- Mutants... There are two other .mcp project files, and I've tried fixing their access paths etc and getting them to one point or other of building. "TOQ.mcp": Looks like the author may have had a deal/contract with "TBN Online" to have a custom version of Jabbernaut (seemingly cut down, as it leaves several features, mostly the different "Managers", #ifdef'd out) called "TOQ". It is localized in Portuguese and has different artwork/resources. I'm assuming the "B" stands for Brasil, but have otherwise been unable to find any historic info about it. The source calls many Zoop funcs/classes, but does not include them in the project, so I'm assuming this was broken or abandoned. "Jabbernaut Carb Z2.5.mcp": This is a Carbon build that may not have been finished before being abandoned. It has several problems in the code, such as needing casts to UPP's for AppleEvents, just to start... May have not been finished before being abandoned. I may or may not work further on getting these versions building, as they may provide clues as to what is going wrong by crashing/failing in different ways from the standard PPC build (maybe showing different error numbers?). If we end up having to fix a lot of things, the "TOQ" version may be useful because it is smaller (ie leaves things out we wouldn't have to fix)...maybe? And the Carbon build would be nice because we'd be able to use XCode (eventually) and the its much more modern debugger! ---- m68k support... I've created "Jabbernaut m68k.mcp", by taking the PPC project, changing the target type to m68k, and replacing all the PPC libraries it uses with the m68k CW6 (and GUSI and JLIb) equivalents. It compiles, but does not link, giving several "16 bit reference out of range" errors. I made sure to use the "Large" memory model, 68020 instructions, have all the "Far" settings turned on, and am using 4 byte ints (and struct alignment) with their corresponding MSL and other libraries, so I don't know what is causing this (those are all the usual suspects)...but will figure it out...signs are good it will work since it compiles the same as the PPC version! ---- Ideas for next steps... While building, CodeWarrior 6 reports several warnings "Illegal access to private/protected member". It is VERY puzzling that these are warnings and NOT errors, as these seem to not be legal C++, and clearly mistakes...but if it is illegal, why does it compile?!? I'm going to be looking very closely at these, and see why it is flagging, but allowing, the code at those points. They could be clues as to what is going wrong. The project file builds Zoop from source, and I am building OpenSSL using the same (known to be working...I hope) version I used for Goliath. It currently uses the supplied pre-built copies of GUSI and JLib, and possibly others. Building EVERYTHING from scratch would allow us to be sure compiler settings were all the same, there weren't any conflicts with different library headers, etc etc...not likely to actually help, but never (totally) trust a pre-compiled binary when you have the source right there!!! I've been doing most of my building in ShapeShifter, which is unable to run MacsBug (as it doesn't implement the PPC MMU)...by using real PPC hardware, I'll be able to see the function where the crash is occurring and will start figuring out what is going on...stay tuned...
Last Edit: April 23, 2024, 03:06 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #4 on: April 23, 2024, 17:14
|
github repo is at https://github.com/laulandn/Jabbernaut_build Do NOT clone or pull the repo and build from that...github does not preserve Mac resource forks, or file types and creator codes. Use this instead: https://github.com/laulandn/Jabbernaut_build/blob/main/Jabbernaut_build.sit Which has the same contents, but stuffit'd.
|
Knezzen
|
Administrator 512 MB Posts: 608 Village idiot
Reply #5 on: April 23, 2024, 19:18
|
Wonderful! 
|
garambo
|
16 MB Posts: 29 System 7 Newcomer!
Reply #6 on: April 24, 2024, 00:41
|
I saw the previous discussions some time ago and as soon as I had the chance I had to give this a try! All your project fixes have been great, thank you so much for your work @lauland! I was able to get it working without many issues, just found that the first line of code from the StartUp method in JabberApplication.cpp triggers a user break that can be caught only with Macsbugs: Screenshot(PNG) For reference: DebugStr("\pJabberApplication::StartUp()"); Not really familiar with this method call (or with C++ programming on Classic Mac OS with CW), but getting rid of it, allows the application to run smoothly even without a Release target. With the instruction back, I got error code 12 running natively on my Power Mac G4 with OS 9 and the application simply closing on OS X (through Classic on G5) Here it is running through classic on my G5 (connected to the Macintosh Garden services): Screenshot(JPG)
Last Edit: April 24, 2024, 00:57 by garambo
|
garambo
|
16 MB Posts: 29 System 7 Newcomer!
Reply #7 on: April 24, 2024, 13:26
|
Also took some time to try a 68k build, the link errors can be solved by tweaking the C/C++ compiler settings (Target> C/C++ Language) to: - Inline Depth: Smart - Pool Strings: Disabled When running on a G4 (Mac OS 9) with Macbugs, I noticed an issue exception reading long word std::basicstring, so I figured I could add back the Pool Strings option. Got the 68k Build to run and connect to the MacintoshGarden service on PPC Macs (both emulated and native). I was able to get the build running on System 7 (on Basilisk II), but I wasn't able to connect, when logging in I get: - A regular error message: Login Failed Error ID 1002 - A crash, with the application quitting with error type 27, 3 or 4 Basilisk II screenshot: https://revontulet.org/2024/04/24/69ac439e220348d5a777cbb03fdd49bc.jpg Similarly, with an incorrect login I am able to get the correct error type, in sequence: - Incorrect Username/password - Login Failed - Crash Could it be something related to writes to the profile/preferences? I didn't have the chance to dig deeper but a Chk error I saw once, plus the writes done on the connection handler to the profile/prefs managers tells me something might be wrong there for m68k. It would be interesting to see what happens on a native 68k machine with a debugger as I don't seem to have luck with 68k emulators, but I don't have any that could work at the moment (too much to ask to my SE FDHD) 
|
Knezzen
|
Administrator 512 MB Posts: 608 Village idiot
Reply #8 on: April 24, 2024, 17:45
|
This is soooo exciting! Can't believe this is actually happening at last. Don't know how to express the level of gratitude I feel like now. Amazing work, guys! Quote from: garambo I was able to get the build running on System 7 (on Basilisk II), but I wasn't able to connect, when logging in I get:This is a known bug in 7.x and 68k. It will connect and work fine if you collapse all the categories in the roster. Must be something with the icon handling or the way it renders the contacts names that's incompatible with 7.x. My guess at least. Is there anyway to get a hold of the modified sources, garambo? I can set up a new upload folder on Hotline or such to keep some kind of rudimentary version handling of the sources.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #9 on: April 24, 2024, 18:12
|
"And you, young Skywalker; we shall watch your career with great interest." garambo you rock! I'm not even going to start on how silly I feel about that DebugStr being RIGHGT UNDER MY NOSE. "If it'd been a snake, it'd bit me!" And "Smart" is better than "Large"? I had no idea. No idea. I thought "Smart" meant "Do 16 bit references when you can but if you have to 32 bit", as in, it was the safest option at the risk of generating larger/slower code. But it really does seem to mean "Smart" (ie mix at will?) FYI I actually had turned "pool strings" on AFTER I got the link errors first time, and it didn't help...and may have made it worse?!? I did that because I ran into problems building Goliath m68k and it seemed to help...I don't even know what it really does...it either "uses the same copy of a string if they are the same to save memory but risk if they are writable" or "puts all the strings together in memory". If the second, yes, that could make references farther and the 16 bit problem WORSE. ---- You did some amazing sleuthing there! A+ work! Gold star! No...TWO GOLD STARS! Since it basically works (on both platforms even if still buggy), if you like, you can (and should) have the honor of uploading the working ppc and m68k apps to macintoshgarden.org here https://macintoshgarden.org/apps/jabbernaut (And replace downloads 8 and 9 with a source/build folder if you wanted) Here's a fun thing to decide...what version are we going to call this mutant...we could stick to 0.6d1 since that's what the author had...but confusing if it is newer than 5.5b1...but computer people are whimsical with version numbers and it would be funny to have the version number go lower! (And actually make it clear that this a new thing and NOT from the original author but instead a hack effort). As far as sharing amongst ourselves, I don't care and don't expect people to learn or use git/github unless they want to. Doing it via shared files on hotline sounds fine! ---- NOTE: The PPC build STILL doesn't start with a strange error when ran on SheepShaver, but does NOT (and works fine) on real ppc hardware. Strange!
Last Edit: April 24, 2024, 18:38 by lauland
|
garambo
|
16 MB Posts: 29 System 7 Newcomer!
Reply #10 on: April 24, 2024, 19:41
|
Thank you! Happy to help!  I've added the new sources and the two debug builds (68k and PPC) on the Jabbernaut page on the Garden (decided it might be good to keep downloads #8 and #9 for historical reasons): https://macintoshgarden.org/apps/jabbernaut Quote from: lauland I'm not even going to start on how silly I feel about that DebugStr being RIGHGT UNDER MY NOSE. "If it'd been a snake, it'd bit me!" You can't imagine how many times it happened to me! The joy of software development! Quote from: lauland As far as sharing amongst ourselves, I don't care and don't expect people to learn or use git/github unless they want to. Doing it via shared files on hotline sounds fine! It would be great for me! We can use your repo to keep working on it!
|
Knezzen
|
Administrator 512 MB Posts: 608 Village idiot
Reply #11 on: April 24, 2024, 21:45
|
Wonderful, garambo! Downloaded your sources and project files and Jabbernaut builds fine on my TiBook now. Time to go hunting for those nasty bugs I'm fed up with having to live with on a daily basis  Thanks again!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #12 on: April 25, 2024, 05:00
|
Well, I've tossed my Jabbernaut_build folder, and am building fresh from "Jabbernaut_CW_Project.sit" from the MG page...so hopefully we'll stay in sync! ---- Probably obvious, but the "Smart" setting I was talking about was the wrong one...you meant for inlining depth and I thought it was memory model! Memory model does seem to need to be "Large" and not "Smart" for m68k! As far as the version number, I was derping when I called the last version released by the original author "5.5b1"...it was really "0.5.6b1". And since what we have in our hot little hands reports as "0.6d1", it looks pretty clear that we are dealing with his work post last release. And it was probably abandoned before he finished it...which may mean who knows how buggy....or not? ---- Interestingly the m68k version, when run on Shapeshifter, shows the same strange negative zoop error (-1856) as the PPC version. Guess I shouldn't be surprised, but was disappointed, as hoped it'd help be a clue why it won't run...oh well... I took a quick look at the "illegal access to protected/private member" WARNINGS and none of them seem blatantly bad or actual problems...the data members should maybe have accessor functions, and there's at least one function that is protected that could (should?) be public. Maybe he just didn't want to make too many classes friends of others...which I agree with basically. It can break down the encapsulation and protection. The original author was obviously not happy with what he had, as in PrefsManager.h he has: "FIX ME - these friend declarations are evil!". I still think they should be ERRORS and not WARNING and codewarrior shouldn't have allowed the code to compile as is...they are not legal C++. ---- I'm thinking I might work on the Carbon version...at least see how far it can get. The original author has a note at the bottom of PrefixBase.h: /* note: as I write, the new Carbon printing Manager API has been released, but CarbonLib does not contain the implementation of it. Until it does, you can't print using the new API, and compiling will generate link errors. To work around this, we use a special switch here to supress the new carbon printing stuff until we can actually go with it. */ By "CarbonLib" he means the MacOS 8.5/9 implementation of Carbon (not the MacOS X one)...so this gives us a good insight into what was going on in the Mac world when he was working on the code. MacOS X, and Carbon, were very new. This means his Carbon work was very early, and who knows how far he got, or how well it works...will be interesting to see...
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #13 on: April 25, 2024, 08:44
|
Amazing, you guys! This is, once again, inspirational. Also, good call on preserving the previous source code for historical reference! As long as the labeling is clear, this always helps! Issues right under our nose CAN easily take a whole week, OR longer, for us to notice and do something about. Very relatable! It's basically what a dev job is like all the time, minus an angry customer, and/or your boss...
|
Bolkonskij
|
Administrator 1024 MB Posts: 2023
Reply #14 on: April 25, 2024, 08:58
|
Absolutely amazing job, guys. Everyone involved, a big thumbs up from me!!
|
|
Pages: [1] 2
|
| |||||||||||||||
|
© 2021 System7Today.com. |
