FourthWorld wrote: ↑Mon Jan 29, 2024 4:42 pm
Also, is the value returned by older versions of LC even a meaningful number anymore? That is, is it the actual process ID?
Both macOS and Windows use address randomization in conjunction with other methods to make it hard for unauthorized software to know how to get inside the runtime innards of other apps. I don't know the history of processID specifically, but it wouldn't surprise me if older LC versions are returning a value from an old API that no longer reflects the actual process ID of the target process.
In the work you're doing that relies on processID, are you able to accomplish what you need on current OS versions using the value returned from older LC versions?
Yes, that's the point, the docs say it's not meaningful but it is, it returns the actual PID as seen in 'top' and that you can use 'kill' from a shell to send the kill signal to the process.
There is (was, I removed it from the OXT Dictionary) in the docs an incorrect blurb about on 'macOS AND OS X' systems
From their dictionary on their website, just now:
On Mac OS and OS X systems, there is no process ID. Instead, the openProcessIDs function returns a list of integers. The first application started up (with the open process or launch command) during a session is assigned the number 1, the second is assigned the number 2, and so on. After an application quits, its process number is not re-used, so you can use the openProcessIDs function to determine how many times LiveCode has started up an application during the current session.
This may have been true at some point in the past (if so, my guess is it was early days of OS X), but it certainly is NOT true in OXT now. The integers you'll from 'put the openProcessIDs' are NOT going to be 1,2,3,... but numbers more like 3525, 3526, 3527, etc. and may not be in a perfectly sequential order if other processes were opened and then completed their run or were killed by the engine or system in the interim.
If a process is no longer running after using the kill <process> command or something like 'shell("kill " & tPID)' then the process is still in 'the OpenProcesses' list, BUT the corresponding number in the list returned by 'the OpenProcessIDs' will be now be 0 (zero) for that line (the process is not running). I'll have to check tonight to see what happens with that number if I then re-run that process (I'm guessing it would get a new PID). The other part that I italicized can't be accurate either, since the numbers may not be perfectly sequential and definitely do not start at one.
The 'put the processID' definitely returns the PID number for the engine itself, the same number you would see with 'top' command in the terminal. It seems 'the openProcessIDs' does as well, which means it is much more useful information, since the order of the list is already in a sequential order that reflects the order in which the (sub)processes were launched (1,2,3 etc.) it would just be redundant information. I would note that it should only be these Engine launched processes, which are child-processes, that can be manipulated. Since they are spawned from our Engine's process they should inherit the same privileges as the parent process (OXT Engine in our case), and also likely means they need to have ABI (Application Binary Interface) compatibility, which means 'no mixing architectures' like no using an ARM binary child process from a parent process that's an x86 Intel binary (via Rossetta2 I'm not 100% certain about).
The docs mention that support for 'read from process' on OS X was added in RunRev 2.0, that's decades ago so I'm guessing the returned values have changed at some point and the docs just never got updated.
, could add some a little at a time, a few each time I rebuild the dictionary... or maybe just stick to straight CompSci definitions as the dictionary is already kind of large? 