Extension of systemVersion
Moderator: Klaus
-
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Extension of systemVersion
If the processor doesn't return the processor please file a bug report.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Extension of systemVersion
Ah, Richmond... deploying to other processors/operating systems isn't a matter of checking a system property via script - the engine itself has to be compiled to run on the processor (Intel/ARM/etc) and hook into the operating system in various sneaky ways. That's why we don't currently have a Raspberry Pi deployment at present - it's waiting for someone with the proper ken to step up and fiddle with the build files and the engine innards. We can currently deploy Android engines to ARM7 devices, but that's still not enough to get us to Piville.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: Extension of systemVersion
Certainly, My assumption was that it was returning what the installed OS was reporting, not anything from the actual hardware level, and so this was not a bug, but I'll be happy to file it.FourthWorld wrote: ↑Sat Aug 31, 2019 11:32 pmIf the processor doesn't return the processor please file a bug report.
*Edit - apparently a bug was already filed for this, and according to Panos, the processor should actually report the app's architecture? <hee hee> that is confusing, or maybe better said "counter intuitive" to say the least.
I sure didn't see that one coming heh."the processor" returns correct results, it should return the arch of the running app. Maybe the docs need to make this clearer.
In any case, I appended what I am seeing, even though processor isn't actually a bug.
*Edit 2 - I dug around back to Mc 2.2 to see if any changes in the dictionary occurred, this is what I found.
This in the Metacard 2.2 reference, which states:
"The following terms are accepted as valid function and property names, but are not implemented and return fixed values:"
This is where 'processor' is listed. Machine, though, is a slightly different bird, even in the earliest Mc IDE I can run, it states that it is indeed supposed to return the CPU type, however even back then it reports it incorrectly, or at least, reports what the installed OS says it is running on.
*Edit 3 - Also came across this interesting discussion about the processor function.
For instance....
Long read, but fascinating stuffmontegoulding on Jun 30, 2017 Contributor wrote: Actually this is the same for all platforms. the processor will return the processor the engine was built for not the processor of the machine if there is some emulation going on. So in the case of all three desktop OSs that may or may not be the actual processor arch if it returns 32 bit...

Last edited by bogs on Sun Sep 01, 2019 7:53 am, edited 3 times in total.

-
- Livecode Opensource Backer
- Posts: 10078
- Joined: Fri Feb 19, 2010 10:17 am
Re: Extension of systemVersion
Really? Gosh, I didn't know that . . .deploying to other processors/operating systems isn't a matter of checking a system property via script
Um: fiddle with the . . . innards.waiting for someone with the proper ken to step up and fiddle with the build files and the engine innards
I've got a friend who performs autopsies on road crash victims . . .

