Detect Operating System

[FourthWorld]

Bogs, did I miss something? Doesn't the processor function function allow one to determine whether a professor is 32 or 64 bit?

[richmond62]

Bogs, did I miss something? Doesn't the processor function function allow one to determine whether a professor is 32 or 64 bit?

My wife's a professor: and she fizzes at 128 bits.

[tperry2x]

To detect operating system, do you want

put the platform

should return

"Win32" on any version of Windows
"Linux" on all Linux distributions
"MacOS" on any version of Mac OS X
"iphone" on iPhones, iPads and other iOS devices
"android" on smartphones, tablets and other Android devices
"HTML5" when running in a web browser

[bogs]

Well, rather than go through that entire (slightly older) thread here all over again, I'll just paste the appropriate quotes from it.

I'd like to say I appreciate everyone's answers, but, there are some things wrong in eden

The original request was for:

1. Your system is a 32 or 64 bit system.

The processor will tell you that. If you're able to turn up a case where it reports that incorrectly please submit a bug report.

This is actually not the case, 'the processor' (and 'the machine') echo merely what the installed OS is, really, not what the processor is. For instance, this is on a 3 core 64 bit AMD processor, with 32 bit Linux Mint 19 installed -

The 'system version' (or systemVersion, either way) is actually complete, it returns the OS and the version number.
The 'platform' merely tells you the OS.

the systemversion - Linux 4.4.0-159-generic
the platform - Linux

The 'environment' is of course as stated, but inconsequential in this discussion (which I think is focusing on system information, but could be wrong).

To which you suggested I file a BR here. I pointed out the inconsistencies in the documentation, we discussed this back and forth a while, until the final authority showed up - here, which I answered, and ultimately which he answered back that it isn't going to change, no way, no how, no matter what (I'm paraphrasing, what he actually said was more along the lines of "If you know how to get what your looking for, we don't need to put it actually into the language/engine").

<sic>
At the end of the day if you app needs this stuff in this much detail, then it means you know what you are looking for and can easily figure out how to find it, and then manipulate it using shell() commands and LC's excellent text processing abilities, surely?

After that, we did approximately 3.5 more pages of dancing around the maypole, and a good time was had by all, despite disappointing results.

Does that help?

[FourthWorld]

When I query processor() on 64-bit machines, I get "x86_64".

[bogs]

You are having a go at me, right?

[tperry2x]

If you want to know if it's a 32bit or 64bit machine, I know how to do it on the mac.
You could use:

paste this into a field called "script" on the card

set xvar to do shell script "getconf LONG_BIT"
set yvar to do shell script "sysctl -n machdep.cpu.brand_string"
display dialog "Running a " & xvar & " bit operating system.
Processor: " & yvar buttons "Close"

then on a button,

on mouseup
put cd fld "script" into tscript
do tscript as Applescript
end mouseup


Don't know how you'd do it on other platforms though.

[bogs]

Don't know how you'd do it on other platforms though.

And there in lies the problem discussed in the topics Richard and I have posted links to, as well as other places. Some of us, myself included, would like to be able to easily access knowing what the 'real' hardware we are running on really is.

Others think it is 'good enough' to take the OS'es word as gospel, no matter what it tells you.

In the thread I linked to (6 pages of OH MY GO...odness....), as well as the one Richard linked to, it was well pointed out that some may know how to get that on their own through the cli, or may be able to find that out on their own and be able to implement it.

I'm all for learning, however we also know the shell doesn't always work out for any number of reasons (and those reasons aren't Lc's fault, such as incorrectly configured paths, etc). Knowing that is one reason aside from ease on me that I think it should be part of the product, much like I think the product really needs it's own audio setup.

However, that is neither here nor there, and would not benefit me in any way, shape, or form, even if it were put into the product tomorrow. But that is another story, I'll leave this one up to you all to sort out (again)

[tperry2x]

Something like this perhaps then?
Which works on Mac, Linux and Windows.


https://www.tsites.co.uk/downloads/32bi ... versal.zip

[bogs]

