What is the most reliable way to determine the OS of a visitor to a web site? All other things being equal I prefer an easier to integrate solution. I'm not attempting to gather analytics and I understand there is no completely reliable method. The purpose of this is to subtlely tailor the user experience in ways that do not affect the functionality of the site -- for instance, making a guess at which os version of a cross platform app the user would like to download (I won't hide the other selections, the one matching the user's OS will just become more prominent).
On the client side, you can use Javascript to try to detect it:
// This script sets OSName variable as follows:
// "Windows" for all versions of Windows
// "MacOS" for all versions of Macintosh OS
// "Linux" for all versions of Linux
// "UNIX" for all other UNIX flavors
// "Unknown OS" indicates failure to detect the OS
var OSName="Unknown OS";
if (navigator.appVersion.indexOf("Win")!=-1) OSName="Windows";
if (navigator.appVersion.indexOf("Mac")!=-1) OSName="MacOS";
if (navigator.appVersion.indexOf("X11")!=-1) OSName="UNIX";
if (navigator.appVersion.indexOf("Linux")!=-1) OSName="Linux";
document.write('Your OS: '+OSName);
Sourced from here. Javascript methods are inherently unreliable however. Server side, you can examine some of the HTTP headers in the language of your choice, however, these can also be crafted and are unreliable as well.
In short, there's no 100% reliable method.
There is no reliable way to do it, and it's not only none of your business, it's also something your web site should pay no attention to.
If this was something your site was meant to know, then there would be a navigator.os property. Note there is not.
Here are examples of Perl code that does OS detection server-side from useragent strings:
HTTP::BrowserDetect or HTML::ParseBrowser for desktop operating systems
Mobile::UserAgent for legacy mobile platforms
What is the most reliable way to determine the OS of a visitor to a web site? Ask them on a survey... all else is a crap shoot. Using the UserAgent string you may be able to divine the OS, but as numerous articles will attest - there is no really reliable way to tell.
Related
I've got a big ask here, but I am hoping someone might be able to help me. If there's another site you think this should be posted on, please let me know.
I'm the developer of the free app Amphetamine for macOS and I'm hoping to add a new feature to the app - keeping a Mac awake while in closed-display (clamshell) mode while not having a keyboard/mouse/power adapter/display connected to the Mac. I get requests to add this feature on an almost daily basis.
I've been working on a solution (and it's mostly ready) which uses a non-App Store helper app that must be download and installed separately. I could still go with that solution, but I want to explore one more option before pushing the separate app solution out to the world.
An Amphetamine user tipped me off that another app, AntiSleep can keep a Mac awake while in closed-display mode, while not meeting Apple's requirements. I've tested this claim, and it's true. After doing a bit of digging into how AntiSleep might be accomplishing this, I've come up with 2 possible theories so far (though there may be more to it):
In addition to the standard power assertion types, it looks like AntiSleep is using (a) private framework(s) to apply non-standard power assertions. The following non-standard power assertion types are active when AntiSleep is keeping a Mac awake: DenySystemSleep, UserIsActive, RequiresDisplayAudio, & InternalPreventDisplaySleep. I haven't been able to find much information on these power assertion types beyond what appears in IOPMLibPrivate.h. I'm not familiar at all with using private frameworks, but I assume I could theoretically add the IOPMLibPrivate header file to a project and then create these power assertion types. I understand that would likely result in an App Store review rejection for Amphetamine, of course. What about non-App Store apps? Would Apple notarize an app using this? Beyond that, could someone help me confirm that the only way to apply these non-standard power assertions is to use a private framework?
I suspect that AntiSleep may also be creating a virtual keyboard and mouse. Certainly, the idea of creating a virtual keyboard and mouse to get around Apple's requirement of having a keyboard and mouse connected to the Mac when using closed-display mode is an intriguing idea. After doing some searching, I found foohid. However, I ran into all kinds of errors trying to add and use the foohid files in a test project. Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app? I'm not asking for code help with that (yet). I'd just like some help determining whether it might be possible to do.
Thank you in advance for taking a look.
Would Apple notarize an app using this?
I haven't seen any issues with notarising code that uses private APIs. Currently, Apple only seems to use notarisation for scanning for inclusion of known malware.
Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app?
Taking a quick glance at the code of that project, it's clear it implements a kernel extension (kext). Those are not allowed on the App Store.
However, since macOS 10.15 Catalina, there's a new way to write HID drivers, using DriverKit. The idea is that the APIs are very similar to the kernel APIs, although I suspect it'll be a rewrite of the kext as a DriverKit driver, rather than a simple port.
DriverKit drivers are permitted to be included in App Store apps.
I don't know if a DriverKit based HID driver will solve your specific power management issue.
If you go with a DriverKit solution, this will only work on 10.15+.
I suspect that AntiSleep may also be creating a virtual keyboard and mouse.
I haven't looked at AntiSleep, but I do know that in addition to writing an outright HID driver, it's possible to generate HID events using user space APIs such as IOHIDPostEvent(). I don't know if those are allowed on the App Store, but as far as I'm aware, IOKitLib is generally fine.
It's possible you might be able to implement your virtual input device using those.
Since one release binary will run on pc, xbox and phones, I need a way to fetch the device type on runtime.
It is doable by checking with the ApiInformation for present types, methods etc., but I believe there should be a more reliable way.
Currently (with the preview tools released 23-Mar-2015) there isn't an easy way to do this, other than (as you mention) using the ApiInformation methods to detect implementations of things that only exist on the specific platform you're after.
It would be nice if there were some helpers to do this and if none are in the final tooling I'm sure some will be created by helpful people in the community.
However, there is a really good reason not to have this in that it encourages broad assumptions about the device.
If it was possible to say "Am I running on a phone?" then if you got the response 'Yes' then it would be easy to make assumptions about what was possible with that device but not all phones have the same capabilities.
It looks like there will be a "mobile" version of Windows 10 for both phones and small tablets. If you were able to say "am I the 'mobile' version?" then again that wouldn't potentially answer all your questions and you'd have to still check individual API availabilities as the capabilities of a cheap tablet and a high end phone could be vastly different. (The inclusion of physical buttons on the device and the ability to make phone calls are two obvious examples.)
Extending this further there are plenty of scenarios where you'd treat different platforms the same as the functionality exists on all of them. In this scenario you're code would be better of saying "Is such and such API available?", rather than saying "Am I running on desktop, Xbox or SurfaceHub?".
The IOT platform will likely further complicate this due to the range of functionality and capabilities different IOT devices will have available.
There are very few scenarios where you want to know the platform you're running on and not whether a specific API is available. Hopefully, by only exposing API availability Microsoft are encouraging developers to think about checking for what they actually need, rather than relying on broad, potentially incomplete, classifications of devices.
Just as with web development where you don't know what platform or browser you are running on, you shouldn't detect the platform and make assumptions about what capabilities that device will therefore have, you should detect if the specific capability you require is supported/enabled on the device before using it or exposing associated UI in your app.
It seems there is a new API to detect Device Family:
Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily
You can find more information here: https://msdn.microsoft.com/en-us/library/windows/apps/dn705767.aspx
Updated:
https://msdn.microsoft.com/en-us/library/windows/apps/windows.system.profile.analyticsversioninfo.aspx
[Edit July 3 to replace //build-era information with current information]
Although you can try and infer the device you're on by using the ApiInformation APIs to detect APIs, this is a very bad solution since APIs can be added to devices over time. Please don't do that; your future self (or your replacement ;-) ) will thank you.
If you really do need to programmatically detect the device family that you're running on (and in most cases you don't) then you can use AnalyticsInfo.VersionInfo.DeviceFamliy. This returns a string for which there is no published standard set of values, because device families could be introduced or retired at any time.
If you want to provide different resources per device-family (strings, images, XAML files, HTML pages, etc.) then you don't need to detect the device-family in code; instead you can use an MRT qualifier DeviceFamily (such as Logo.DeviceFamily-Mobile.png). Just make sure you always have a fallback resource (image, string, etc) for use when the app is running on a device family you've never heard of before. And don't fall into the trap of assuming things like "Desktop requires higher-res assets than Mobile" because that is often not true.
Additionally to support the scenario Alan describes in his comment you can check for a Contract rather than a specific type as this indicates a block of related functionality. There is one such contract for the Windows Phone specific APIs - I described in here http://inthehand.com/2015/03/26/determine-if-running-on-windows-phone-from-a-uap-application/
Since this contract provides compatibility APIs for current Windows Phone apps we can assume at this point that it won't be implemented in small tablets as they won't have this. Obviously since the OS or APIs are not final this is not set in stone yet. This is a useful thing to know for Windows Phone especially if during the transition you want to cross promote legacy WP apps only on WP devices. For custom IoT devices I would check availability at the API level.
You can specify device family exclusive resources and views using specially named folders: (http://www.sharpgis.net/post/2015/04/01/Creating-DeviceFamily-specific-layouts-in-a-Universal-App).
You could, for the "advertising only same family apps" scenario described above, place a JSON or XML file in that device family's folder and fetch it at runtime using the storage API's.
I use this for phone (mobile):
if (Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily == "Windows.Mobile")
{
// code for phone
}
else
{
// other code
}
extample is here
This is just repeating one of the previous answers which suggests using Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily but I thought I'd include the complete code for a check:
// ----------------------------------------------------------------------
// IsRunningOnXbox
// Determines whether or not the game is running on an xbox console
bool IsRunningOnXbox()
{
// Skip if already checked
static bool bChecked = false;
static bool bRunningOnXbox = false;
if (bChecked)
return bRunningOnXbox;
// Retrieve the platform device family
Platform::String^ strVersionInfoDeviceFamily = Windows::System::Profile::AnalyticsInfo::VersionInfo->DeviceFamily;
if (strVersionInfoDeviceFamily != nullptr)
{
// Check to see if the device belongs to the xbox family
std::wstring strDeviceFamily = strVersionInfoDeviceFamily->Data();
std::transform(strDeviceFamily.begin(), strDeviceFamily.end(), strDeviceFamily.begin(), ::tolower);
if (strDeviceFamily.find(L"xbox") != std::wstring::npos)
bRunningOnXbox = true;
}
// Check complete
bChecked = true;
// Return whether or not the host platform is xbox
return bRunningOnXbox;
}
I do agree with Chuck's comment that this is probably not what AnalyticsInfo is intended for... but at the same time, we're talking about the xbox - a device with a single manufacturer who is also responsible for the OS. So in my mind at least, this seems pretty safe. Plus, if you wrap it like this, it's incredibly easy to swap in a different check should something better come along.
I have a desktop app based on HTML/JS that needs WebKit to function at a reasonable speed. Normally, I would live with IE behaving badly, but its JS engine is just too slow.
I would normally go to Appcelerator for this, but it seems they have discontinued their desktop SDK and left it for the "community"...
This needs to function on Windows PCs, or I would just use Fluid (http://fluidapp.com)...
Is there a simple Webkit wrapper that I can use, or should I build one really quick in something like Qt. I haven't used Qt in a while, so I'd have to look at it again and make sure WebKit is implemented in it...
While it is somewhat node.js-oriented, AppJS may offer what you're looking for. If it doesn't already support other scripting languages, it might at least provide a good example to start from.
Update: in the time that's passed since my original answer, it seems node-webkit fills a similar role but has gathered and maintained more momentum than AppJS. It's a little more focused, in that it doesn't attempt to provide much additional "framework" on top of simply exposing the node.js API to the window's JS context.
There's also https://github.com/atom/atom-shell, which I just learned of and may be similar.
One other thing to note is that (presumably with either, but at least with node-webkit), you MUST be cautious of any XSS-like vulnerability in your app that an attacker could exploit to gain complete access to the user's native machine. So if you are simply needing to package an offline web app in a downloadable desktop distribution, you may wish to research more PhoneGap-like solutions (e.g. Mac OS X as PhoneGap platform) or a plain web view wrapper (like mentioned in the OP) that do not expose an entire OS-level native API — as node.js does — into the JavaScript environment.
I wrote an application in a JS-based framework called Titanium. This framework doesn't have some functions, so I'm bundling autohotkeys, and using STDIN/STDOUT to connect the two. Autohotkeys has a cool function DllCall which allows to interconect with the operating system and should help me close the gap between the JS-based framework and the missing functionality.
To give you an example, Titanium allows me to bind to a specific port. But if I bind to 0 and let the OS pick a free port (as it should), it will work, but there's no way to tell which port it actually bound to.
Now since I come from web applications, DLLs are new to me; so I have a few questions:
Is there like a big doc with all the DLLs and all their methods?
How do I know if some methods are dependent on some services? I mean I've heard some rely on RPCs, COM, COM+, WMIs, etc. which a user can turn off and if it does, these methods won't work. Is there also a place where I can get more info on this?
Are there any off-the-shelf DLLs, with their methods, which I can trust that they will work 100% from XP up to 7?
Are there any access permissions I should know about? Are they documented.
If you also come from web programming, is there anything else I should be aware about?
Thank you very much.
You can find a (mostly) complete documentation of all Windows API functions (which reside in DLLs) either online on MSDN or offline using the documentation from the Windows SDK.
For example look at the documentation for SHGetSpecialFolderPath. There you can find various information, like the DLL (shell32.dll), any prerequisites (min. IE 4) and the platform availablity. (min. Windows 2000) Also security considerations are documented.
All API functions are documented more or less in this manner. A good starting point is the Windows Developer Reference. From there you can browse through the many API functions.
Basically the answer to every question is that you should search MSDN for the functions or APIs you are interested in and read the documentation there:
http://msdn.microsoft.com/en-us/library/ms123401.aspx
They document which operating systems the functions are available in so it should be easy to write something that works in Windows XP and up.
In the bad old days of interactive console applications, Don Libes created a tool called Expect, which enabled you to write Tcl scripts that interacted with these applications, much as a user would. Expect had two tremendous benefits:
It was possible to script interactions that otherwise would have had to be repeated by hand, tediously. A classic example was dialup Internet access hell (from the days before PPP).
It was possible to write scripts to test one's own interactive applications, programmatically, as part of a regression suite.
Today most interactive applications are on the web, not on the console. Hence my question: is there any tool that provides the ability to interact with web pages and web forms programmatically, much as Expect provides the ability to interact with console applications programmatically?
(The closest thing I am aware of is Chickenfoot.)
You might be looking for Selenium
I've used Selenium RC in conjunction with Python to drive web page interactions programmatically. This has allowed me to write pretty extensive user tests in which forms and inputs are driven and their results are measured.
Check out the Selenium IDE on Firefox (as mentioned above). It allows you to record tests in the browser and play them back, either using the IDE itself, or the Remote Control app.
Perl Mechanize works pretty well for this exact issue.
HTTPS and some authentication issues are tricky at times. I will be posting couple questions about those in the future.
I did a ton of Expect work in a former life and always thought Don Libes' Expect book was one of the best-written and most enlightening technical books I'd ever seen.
Hands down I would say that Perl's WWW::Mechanize library is what you want. I note above that you were having trouble finding documentation. There is good documentation for it! Look up the module's distribution on search.cpan.org and see what all is packaged with it. There's a FAQ, Cookbook with examples, etc. Plus I've always been able to get help on the web. If you can't get it here, try at use.perl.org or perlmonks.org. WWW::Mechanize's author, Andy Lester, is present on Stack Overflow. (He's also an all around friendly and helpful guy.)
I believe WWW::Mechanize also has a program that is analogous to Expect's autoexpect program: you set up a proxy process running this program as a server, point your browser to it as a proxy, perform the actions you want to automate, and then the proxy program gives you a WWW::Mechanize program for you to use as a base for your project. (If it works like autoexpect, you will certainly want to make modifications from there.)
As mentioned above, WWW::Mechanize is a browser (to be more exact, it is a web client or http client) that happens to be programmable. The last time I looked, there was even work in progress to make it support JavaScript.
In addition to Selenium, if you're doing the Ruby/Rails thing, there's Webrat.