Err . . . joking apart . . .
For the sake of argument . . . I am the author of a "thing" called Devawriter Pro, which
is one hell of a sh*t-kicker when it comes to Indic language writing systems . . . and I offer
a variety of Demos for a variety of OSes and machines (thanks to LiveCode).
Now I can spare myself a lot of time and aggro if I have a small standalone for, say, Windows,
which a potential customer can run on his/her system and it can tell me what sort of Windows
they are using and whether their computer is a 32-bit or a 64-bit machine.
This is particularly useful as most "crusty professors" of Sanskrit don't know very much
about the innards of computers and their operating systems.
- -
https://www.dropbox.com/sh/z9r67i66f094 ... B5gia?dl=0
Re: Extension of systemVersion
Devin asked a similar thing on the use-list last week - suggesting doing exactly
the same thing - my general response was don't make your life more complicated
than it needs to be:
enough to justify any extra complexity[of shipping more than one binary]'. Unless
you actually notice a performance advantage or, indeed, are needing to manipulate
> 3Gb of data at a time (in memory) then its probably the case that 32-bit only will
do fine for some considerable time into the future.
the same thing - my general response was don't make your life more complicated
than it needs to be:
Really the key thing in most cases is 'does your app actually benefit from being 64-bit> No, I’m just toying with the idea of having a 32-bit launcher that
> would examine the host OS, then launch the proper executable based on
> whether it is 32 or 64 bit. Sort of like a poor man’s universal app
> like we used to create for MacOS. It’s possible I’m use way
> overthinking this.
I think you might be overthinking this...
The Windows world is different from mac because the former don't have the
idea of multi-architecture binaries.
Obviously on mac this isn't something you have to worry about - especially
since versions of macOS going back many years have supported 64-bit as have
the machines it runs on.
On Windows it is usual for the user to choose whether they want 32-bit or
64-bit versions of the apps they download and install. This is usually guided
by the webpages which offer downloads as you can usually assume that if the user
is on a 64-bit windows machine, then the browser they are running will be 64-bit
which means that you can tell from the UserAgent string what architecture their
machine has and so you can guide the user to the right choice.
In an end-user setting, you could always have a dialog which pops up when running
the 32-bit version on a 64-bit machine (by using Dar's suggestion) on first run
to suggest the user might want to download the 64-bit version - however, you then
have to ask yourself whether your app actually benefits from being 64-bit enough
to justify this extra complexity.
In an organizational setting then one would hope that the IT department would
know what to do when presented with the choice of both a 32-bit and a 64-bit
build of a Windows app... In reality this may or may not be the case
So my suggestion (in general - obviously specific circumstances always apply) is
don't worry about it. Offer two downloads explicitly named and marked - one as
32-bit one as 64-bit and then, if you can, guide the user to the right choice
online by offering the appropriate build (which Chrome does, for example, adding
further weight to being able to rely on the bitness of the browser accessing your
download site).
enough to justify any extra complexity[of shipping more than one binary]'. Unless
you actually notice a performance advantage or, indeed, are needing to manipulate
> 3Gb of data at a time (in memory) then its probably the case that 32-bit only will
do fine for some considerable time into the future.
Re: Extension of systemVersion
Hi,
I have in use:
Have fun!
I think you'll get the best information switching for "the platform", and then using a suitable cmd line tool.richmond62 wrote: ↑Sun Sep 01, 2019 7:01 amNow I can spare myself a lot of time and aggro if I have a small standalone for, say, Windows, which a potential customer can run on his/her system and it can tell me what sort of Windows
they are using and whether their computer is a 32-bit or a 64-bit machine.
This is particularly useful as most "crusty professors" of Sanskrit don't know very much about the innards of computers and their operating systems.
I have in use:
- Windows:
Code: Select all
put shell("systeminfo")
- Android:
Code: Select all
put "BOARD,BOOTLOADER,BRAND,CPU_ABI,CPU_ABI2,DEVICE,DISPLAY," & \ "FINGERPRINT,HARDWARE,HOST,ID,MANUFACTURER,MODEL,PRODUCT," & \ "RADIO,SERIAL,TAGS,TIME,TYPE,USER" into myData repeat for each item L in myData put "mobileBuildInfo(" & (quote & L & quote) & ")" into myTemp put L & ": " & value(myTemp) & CR after myVar end repeat put myVar
Have fun!
All code published by me here was created with Community Editions of LC (thus is GPLv3).
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
-
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Extension of systemVersion
If your app is running, it's compatible with the host OS. Just let your users enjoy that, and they'll never need to become CPU-savvy. If it won't run on their machine no additional functions well help, since they'll never be able to be called.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- Livecode Opensource Backer
- Posts: 10078
- Joined: Fri Feb 19, 2010 10:17 am
Re: Extension of systemVersion
Well, Yes . . .If your app is running
But, let's suppose I release a DEMO version of my thing in various flavours,
and the Windows 32-bit version runs on Windows 64-bit, but "Dr Sanskrit",
were s/he to order a fully-licensed and fully-enabled version from me might
still be better served if s/he is sent a licensed version for Windows 64-bit.

Re: Extension of systemVersion
Still not clear on this...
I can see why you'd want a 32-bit demo version running on 64-bit Windows.
But then "Dr Sanskrit" would select either the 32-bit or 64-bit version to order from you, no?
Are you suggesting that the demo version tell the user which version to order?
Or maybe the order form is in the demo version? And it would select for the user?
I can see why you'd want a 32-bit demo version running on 64-bit Windows.
But then "Dr Sanskrit" would select either the 32-bit or 64-bit version to order from you, no?
Are you suggesting that the demo version tell the user which version to order?
Or maybe the order form is in the demo version? And it would select for the user?
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: Extension of systemVersion
I think the most likely reason you'd want 'the processor' to tell you the actual processor, or 'the machine' to give you an in-depth description of the hardware your running on, would be system requirement testing. The rest of the functions cover the rest of the requirements in that scenario pretty well.
But lets take a look at it from a backwards view if you will.
You have a function called the processor, which the dictionary blatantly states should be telling you what the CPU is. Instead, apparently, it tells you what your application is compiled for. You compiled the application, why would you need to know what you compiled it for? You already have this information before it leaves your machine.
Now, I don't know how resource intensive Richmond's Deva Writer is, but instead of that, let us say you were making a bench marking utility. I think the very least you'd have to know is the processor (and as much about it as you could find out, make/cores/mhz/86-64/etc... directly from the hardware and not from the OS), the amount of ram, what kind of hard drives, chipset, graphics card, monitor, etc etc etc. just for the reporting part of the tool. At least, I haven't seen very many good tools of that kind that can't tell you what kind of system your running.
Another example, your writing a game. You know below certain specs, this game will run like doo-doo. In the demo and release version of your game, you could include the test by having Lc tell you the hardware the game will be running on. You then can tell the end user "Hey blockhead, your system is going to run this game like DOO-DOO you cheap skate! Put another gig of ram in you miser!! And how about a video card newer than the '80s !??!"
Either of the two functions discussed here would be ideal for that kind of information, but despite the descriptions of them, neither actually does anything close to this. For that matter, you could drop 'the processor' altogether if you felt like it, and just bulk up 'the machine' so the programmer could pick and choose what he/she wants to, but since it is existing, why not make it do what it says it should be doing?
But lets take a look at it from a backwards view if you will.
You have a function called the processor, which the dictionary blatantly states should be telling you what the CPU is. Instead, apparently, it tells you what your application is compiled for. You compiled the application, why would you need to know what you compiled it for? You already have this information before it leaves your machine.
Now, I don't know how resource intensive Richmond's Deva Writer is, but instead of that, let us say you were making a bench marking utility. I think the very least you'd have to know is the processor (and as much about it as you could find out, make/cores/mhz/86-64/etc... directly from the hardware and not from the OS), the amount of ram, what kind of hard drives, chipset, graphics card, monitor, etc etc etc. just for the reporting part of the tool. At least, I haven't seen very many good tools of that kind that can't tell you what kind of system your running.
Another example, your writing a game. You know below certain specs, this game will run like doo-doo. In the demo and release version of your game, you could include the test by having Lc tell you the hardware the game will be running on. You then can tell the end user "Hey blockhead, your system is going to run this game like DOO-DOO you cheap skate! Put another gig of ram in you miser!! And how about a video card newer than the '80s !??!"

Either of the two functions discussed here would be ideal for that kind of information, but despite the descriptions of them, neither actually does anything close to this. For that matter, you could drop 'the processor' altogether if you felt like it, and just bulk up 'the machine' so the programmer could pick and choose what he/she wants to, but since it is existing, why not make it do what it says it should be doing?

Re: Extension of systemVersion
I see two things going on in this thread:
1. I need a way to determine which build to distribute to a given customer.
2. I want in-depth information about my client's machine for debugging, etc.
#1 is pretty easy to do from a scripting level, so I don't see the need to bother the engine files with it.
#2 is also doable from a script, although it takes a bit more environment-sensitive scripting to take care of, and then I don't think you can generate any useful cross-platform results.
I don't know if anyone is using the systemVersion currently... it doesn't seem very useful. On my system I get just the kernel:
Linux 4.15.0-58-generic
1. I need a way to determine which build to distribute to a given customer.
2. I want in-depth information about my client's machine for debugging, etc.
#1 is pretty easy to do from a scripting level, so I don't see the need to bother the engine files with it.
#2 is also doable from a script, although it takes a bit more environment-sensitive scripting to take care of, and then I don't think you can generate any useful cross-platform results.
I don't know if anyone is using the systemVersion currently... it doesn't seem very useful. On my system I get just the kernel:
Linux 4.15.0-58-generic
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: Extension of systemVersion
...which is more than 'the platform' gives you by a yard

Code: Select all
put "The systemVersion is" && the systemVersion & cr \
& "The platform is " & the platform
Of those two, the platform gives you less than what I'd be looking for in a series of if/then or case statements determining what to do on a given system. On linux, the kernel version could mean a *lot*.The systemVersion is Linux 4.19.0-5-amd64
The platform is Linux

Re: Extension of systemVersion
Possibly, but I'd be more concerned about the distro and desktop manager. Ubuntu? Debian? KDE? Gnome? Cinnamon? Mate? xfce?
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: Extension of systemVersion
Well, I'm sure you already know how to 'cat' that stuff, and it might matter if Lc was designed to run on every distro, but since that isn't the case, you really only have to know if it is running on Ubuntu, Mint, or straight Debian maybe.
Unless the desktop is Gnome, I'm not sure I'd be counting on a lot for the decorations being correct. I can't tell if the menu issue was fixed or not. I'll have to load an ubuntu machine at some point to find out, since I never checked beyond the thread that came up in.
*Edit - My bad, there is also Redhat gnome and I *think* SUSE gnome
Unless the desktop is Gnome, I'm not sure I'd be counting on a lot for the decorations being correct. I can't tell if the menu issue was fixed or not. I'll have to load an ubuntu machine at some point to find out, since I never checked beyond the thread that came up in.
*Edit - My bad, there is also Redhat gnome and I *think* SUSE gnome


Re: Extension of systemVersion
My point, though, was that returning the kernel version by itself doesn't really help with any of that.
Except possibly the data point of "the client hasn't updated the kernel".
Except possibly the data point of "the client hasn't updated the kernel".
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev