I was previously maintaining an mbedTLS fork for classic/Carbon Mac OS (https://github.com/bslabs/mbedtls) for use with libssh2, they were still keeping C89 compatibility at the time which was helpful.
Newer versions of CodeWarrior do support C99, but I can't remember if Pro 6 (the last version with a 68k toolchain) does. My go-to was Pro 8, since it's Carbonized you can run it natively on OS X (PPC or under Rosetta 1). It's possible to take the Pro 6 68k tools and use them in Pro 8 as well: https://github.com/macssh/macssh/wiki/Using-CWPro6's-68k-too...
As an aside, I empathize with the author’s struggles to insert files with resource forks with resource forks-oblivious git. What I’ve done before is use AppleDouble as a post-compilation step and git hook to separate resource forks into separate files and reconstruct them - it was included in A/UX for precisely that reason.
> That last bit -- addressing the path limitations -- is a big one. You know how you can write #include "mbedtls/aes.h", and the compiler will pull in code from the aes.h file that's in the mbedtls folder? You can't do that on a Mac! Or at least I couldn't figure out how Codewarrior defines paths.
I believe you use colon as a path separator. At least that's what I remember from working with CW back in the 90s.
I thought long long was 64bit on CW 4 on m68k. Was it not?
This is sick. I know Classilla, our last somewhat modern web browser, was having issues with SSL/TSL stuff at the end. Maybe this opens the door for some smart hero to revive it a bit.
A catch-all solution, that I've been using for many years, is to have a MITM proxy on the network do transparent TLS upgrading for everything that passes through it.
Then you'll inevitably run into other more nefarious forms of user-agent-discrimination via TLS fingerprinting[1], in which case https://news.ycombinator.com/item?id=43571099 will also be useful.
[1] Seeing a TLS 1.3 connection from a system identifying itself as Mac OS 7 will definitely trip a lot of "bot detection" software.
Yes, a proxy is the most obvious solution, but quite a bit impractical as you need to keep some other computer/rPi running. It ruins the feeling of being able to use _just_ the retro system to connect to the Internet. Regarding the user-agent, we could just spoof that.
I was previously maintaining an mbedTLS fork for classic/Carbon Mac OS (https://github.com/bslabs/mbedtls) for use with libssh2, they were still keeping C89 compatibility at the time which was helpful.
Newer versions of CodeWarrior do support C99, but I can't remember if Pro 6 (the last version with a 68k toolchain) does. My go-to was Pro 8, since it's Carbonized you can run it natively on OS X (PPC or under Rosetta 1). It's possible to take the Pro 6 68k tools and use them in Pro 8 as well: https://github.com/macssh/macssh/wiki/Using-CWPro6's-68k-too...
What about targeting Retro68 instead? Then the C version would not be a problem.
As an aside, I empathize with the author’s struggles to insert files with resource forks with resource forks-oblivious git. What I’ve done before is use AppleDouble as a post-compilation step and git hook to separate resource forks into separate files and reconstruct them - it was included in A/UX for precisely that reason.
https://en.m.wikipedia.org/wiki/AppleSingle_and_AppleDouble_...
I found Rez to be a really good option, see https://github.com/macssh/macssh/blob/master/macssh/source/A... or https://github.com/macssh/macssh/blob/master/macssh/source/t.... Modern macOS still includes Rez and DeRez too!
And new-enough CodeWarrior should be fine with regular \n line-endings and '/' in #include.
Related: TLS 1.2 and 1.3 on Windows 3.1 https://news.ycombinator.com/item?id=36472854
> That last bit -- addressing the path limitations -- is a big one. You know how you can write #include "mbedtls/aes.h", and the compiler will pull in code from the aes.h file that's in the mbedtls folder? You can't do that on a Mac! Or at least I couldn't figure out how Codewarrior defines paths.
I believe you use colon as a path separator. At least that's what I remember from working with CW back in the 90s.
I thought long long was 64bit on CW 4 on m68k. Was it not?
This is sick. I know Classilla, our last somewhat modern web browser, was having issues with SSL/TSL stuff at the end. Maybe this opens the door for some smart hero to revive it a bit.
A catch-all solution, that I've been using for many years, is to have a MITM proxy on the network do transparent TLS upgrading for everything that passes through it.
Then you'll inevitably run into other more nefarious forms of user-agent-discrimination via TLS fingerprinting[1], in which case https://news.ycombinator.com/item?id=43571099 will also be useful.
[1] Seeing a TLS 1.3 connection from a system identifying itself as Mac OS 7 will definitely trip a lot of "bot detection" software.
Speaking of MITM proxy, which one do you use?
Currently doing some interesting experiments on a bunch of Legacy Windows VMs. ;-)
Yes, a proxy is the most obvious solution, but quite a bit impractical as you need to keep some other computer/rPi running. It ruins the feeling of being able to use _just_ the retro system to connect to the Internet. Regarding the user-agent, we could just spoof that.
>It ruins the feeling of being able to use _just_ the retro system to connect to the Internet
Surely there's a modern modem in the way somewhere?
In all fairness, we use proxies without realizing it.
This would have been really handy when I was porting my Matrix client to OS8/9. Thanks
How far were you able to get with that? Matrix on OS8/9 sounds great.