MetaCard

[richmond62]

Tangentially . . .

I wonder why the Windows version will not run on MacOS with WINE . . .

http://www.canelasoftware.com/metacard.html

And, as the whole MetaCard IDE has been Open Sourced (interesting verb that), it is 'fair game' and we can use whatever we want from it.

[tperry2x]

I wonder why the Windows version will not run on MacOS with WINE . . .

What version of MacOS are you trying to run this on?
Does your MacOS & version of Wine support 32-bit?

Runs here via a 32-bit wine instance:

Screenshot at 2024-11-22 17-41-00.png (111.24 KiB) Viewed 3351 times

[tperry2x]

The funniest thing. Well, kind of makes sense, but shouldn't.
If you save a copy of the "mctools.mc" stack out of metacard, open it in OXT/OXT Lite/LCC
It'll open, and then it'll throw loads of errors about stacks having the same name (because that mctools.mc contains all the same stacks that make up the individual stacks in LCC - LC basically just lifted *everything* out of there into seperate stacks).

Even the script editor, the error dialogs the message box. Everything. An IDE within an IDE
had to end up force quitting it, but it was obvious how much of the LCC IDE is just straight lifted from MetaCard. They haven't even tried to change the names of the stacks.

funniest-thing.png (299.2 KiB) Viewed 2913 times

[OpenXTalkPaul]

The funniest thing. Well, kind of makes sense, but shouldn't.
If you save a copy of the "mctools.mc" stack out of metacard, open it in OXT/OXT Lite/LCC
It'll open, and then it'll throw loads of errors about stacks having the same name (because that mctools.mc contains all the same stacks that make up the individual stacks in LCC - LC basically just lifted *everything* out of there into seperate stacks).

Even the script editor, the error dialogs the message box. Everything. An IDE within an IDE
had to end up force quitting it, but it was obvious how much of the LCC IDE is just straight lifted from MetaCard. They haven't even tried to change the names of the stacks.

funniest-thing.png

Yeah I went through all of that while trying to see what bits I could scavenge from the MC IDE (I copy-pasted some of it directly into the OXT Web Playground thing )

[richmond62]

For quite a long time there was a film on a certain website giving the impression that LC rose sui generis from the mind of one man.

https://youtu.be/C8RD4SVOyVs

Nothing could be further from the truth.

https://preserve.mactech.com/articles/m ... index.html

The only 'hint' in the film is the statement "a revision of . . .".

RunRev was conceived of, initially, as a GUI (i.e. front end) for MetaCard that would be easier for new programmers to use than the original MetaCard GUI; and it was.

At some time the MetaCard Corp. went bust and the MetaCard people GAVE all the MetaCard code to RunRev.

This resembles my buying a brick house and shoving a fascia on the front so it looks as if it is built of stone.

For quite a time it was possible to take the MC GUI, "disembowel" it (remove the old MC engine) and plonk a RunRev engine inside it so one would end up with the MC GUI fuelled by a RunRev engine.

In 2003 I "rejigged" the RunRev GUI (Horizontal Toolbar with icons for all sorts of objects for which there were no icons at that time), and the whole exercise was relatively simple: as I am most definitely NOT a programming genius I should know.

So, up to a certain point at least, RunRev was just MetaCard with "Christmas Glitter": that is not meant to run that effort down: personal experience when I discovered both MC and RR prove to me that the RunRev GUI was far, far more user-friendly that the MetaCard one.

That a lot of the MC is still "there" does not really surprise me: what I do feel is a bit disingenuous is how RunRev/LC has been presented: and all the blether anent it being something 'new', when it is, still, more like stuff tacked onto MC: admittedly to such a large extent that unless one does a bit of digging its MetaCard origins are not apparent.

[FourthWorld]

At some time the MetaCard Corp. went bust and the MetaCard people GAVE all the MetaCard code to RunRev.

On the contrary, MetaCard Corporation is likely among the most successful of xTalks in terms of ROI, and was acquired through purchase for a nontrivial amount.

When you have a question about xTalk history, feel free to ask. Inventing answers to your questions is less likely to result in factual portrayal, and others who read such guesses may mistake them for fact.

This resembles my buying a brick house and shoving a fascia on the front so it looks as if it is built of stone.

That could apply to any interface. How computers work and how they're presented for usability are very different.

This is fundamental, extending all the way down to even file systems: folders are presented as containers, but if we look at the underlying structure we see nothing could be further from the truth; they're just a special type of file. When we "move" a file into a folder, the file never moves. All that happens is a pointer to the file is deleted from one "directory" file and added to another. This extends to even "files" themselves, which are not discrete objects but just allocations of sometimes even discontiguous portions on one long byte space.

Everything in computing is smoke and mirrors, necessitated by their alien binany mechanics and the limitations of human cognitive process.

For quite a time it was possible to take the MC GUI, "disembowel" it (remove the old MC engine) and plonk a RunRev engine inside it so one would end up with the MC GUI fuelled by a RunRev engine.

The xTalk world has two main branches of architecture: engine UI and scripted UI.

When the dev UI is provided in the engine, users get a more performant experience in which IDE operations can't interfere with user scripts because the IDE code runs outside of script space. The tradeoff is much higher cost to the vendor, and fewer opportunities for developers to customize the environment. Examples of this type include HyperCard, Oracle Media Objects, and Spinnaker Plus.

When the dev UI is scripted, performance is measurably and sometimes even observably slower, and care must be taken by both the vendor and the user to maintain awareness that user scripts and IDE scripts are running in the same execution space. The benefit is MUCH faster development of UI features, and nearly infinite customization by the user. Examples of this type include SuperCard, Gain Momentum, and MetaCard/RunRev/LiveCode.

With scripted IDE UIs, when the app launches the engine is hardwired to look for a specified stack file, which it then opens. The rest of the IDE environment is then set up by the scripts in that specified file, invoking any number of other stack files. SC, TB, and MC/LC each differ in the details of how they find that first stack file (TB's boot sequence is hands-down the most complex, mostly due to DLLs strewn all over the hard drive as was common with Win apps back in the day), but the basic sequence is pretty much the same for all.

In MC, the engine first looks for a file named mcmini.mc in the same folder as the engine executable. If that isn't found it looks for mctools.mc. mcmini was apparently a very barebones toolkit scripted from the command line so there could be a GUI environment in which to make mctools.

In LC they added a third file to the sequence to boot its own environment.

But even with the LC IDE running, it's all just stack files, and nothing prevents opening mctools.mc and then purging the LC stacks from memory. Many of us did that for years. Jacque and I collaborated on a tool to a automate that back when we were still using the MC IDE with the acquired engine. The LC engine team generously added the messageBoxRedirect global property to support that effort (and anyone else wanting to make a drop-in replacement Message Box).

The key here is that there is no "MC engine" as distinct from the "LC engine". There's one engine, which can be used to open any stack files one wants to use as their development environment.

That a lot of the MC is still "there" does not really surprise me

Nor anyone else. They acquired it to use it, and those portions that continue to serve design goals of the new product have remained in place.

what I do feel is a bit disingenuous is how RunRev/LC has been presented: and all the blether anent it being something 'new', when it is, still, more like stuff tacked onto MC: admittedly to such a large extent that unless one does a bit of digging its MetaCard origins are not apparent.

Your dislike for the company is well known. But they've made no secret of having acquired MC. On the contrary, back when it was relevant news they announced it broadly across the software ecosystem, eg;
https://www.mactech.com/2003/07/08/runt ... ogy/?amp=1

That they don't make an acquisition from two decades ago the centerpiece their messaging today is understandable. Few knew of MC at the time, fewer even remember it today.

And with mobile, Skia, Unicode, nested arrays, vast clipboard options, improved and expanded network I/O, M-series compatibility, and a great many other enhancements, there's relatively little of the engine code they'd acquired that hasn't been at least revised if not entirely new.

[richmond62]

Your dislike for the company is well known.

And you tend to go in for blanket statements that oversimplify things.

I do not dislike that company: but I do have some differences of opinion.

1. Without Kevin Miller's great efforts we would have no LiveCode, nor any OXT. It would be ludicrous to 'dislike' a company that has provided
me with tools I have used on a day-to-day basis for about 23 years.

2. Without Mark Waddingham's great efforts LiveCode and OXT would not be Unicode complaint.

My 'problems' with the company come down to 2 fairly basic things:

1. That they have not kept a lot of promises they have made in the past.

2. The unbelievably shoddy state of the Dictionary (and the extent to which it is shoddy has only really become apparent to me when I embarked on what I, naively, envisioned as an afternoon's work which turned out to probably come down to at least 100 hours).

Had I 'disliked' the company (as you state) I would not have donated 3 sums of money to them.

[richmond62]

Nor anyone else.

Well it appears to have surprised at least one person.

[tperry2x]

The key here is that there is no "MC engine" as distinct from the "LC engine". There's one engine, which can be used to open any stack files one wants to use as their development environment.

As an aside, there are huge distinctions between the Metacard Engine and the Livecode Engine. The underlying codebase, the sheer amount of extra requirements and functions the Livecode engine has in place (embedded in place as part of the C++ source) when compared to the minimal Metacard engine, mean both are very very different and definitely distinct from eachother.

[tperry2x]

Well it appears to have surprised at least one person.

It's like sticking a Ford Sierra engine in a Toyota and seeing it run, when I really didn't expect it to.
That's where the analogies end though because although the LC engine can open MC stacks, MC does not seem to be able to open .rev stacks.

[FourthWorld]

The key here is that there is no "MC engine" as distinct from the "LC engine". There's one engine, which can be used to open any stack files one wants to use as their development environment.

As an aside, there are huge distinctions between the Metacard Engine and the Livecode Engine. The underlying codebase, the sheer amount of extra requirements and functions the Livecode engine has in place (embedded in place as part of the C++ source) when compared to the minimal Metacard engine, mean both are very very different and definitely distinct from eachother.

That's more a function of continued development. There was a version of the engine owned by MetaCard Corp that could open any stack files made at the time, and more recently there's a later version of that engine now owned by Live code Ltd that can open any stack files.

Whatever stack files comprise one's development environment has been and remains a user choice. All the while, until this FOSS fork, there has not previously been a period of parallel engine development by separate teams.

[FourthWorld]

Nor anyone else.

Well it appears to have surprised at least one person.

Well what we've learned in this thread is that at least it isn't you and it isn't me.

I can't claim to have discussed the matter with all 8 billion people on this planet, and if I've missed the comment which imagines a company would pay good money to acquire a set of components and then discard some of the working ones just to rewrite them again from scratch for no reason, it's probably just as well.

[FourthWorld]

Well it appears to have surprised at least one person.

It's like sticking a Ford Sierra engine in a Toyota and seeing it run, when I really didn't expect it to.
That's where the analogies end though because although the LC engine can open MC stacks, MC does not seem to be able to open .rev stacks.

That's just the answer file filter. Predating the .rev extension, the MC scripts could not have anticipated the extension later used by the acquiring company.

And it may be that you're using an older MC version. IIRC those scripts were updated at some point after the acquisition to make .rev files selectable, either during my tenure as MC maintainer, or perhaps under KenRay or Klaus Major.

There's an even more recent update to MC which Bogs posted to the LC forums which I believe may even extend the filter further to support .livecode.

[tperry2x]

And it may be that you're using an older MC version. IIRC those scripts were updated at some point after the acquisition to make .rev files selectable, either during my tenure as MC maintainer, or perhaps under KenRay or Klaus Major.

Yes, - I should have mentioned that saving a .rev file out of OpenXTalk, then changing the extension to .mc does work - however not all the time. It's probably the case that some elements you can drag into the stack in LC/OXT/OXTLite just have no equivalent control or representation in Metacard, so hardly surprising I suppose.

However, it's more of an informational piece in case anyone thought that Metacard could seamlessly work with .rev/.livecode/.oxtstack stacks - your mileage will vary, and nothing is guaranteed of course. But then Metacard is now very old, so again, not surprising.

This is also what I meant about the Metacard engine and the LCC/OXT engine being substantially different.

[FourthWorld]

However, it's more of an informational piece in case anyone thought that Metacard could seamlessly work with .rev/.livecode/.oxtstack stacks - your mileage will vary, and nothing is guaranteed of course. But then Metacard is now very old, so again, not surprising.

A great many features have been added to the engine that are far outside the scope of the the MC IDE scripts and UI are designed to handle.

MC was always a sparse UI. The attraction it held for those of us who continued using that IDE after RunRev acquired the engine wasn't for its features, but merely that it stayed out of the way of our own tools cleanly and gracefully.

This is also what I meant about the Metacard engine and the LCC/OXT engine being substantially different.

Yes, as a demarcation of versions. OXT aside, there was only one engine, which ran both IDEs.

[OpenXTalkPaul]

I’ve had an old iPad 5th gen handed down to me to tinker with, so of course this weekend I went down the jailbreak rabbit hole and came out with a semi-untehered rootless thing, not quite full p0wnd (or whatever the kids call it theses days), but close enough, thanks to a tool called Dopamine.

So then I could finally try out the iOS builds of MiniVMac and BasiliskII (68k Mac emulators). Great nostalgic fun! Super easy, even shares its folder to the emulated Mac so I can download stuff with Safari and use Files to copy it to where I can accesses it inside the emulated Mac.

87AA3173-0BFD-4875-A587-0EB142174DC3.png (398.73 KiB) Viewed 2657 times

[OpenXTalkPaul]

There's an even more recent update to MC which Bogs posted to the LC forums which I believe may even extend the filter further to support .livecode.

Actually from what I've seen (by opening binary files in coding-text/hex editors) there is at least minor difference between the file formats .mc and .rev but it's only like a 'magic umber' difference' (IIRC) .mc files start with a shebang (like a bash script). So I would think it would be more (just slightly) than simply adding .rev/.livecode /.lc to the answer-file file extensions filter.

Also, thanks any historical corrections. From the beginning one of the things I hoped OXT community could build (besides an AppleSilicon native-engine) some holistic-history of xTalk, and so I would like to stick to historically accurate comments on this site, sans any feelings about company X or company Y. I have read a little about when RR acquired MC and when old MC IDE was basically donated to the public during that time, but the other details I find very interesting.

I wouldn't exactly call an article in MacTech magazine big announcement though. I'd heard of most of the others that we've covered in this 'xTalk Implimentations' forum, I'd heard of Dan's Serf even (that beta was floating around on Mac 'Hotline' servers for a while, but I'd forgotten about it until recently). In contrast, I don't think I ever even heard of MetaCard (nor RuntimeRevolution for that matter), until around 2014 when I 'discovered' LiveCode Community after the initial crowd-funding success. It must have been fairly obscure, but then again even HyperCard is obscure at this point in history.

One thing I'd push back on a little is about IDE in Application Code versus being built with stacks/script in IDE itself (and I also understand Richard is a fan of SuperCard's bespoke 'IDE-editor' approach). I feel like HyperCard does not quite fit into a category there. Some of it's IDE/UI was built into the computer's ROM file ( like the color picker), some of it was in the HC application binary (engine), other bits where added as CODE resources (XCMD/XFCNs + UI resources, ICONs, icns, WDEFs, DLOGs, etc.) on top of the 'engine', AND some of it was indeed stacks (Home, HC Help, Color Tools, etc.) or built-into those stacks (resource forks), so there could be both some level of separation of the IDE UI from Stack Author's project UIs, but you could also customize the IDE to your liking to some degree to build your own 'tools' palette, quite easily in fact. I had a bunch of 'messageBox short-cuts' (typing 'rc' to open a 'resource copier' window'), plus extra 'power tools' type palettes built into my HyperCard Home stack. And being that they some of it was compiled code resources it was a bit isolated from the user's stack UI.

But I do really like that concept, I've wondered for some time now if it would be helpful to make something like a 'New Tools' palette where the 'business' back end, by virtue of being an extension running in the UI thread rather than script execution context, is significantly isolated from the IDE user's work and any messages the user's stack UI might want to send/ or respond to, would help the IDE run better, and provide a better experience in the end. At one point I started to modify a copy of the 'IconSVG Picker' (which is a widget) to behave a bit like the HC 'Palette' XCMD & Palette-Maker stack, so that a user can quickly and easily build a simple 'buttons-grid' style paltte stack.

[OpenXTalkPaul]

I don't think I ever even heard of MetaCard (nor RuntimeRevolution for that matter), until around 2014 when I 'discovered' LiveCode Community after the initial crowd-funding success. It must have been fairly obscure, but then again even HyperCard is obscure at this point in history.

Then again to be honest by 2003 I think I was hoping for something like ApplescriptObjC + Interface Builder to fill the indy/hobbyist-coding void left by Jobs killing off HyperCard. I remember a feeling of defeat and disgust with the company back when the HC End Of Life announcement was made, and I was looking to move on from xTalk-scripting all together by 2003 (who knew how long the 'Classic Environment' environment was going to last? Not much longer by then). So I probably was not looking for a 'New HyperCard" much by then.

"Runtime Revolution Acquires MetaCard Technology
Now Poised to Deliver New Generation of User-Centric Development Tools

Edinburgh, Scotland, July 8th 2003

“MetaCard has been in development for over 12 years and has attracted a
loyal following. This sale will allow the technology to break through
barriers it never could before,” said Scott Raney, President of MetaCard

Ah, that's interesting. 2003 minus 12 yrs put it at 1990-1991 being when the development of this engine began. That's when I figured, but this quote solidifies it. As has been pointed out, the MetaCard 'engine' was an earlier version of the very same engine that OXT is built on. This code base is about 35 years old! And it's been compiled/ported to run on about every 'desktop' platform with or without a GUI since then! I think that would be really impressive history for any project!

Speaking of 'ports' of the engine, I found it strange that I was able to run MetaCard v2.5 on macOS 8.1 with emulated 68k Mac but not RunRev 2.6. RunRev 1.1 (FAT PPC+68k) ALMOST runs but there seems to be some issue preventing it from working correctly. Since there was a 'Classic' and a an 'OS X' installer my guess is that the first thing they did when they took over as developers was to 'Carbonize' the macOS version of the engine, given that date that it would've been a top priority for Macintosh devs. So now I'm wondering 'was there a 68k version of CarbonLib' and/or 'CodeFragmentManager' for 68K which were both System Extensions, and so maybe all I need to do to get Rev 1.1 working in the emulator is to install those extension.
I'm dreaming but wouldn't it be cool if some anonymous person released '(not-quite-as-Open)xTalk Archeological Artifact Edition' for Moto 68K !

[FourthWorld]

Actually from what I've seen (by opening binary files in coding-text/hex editors) there is at least minor difference between the file formats .mc and .rev but it's only like a 'magic umber' difference' (IIRC) .mc files start with a shebang (like a bash script). So I would think it would be more (just slightly) than simply adding .rev/.livecode /.lc to the answer-file file extensions filter.

Are you having trouble opening stack files made with MC IDE?

For nearly the first decade of RunRev Ltd's existence, my only job was building stacks in both IDEs and sharing them across my machines and with others.

The engine of course changes between versions, but (aside from this recent OXT fork) there has been only one evolving code base from 1992 until today.

I've been moving stacks around for a while. If you're having trouble moving stack files between versions of the engine, let's look at the details of the error you're encountering.

Also, thanks any historical corrections. From the beginning one of the things I hoped OXT community could build (besides an AppleSilicon native-engine) some holistic-history of xTalk...

I used to think about writing a book on the history of xTalks, but these days I can't imagine more than a few dozen would want to buy it.

Writing a book is a lot of work; if I'm going to spend that much time on something with negative ROI I'm having much more fun these days designing tabletop games.

I wouldn't exactly call an article in MacTech magazine big announcement though.

I've seen no magazine focused on Mac development with bigger circulation than MacTech in it heyday, and that wasn't the only place the press release ran.

But yeah, looking back i suppose it was odd that Forbes didn't make it their cover story.

It must have been fairly obscure, but then again even HyperCard is obscure at this point in history.

There are possibly more people typing in JavaScript this month than the sum of all people who have ever coded in all xTalks combined.

So much of the world has changed, and Pascal-flavored languages have been a hard sell for a great many years.

One thing I'd push back on a little is about IDE in Application Code versus being built with stacks/script in IDE itself (and I also understand Richard is a fan of SuperCard's bespoke 'IDE-editor' approach). I feel like HyperCard does not quite fit into a category there. Some of it's IDE/UI was built into the computer's ROM file ( like the color picker), some of it was in the HC application binary (engine), other bits where added as CODE resources (XCMD/XFCNs + UI resources, ICONs, icns, WDEFs, DLOGs, etc.) on top of the 'engine', AND some of it was indeed stacks (Home, HC Help, Color Tools, etc.) or built-into those stacks (resource forks), so there could be both some level of separation of the IDE UI from Stack Author's project UIs, but you could also customize the IDE to your liking to some degree to build your own 'tools' palette, quite easily in fact. I had a bunch of 'messageBox short-cuts' (typing 'rc' to open a 'resource copier' window'), plus extra 'power tools' type palettes built into my HyperCard Home stack. And being that they some of it was compiled code resources it was a bit isolated from the user's stack UI.

It's possible to delineate pretty much anything in ways that would make classification impossible.

I was painting in broad strokes, here in this discussion of how IDEs in this engine are scripted stack files.

As someone who's used both HC and LC, you know the differences between them. Of course you can tailor your HC environment, but you can't completely replace it as you can with LC.

At one point I started to modify a copy of the 'IconSVG Picker' (which is a widget) to behave a bit like the HC 'Palette' XCMD & Palette-Maker stack, so that a user can quickly and easily build a simple 'buttons-grid' style paltte stack.

The Palette Maker and dialog tooling in HC was better than none at all, and given the much smaller set of controls available to scripters the limitations were maybe less noticeable than they would be in LC.

But I've had to make so many palettes with objects beyond just buttons that I much prefer what SC, Gain, LC, and OXT offer.

I just like working in xTalks, even more so when I get to enjoy the same flexibility regardless of window type.

[OpenXTalkPaul]

Are you having trouble opening stack files made with MC IDE?

Not at all, but because there is a difference in the file formats that must also be a difference in handling them somewhere in the IDE or Engine. That's also not a reason for wanting to know more about the file formats. I'd really like to have documentation for the various versions of the MC/RR/LC/OXT stack file format, but I don't think that already exists. That would be needed for any alternative xTalk to be able to import one of this stack formats. It would also be helpful for being able to extract media assets (PCM sound waves in particular) from them.

Writing a book is a lot of work; if I'm going to spend that much time on something with negative ROI I'm having much more fun these days designing tabletop games.

I completely understand, I have more or at least as much fun trying to write original music than anything else I do as a hobby. I used to enjoy drawing comic style pen and ink, and painting and airbrush (with actual airbrushes) more than anything until I started working on graphics for my daily bread and now that mostly feels like work.

When OXT was first forming around the somewhat shocking announcement of dropping the FOSS version, I was quite annoyed with reading some of the comments and attitudes I perceived (much like some of what I think irritates Richmond) where it very much appeared that people either didn't know or forgotten that LC wasn't the only worthy xTalk to ever have existed. Then I started to research what has become of any of the others, and was shocked to find not very much info on xTalk's at all, and many many dead links. Which had/has me thinking of digital obsolescence and how unique things like xTalk are largely going to disappear down an internet memory hole one day and it will be as if none of the works ever existed. So I started to read what I could find and collect links to things and look for articles from historical context.
Gain Momentum is a perfect example, you’re literally tho only source I’ve ever heard about that xTalk from. I couldn’t find anything about it anywhere online. It might as well have never existed.

Anyway, my thinking was to 'crowd-source' an xTalk book, there is things like 'GitBooks', so not it would not be a single person putting it together. Maybe you could contribute with a few corrections or some anecdotal stories. You are the only person on here who has had any sort of insider knowledge of any of these companies, so I think that would be great while it also wouldn't take too much of your time away from board-game dev.

I've seen no magazine focused on Mac development with bigger circulation than MacTech in it heyday, and that wasn't the only place the press release ran.

But yeah, looking back i suppose it was odd that Forbes didn't make it their cover story.

Snark aside... I just meant that I, like most 'casual coders' that the bulk of HyperCard users were, were not waiting for MacTech to arrive in the mail to read up on the latest CodeWarrior release or whatever, I seriously doubt many HyperCard refugees ever even heard of MacTech magazine (I'd only ever seen a few copies lying around in computer consultant side-business my boss was involved with). If they could have had that announcement happen like the day after Steve Jobs said he was killing off HC, that could've seriouly 'went viral' (of course that term didn't exist back then).