WASM wrapper

[OpenXTalkPaul]

I want to back track a bit because you mentioned recently that you have trouble finding anything on GitHub and IMO GitHub is (and GitLab and similar are) valuable resource for independent developer and free open-source projects.

If you click on either the GitHub link in the tag at the bottom of my comments, or go to the OpenXTalk page on GitHub and then click the 'Repositories' tab you will find that I have forked all the xTalk or xTalk-adjacent things that I could find on Github or OXT related things I've personally uploaded to repos there.

Here are direct links to those pages repos tabs:
73 related repos here
https://github.com/orgs/OpenXTalk-org/repositories
240 related repos here:
https://github.com/PaulMcClernan?tab=repositories

Some of the repos may only be OXT/xTalk 'adjacent' and/or pertaining mostly to my own dev interests (Music / MIDI data related)
What I do every now and then is I use GitHub's search to find repos tagged with a number of keywords like HyperCard, xTalk, AppleScript, Natural Language, LiveCode, etc. and then sift through the results to see if there may be something new that's of interest to the xTalk cause.

I've often thought it would be good to have an aggregate 'curated list of' page like "Awesome xTalk/xCard" list page, like there is for a bunch of other topics on Github.

For example this one for 'Awesome C++':
https://github.com/fffaraz/awesome-cpp view as regular webpage here: https://faraz.work/awesome-cpp/

That is kind of what I was thinking about when I added that (HTML-only) Links page on the OXT
website here: https://www.openxtalk.org/OXTLinks.html

Those are often my first stop when I want to re-find a project like ViperCard (which is GPLv3 licensed and is an effort similar to HyperCard Sim): https://www.vipercard.net/0.3/ (BTW, you can view the JS code for that, no obfuscation but 'minified', here: https://www.vipercard.net/external/vpc03amin.js)

I should move that links page into a GitHub-pages repo where I can edit it from anywhere that I have my phone and internet connection and where other people could contribute edits to it too. I need to edit that page anyway to remove the link to SuperCard.us as the old SuperCard site's domain has now been taken over by purveyors of internet-garbage and-probably malware.

[tperry2x]

Are you sure about these? I mean without turning on the browsers developer tools options (lie disabling 'local file restrictions'). If a browser has these capabilities enabled by default that seems like it would be serious security risks right there.

It seems to be the case that I can interact with files (albeit via scripting in JS, but I'm loading script and even sounds from subfolders from a local directory in my JS xTalk implementation). I have not turned developer mode on or allowed anything exceptional. This is in a default user profile in Firefox and Opera (Linux) and Firefox and Chrome (Windows) - all on several different computers (5 in total that I've been testing with). I should probably test it on MacOS at some point too, but I don't spend much time on that OS anymore.

And Node JS libraries often come in a web version and a desktop version, I'm sure there's reasons for that.

I was wondering about that earlier. Is it a bit like our IDE, where we have different syntax for the mobile version than the desktop version. Perhaps it's also true of NodeJS?

I'm talking about as-is, by default, because you can't ask a user to install a JS plugin, but you could include a web plug-in inside your desktop app packaged version, probably. In the past I've used Jazz-MIDI-Plug-in (installed into the System) and the Browser Widget to enable cross-platform MIDI instrument I/O, and that worked OK but people said it didn't work when I released a demo of it (because they didn't 'read the docs' that said you needed a browser plugin installed)

Yes, I don't want to have the user have to need to install anything. I haven't used NodeJS actually, just pure javascript as that's the most widely supported. No-frills, no-addons etc. The html page you load just calls the JS transparently in a browser, nothing special required, without the user having to do anything. The same way as javascript will work in a browser on your desktop with no internet if the ".js" files are in place, which is as simple as:

Code: Select all

<script src=xtalk.js></script>

Can a web page communicate with another web page (or inter process communication), or launch a sub process or slave-app?

It used to be able to, but this has largely been squashed.

As it should be squashed, for the same reason I doubt some of those other assertions.

Well, yes and no. There are always innovative ways around these restrictions of course. yes, inter-process communication was largely blocked, but it's still possible by opening sockets and the web page reading data from a desktop companion app. In fact, there's a few examples of commercial software that does this. (Senso, which is a safeguarding tool used in schools) / (printer drivers with companion web interfaces) - even Microsoft365 uses that approach to interface with Teams and document handoff between the online and desktop versions of it's apps.

I would prefer very liberal license. I'm more incline to try to help with that, but any FOSS license is good too. I don't want an xTalk author's scripts to be entirely dependent on, or otherwise permanently tied to the xTalk interpreter being used, that's what we currently have if the scripts use any syntax or feature that's only available with the MC/RR/LC/OXT engines. If you want to free your stacks/scripts work from that 'legacy' engine's GPLv3 license agreement, then your stacks/scripts must NOT be dependent on that particular interpreter to be functional. In order to detach our work from that legacy, we need to build an OXT-dialect compatible 'engine', ultimately that is what I want.

So are you saying we shouldn't improve upon the syntax and add our own? I mean, if we add our own additions - then you can't open that work created in the browser version in the desktop 'legacy' version (or whatever LC are calling it now) of LCC 9.x. But then, is the aim to ultimately leave the 'legacy' version behind and leave that existing as-is (essentially frozen software-wise). (a bit like Supercard now seems to be, Sadly).

[tperry2x]

I've often thought it would be good to have an aggregate 'curated list of' page like "Awesome xTalk/xCard" list page, like there is for a bunch of other topics on Github.

For example this one for 'Awesome C++':
https://github.com/fffaraz/awesome-cpp view as regular webpage here: https://faraz.work/awesome-cpp/

That is kind of what I was thinking about when I added that (HTML-only) Links page on the OXT
website here: https://www.openxtalk.org/OXTLinks.html

Yes, that kind of thing precisely. Just so nobody has to traverse folders upon folders upon folders of content just to get to a download link. (which, as you know, I've never found the option for in Github and have to use third-party downloader websites) / (or the Github CLI which is next to useless as it keeps giving up and does not resume reliably). - or says something about I've "whoa! - you've hit a download limit" some kind of BS. I'm not on a metered connection, so they need to stop being so miserly with download access.

Anyway, I digress - a plan HTML listing of things is definitely a great addition in my view.

[tperry2x]

Moving further off topic...
Speaking of Supercard, did you ever notice how in a standalone, you can create your app and run it - then change something in the stack (like the colour of a rectangle for example). Close the standalone, then reopen it. You'll see your modifications are still all there. So it saves back to itself somehow - almost keeping the executable and stack binary files apart somehow. In theory, once you'd built your Supercard standalone, it would be perfectly possible to carry on shaping it entirely through scripting after the fact (like you can do with LCC and our engine), but the difference is these changes aren't purely saved to RAM - they are written to disk - and back to the standalone.

[richmond62]

With which version of SC is this?

[OpenXTalkPaul]

Are you sure about these? I mean without turning on the browsers developer tools options (lie disabling 'local file restrictions'). If a browser has these capabilities enabled by default that seems like it would be serious security risks right there.

It seems to be the case that I can interact with files (albeit via scripting in JS, but I'm loading script and even sounds from subfolders from a local directory in my JS xTalk implementation). I have not turned developer mode on or allowed anything exceptional. This is in a default user profile in Firefox and Opera (Linux) and Firefox and Chrome (Windows) - all on several different computers (5 in total that I've been testing with). I should probably test it on MacOS at some point too, but I don't spend much time on that OS anymore.

Oh OK, you're talking about web page loading its own resources from sub folders here, as just as it would were the page being delivered from a web server. Safari doesn't allow any seperate .JS files to load unless you disable its 'local file restrictions' setting in its dev menu. This sort of thing could probably also be effected by certain headers being added to the page that enable Cross-Origin Resource Sharing (CORS: https://en.wikipedia.org/wiki/Cross-ori ... ce_sharing)

Normally a web page wouldn't be allowed to load/read resources from a folder that isn't a sub-directory, like users ~/documents/ or other 'specialFolderPath' like a preferences or temporary files directory, unless initiated manually by the end user.

I was wondering about that earlier. Is it a bit like our IDE, where we have different syntax for the mobile version than the desktop version. Perhaps it's also true of NodeJS?

Well yes, because Mobile Apps are containerized and using APIs that are similarly sandboxed like the way web apps are, while desktop apps typically have had much more broad and direct 'bare metal' access to hardware.

[FourthWorld]

Moving further off topic...
Speaking of Supercard, did you ever notice how in a standalone, you can create your app and run it - then change something in the stack (like the colour of a rectangle for example). Close the standalone, then reopen it. You'll see your modifications are still all there. So it saves back to itself somehow

Is that still true under macOS (as opposed to Classic)?

[OpenXTalkPaul]

it's still possible by opening sockets and the web page reading data from a desktop companion app. In fact, there's a few examples of commercial software that does this. (Senso, which is a safeguarding tool used in schools) / (printer drivers with companion web interfaces) - even Microsoft365 uses that approach to interface with Teams and document handoff between the online and desktop versions of it's apps.

I don't think that's quite correct. You are talking about software use a web interface, host/served by such an app (or API) on a socket/port to allow for selecting settings, the way HP printer drivers do. That's more like running a local web server, but only using it for a specific application and on a specific port, like the way Common Unix Printing System (CUPS) can serve it's interface on ports: 631, 515 and/or 9100, which you can then access by directing a web browser to loopback address 127.0.0.1:631

Screenshot 2025-03-05 at 5.25.44 PM.png (133.47 KiB) Viewed 15991 times

That's CUPS web interface is still present but disabled by default on recent versions of macOS.

[tperry2x]

Yes, although starting a webserver on a local port is just one way - some apps have "services" running (windows) which serve the same job with open ports (or via other protocols completely), making themselves available to browsers. The same is true under MacOS (and not limited to cups) - at least on MacOS 12 (which is as far as I've been able to test), via daemon processes, and on Linux via systemd (or sysinit for those that don't like / won't use systemd), or runinit (whichever is applicable).

Using my senso example, this has a system tray on windows (and ChromeOS) which runs as a hidden process. This can not only fully control the computer in unrestricted form (like a VNC server), but also can allow full control of any browser. Including overriding content that is shown in any browser and loading things from file.

One way of running shell commands through JS is via the reactJS method, which doesn't need you to install any packages - you just need to prepare your JS files properly, which is fairly easy.

If you did want to do this via NodeJS, here's another way.

If you want to enable this in Javascript (and just pure javascript), there's a workaround I believe for MacOS - if you put the following into your .js file:

Code: Select all

netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite");

(I know that shows Netscape - a long defunct browser, but that's just where the api comes from. I'm led to believe that's still a viable method)

The browser on MacOS should show the prompt about allowing the browser local file read and write access. Once the user allows that, then you are good to go. I do want to test that out further to see just how much MacOS allows and doesn't though. I will try and test on MacOS 12 and safari when I get a moment.

Another way does require the install of a small xterm utility, but have a look here, and the list of other software using it. Once installed, it allows access via terminal through xterm. Example script of how to do that is shown on their page.

Lastly, there's an alternative way to do this via websockets too.

The Supercard thing - I noticed it back when I used to use version 4.1.2 (haven't used it since of course), but will have to dig it out. The thing that made me think of it again was the topic about making changes to standalones, and that jogged my memory (pun not intended).

edit:
Here's a demo video of a standalone made for OSX (running in 10.6). Note how changes are recorded between launches.

Here's the supercard project attached, and the osx standalone.
Note - do not uncompress this on anything other than a PowerPC mac, as the standalone can be easily corrupted (still uses resource forks).

[OpenXTalkPaul]

Yes, although starting a webserver on a local port is just one way - some apps have "services" running (windows) which serve the same job with open ports (or via other protocols completely), making themselves available to browsers. The same is true under MacOS (and not limited to cups)

That's all interesting, but it seems like a lot of that is related to javascript running in NodeJS environment, or otherwise requires to have some known services/protocols running locally on some port / socket (like that Poweshell related link), or needs to install something additional (like NodeJS), not strictly running in a Web Browser.

I haven't tried some permissions meta you mentioned or websockets). Node and npm stuff seems a lot like running Python or JSX (Javascript for Automation) in a terminal.

I'm wrong and you can do that from a page in a web browser sandbox (once user permission is granted, which you know that is 'user interaction') than brilliant, should be able to satisfy a number of use cases where there would be no need to use any desktop wrapper app like Electron.

Certainly HTM5 has added a lot of APIs for various things, video, svg vector graphics, using the microphone, web audio, web geolocation, polling game pads, using virtual file systems, WebGL, and many other features in modern browsers that have been added of the years to enable ever more robust apps to be created for the web. Which is great, that's why I'm very interested in using a browser engine as an xTalk/xCard "engine". But for other cases where there's no way to access some native thing from a port, some private system API (like say CoreImage filters) for example, you may still need a Desktop App Wrapper or need to use somethings like Node.js React or whatever.

If nothing else, I'd like to have Engine / IDE that is as sneaker-net friendly, portable apps, self contained as possible. Like .app bundle or and .appImage

I looked it up, could not find HaikuOS port of Electron, but I did find that iElectron has been ported to FreeBSD ports.

[tperry2x]

That's all interesting, but it seems like a lot of that is related to javascript running in NodeJS environment, or otherwise requires to have some known services/protocols running locally on some port / socket (like that Poweshell related link), or needs to install something additional (like NodeJS), not strictly running in a Web Browser.

I've not implemented any shell-related stuff in my JS version yet - just testing stuff before I make it part of my main attempt, but it's interesting nonetheless. Without shell commands, the IDE is very limited, so I'd really like to add it.

I do understand the security implications of why this is usually blocked at every turn, but when running locally, those restrictions seem to be loosened. When running over a remote https / http connection, then yes - you really want that locked down to the n'th degree.

[OpenXTalkPaul]

I've not implemented any shell-related stuff in my JS version yet - just testing stuff before I make it part of my main attempt, but it's interesting nonetheless. Without shell commands, the IDE is very limited, so I'd really like to add it.

I know you're concerned about sharing the source, but is this shared on that collab MEGA account? if I can grok (F' Elon's AI, he can't have that word) how the syntax mapping works enough, I'd like to contribute to building up the syntax.

Running shell scripts is part of what Electron offers scripters (as an JS-based API of course) as far as easing the moving from a web app to desktop app with native features. And again Electron offers pre-made access to other platform specific things like Dock(let) or System Tray items, direct file system access (no need for user interaction once the app is authorized by user), with built-in Node.JS support, etc. on Mac, Linux, Windows and FreeBSD (and probably other OSes).

Thanks for fixing the mess I made of this thread, I was editing it at 3:30 AM here and I really needed to crash.

[tperry2x]

I know you're concerned about sharing the source, but is this shared on that collab MEGA account?

It isn't currently, but when I get in this evening (as currently on lunch break), I'll upload what I have.

Running shell scripts is part of what Electron offers scripters (as an JS-based API of course) as far as easing the moving from a web app to desktop app with native features. And again Electron offers pre-made access to other platform specific things like Dock(let) or System Tray items, direct file system access (no need for user interaction once the app is authorized by user), with built-in Node.JS support, etc. on Mac, Linux, Windows and FreeBSD (and probably other OSes).

I'm interested to see if I can indeed implement shell scripting through a browser, and everything I've read says it should absolutely be doable from a locally hosted instance. I keep looking at early versions of runRev on MacOS 9 - it's very limited because there's no shell, so anything that I'd normally resort to the terminal for requires some kind of XCMD/XFCN. Access to shell nullifies the need to have this mostly because there's pretty much a terminal command for everything.

Thanks for fixing the mess I made of this thread, I was editing it at 3:30 AM here and I really needed to crash.

Haha, no problem. I was up until midnight trying my SuperCard standalone test - just to make sure I'd not got the wrong end of the stick or 'misremembered' - but yes, no problem. I'll try and get something into that Mega account in about 5 hours. (currently 12:33 lunchtime here).

[OpenXTalkPaul]

I know you're concerned about sharing the source, but is this shared on that collab MEGA account?

It isn't currently, but when I get in this evening (as currently on lunch break), I'll upload what I have.

Awesome, thanks in advance!

I keep looking at early versions of RunRev on MacOS 9 - it's very limited because there's no shell, so anything that I'd normally resort to the terminal for requires some kind of XCMD/XFCN. Access to shell nullifies the need to have this mostly because there's pretty much a terminal command for everything.

It would be great if I could get macOS 9 / Carbon build of RR 2.2 (or better) running in a better build of Sheepshaver iOS OS9 emulation on iPadOS, or alternatively a version of RR 1.1 that works for Mac 68K with Mac OS 8.1 (max for 68K) to run in Basilisk II iOS build would be workable too. It would be awesome to have any kind of OXT-adjacent IDE that works well on an iPad in a touch keyboard/stylus friendly way.

As you said on macOS 9 there was no command line at all so yes as you say one needed to use XCMD/XFCN add ons for the sort of host system inspection (there were Gestalt externals) you might normally do with a command shell, if there was one (in fact I know there were HC stacks people created that behaved sort of like a command-line).

I would be surprised if no one had created a XFCN based shell() function for HC running in 'Classic' on MacOS X once that had arrived, but on Mac HyperCard very early on had 'polyglot' scripting with syntax: do tMyAppkeScript as AppleScript, so you could always use AppleScript to run OS X shell commands from HyperTalk script. AppleScript could cross-over to reach outside of the 'Classic' environment from a script executed within it. I used to use AppleScripts to control a version of QuarkXPress (6?) running natively in Mac OS X from a HyperCard stack running in the classic environment, which significantly extended the continued usefulness of HyperCard for me going into the early 2000s.

That is why allowing for the HC 'engine' capabilities / syntax to be expanded on by third party add-ins was such a revolutionary new idea (seems to be a very under-rated feature of HC). I think it was the first app to have that concept of 3rd party plug-ins in the form of XCMD/XFCN resources. I imagine that was easily implemented by Resource Manager already being part of the OS / Mac toolbox. But Resource Manager had massive security flaw in that it would auto-load any resource into RAM whenever an App OR EVEN A FILE was opened, which I think is how HyperCard stack viruses were spread IIRC.

That reminds me I should make a thread about something HC related that I recently read about...

[tperry2x]

Oh, something here just caught my eye. If we do use an electron app wrapper on MacOS, we need to bear this in mind (so just pinning it here in case I lose the reference later).

I would assume the same is true no matter what wrapper we put this inside of. I suppose the only way to find out is to try it.

[FourthWorld]

Oh, something here just caught my eye. If we do use an electron app wrapper on MacOS, we need to bear this in mind (so just pinning it here in case I lose the reference later).

I would assume the same is true no matter what wrapper we put this inside of. I suppose the only way to find out is to try it.

From that page:

Solved it myself.

The problem is neither with the existing entitlement entries nor with the package.json options, but rather a missing entitlement entry:

<key>com.apple.security.get-task-allow</key>
<true/>

The app got the permission prompts back after adding that.

[OpenXTalkPaul]

Solved it myself.

The problem is neither with the existing entitlement entries nor with the package.json options, but rather a missing entitlement entry:

<key>com.apple.security.get-task-allow</key>
<true/>

The app got the permission prompts back after adding that.

You never know when Apple will add and require a new entitlement key that can break an app, that's just the way it is now I guess.