That was (close) to the script I wound up with just to find the processor, yes, although I was not as fussy say, as you were on 'nix. I went more like this here:

Code: Select all

   put shell("dpkg --print-architecture")
   put shell("dpkg --print-foreign-architectures")

in the 'nix section.

For the rest of the hardware, though, I usually route the calls through lscpu and lspci, then sort what I need from there as I mentioned in the previously mentioned threads.

[FourthWorld]

Under what circumstances does the processor function not return accurate information about the processor?

[tperry2x]

I guess if suddenly they release a new type of processor, an unidentified model. The shell would know what it is because the operating system needs a working shell, so better to query the shell for the answer.

[bogs]

Under what circumstances does the processor function not return accurate information about the processor?

Ok, I'll assume you really aren't just having a go at me, asking all the same things in the thread I quoted from. I'll make the further assumption that the picture in my quote up there and the text surrounding it somehow doesn't say this too you -

The original request was for:

1. Your system is a 32 or 64 bit system.

The processor will tell you that. If you're able to turn up a case where it reports that incorrectly please submit a bug report.

This is actually not the case, 'the processor' (and 'the machine') echo merely what the installed OS is, really, not what the processor is. For instance, this is on a 3 core 64 bit AMD processor, with 32 bit Linux Mint 19 installed -

The 'system version' (or systemVersion, either way) is actually complete, it returns the OS and the version number.
The 'platform' merely tells you the OS.

the systemversion - Linux 4.4.0-159-generic
the platform - Linux

The 'environment' is of course as stated, but inconsequential in this discussion (which I think is focusing on system information, but could be wrong).

When you use 'the processor', you are not getting the slightest hint of anything about the processor in terms of what it is. Instead, you get whatever processor back that the Operating System was installed for.

In the case of the quote above, I obviously have a 64 bit processor, yet, using 'the processor' tells me nothing of the sort. So, the processor really should have been called "the what-Bit-Os-Am-I_Running" because it has nothing whatsoever to do with the actual processor.

Now that I have repeated myself and hopefully clarified my somehow ambiguous picture and statement, you can go ahead and tell me that none of this information means jack squat, much as went on in the other threads.

Frankly, I am so done with this topic, I hope everyone else understands that I absolutely don't have any more interest in replying in it.

@tperry2x -
Yes, much as I said earlier, the shell is the only place your going to get accurate (and in depth) information, which would be fine if the shell command worked in all situations. The fact is that it works about 95+ % of the time, again, not because of an issue with Lc (far as I can tell), but because of the way that some systems setup (OSX / 'nix variants, anyone from the windows world want to chime in?), path related issues, or programmer or user error.

Those types of things will not make your program in Lc not work, but all shell commands your relying on will fail, usually silently/transparently to the end user. You, as a good programmer though, will (hopefully) have error checking routines in place that will catch such nonsense. Have fun with it.

As an aside, noticed that most of your demos are in Lc 7.x It was refreshing to not have to go past that vers. to look at something heh.

[richmond62]

What comes out of this "jolly love-in" is that LiveCode can pick up information from other software (i.e.the operating system) but
NOT from the hardware.

Mind you, if a 32-bit system runs on a machine, who gives a flying "ffffffffffffff" about the processor as,
presumably, 32-bit LiveCode standalones will run on that machine.

[FourthWorld]

I guess if suddenly they release a new type of processor, an unidentified model. The shell would know what it is because the operating system needs a working shell, so better to query the shell for the answer.

I haven't read this part of LC's source, but the value returned by processor() may well be derived from an OS call, in which case it would reflect information as current as the OS vendor can make it.

But even if it's a hard-coded string, given the vast resources and ramp-up time needed for a chip maker to deploy a new CPU architecture, I'll bet there would be sufficient time for LC to add a string. "Suddenly" is not a word often used in the rollout of new microchip architectures.

Besides, even if there was a lag time it can't affect us, because not only would they need to add the string but they'd also need to recompile LC to be able to run at all on a new architecture.

I think we're pretty safe on this one.