This is a fairly common question, but I haven't seen an answer for Windows Store Apps, which generally don't have access to the full Win32 API. I'm currently building ARM and x86 versions. I don't care if the processor is 64-bit or not, or if the process is WoW64, or whatever (unless that answers the underlying question). Specifically, I want to know how many of my users would be able to run an x64 build.
So, my question: From an x86 XAML/C++ Windows Store App, how can I tell if the user is running the 64-bit version of the OS?
If that's not possible, is there a way to tell if the processor is 64-bit?
Related
I'm currently developing a Python application and I would like to know if there are any ways to pack MongoDB and MySQL (or Postgresql) into the application. By packing I mean taking those application binaries and distribute them with the application files.
For example, Metasploit PRO has some applications like nginx, postgresql, java, ruby, etc... under /opt/metasploit (they come with the application setup), and I would like to know if that could be done with any Linux application. And if so, how could I "choose" what binaries are needed? Would they work for any Debian distro? Can any application follow that procedure? Could it be done with MySQL and MongoDB?
P.D: I would like to do this to distribute one unique application instead of having to "obligate" the user to setup the databases independently, and for pure curiosity.
Thank you very much in advance!
MongoDB already distributes its binaries as standalone binaries in the sense that everything needed for the database (or shell tools) to run is included in the respective binary (mongo/mongos/mongod).
However, these binaries are OS (Linux distribution)-specific. Meaning, for example, they dynamically link against libssl and libcurl and you need to have the right versions of those libraries on the host system. So, for example, a MongoDB binary for Ubuntu 14.04 is likely to not work on Ubuntu 16.04.
As far as I know MongoDB does not support building for "generic linux". Only specific OSes like Ubuntu 16.04 are supported.
With that said, you could possibly build a "portable" MongoDB yourself if you accept some limitations, since its source code is available:
You need to figure out how to build MongoDB on some linux distribution that gives you the baseline glibc that would be compatible with all of your targets.
You may have to forego functionality like TLS connections, or figure out how to link against openssl statically (probably non-trivial).
This would be easier with older MongoDB versions (4.0, 3.6) since they have fewer system dependencies.
I think you can pack the required services and your application as Docker image or Virtual Machine box.
As my experience, I used to package the MongoDB and other Linux CLI tools with my NodeJS web application into a VM box using Vagrant. Or you can use Docker if you prefer container-based application.
If you use Vagrant, the provisioning feature may help you to setup the database before running the application. Check https://www.vagrantup.com/docs/provisioning
I'm building a node-webkit app that needs to run on all 3 main desktop environments (windows, mac and linux) I need my app to connect to a plugged in USB device and I'm having a bit of trouble working out exactly how to go about this.
Is there an npm that would work across all OS's? Could I get one built in C++ that would work? Is there anything built in to node-webkit for interacting with devices (Devices API?)
Thanks in advance.
You're almost certain to need a C/C++ module to make this happen, which means a build process is required. The good news is that you can just do the build on your machine and distribute the resulting binaries (x86 and x64) for Windows and OS X. Linux might be a little trickier, but on the other hand it's more likely to have a working build environment.
There are a few approaches, in order of ease:
If your GPS device can present itself as a simple serial device (a COM port on Windows, or /dev/tty-usbserial on *nix), then you can just use serialport to connect to the device and receive raw data. There's a nmea module that can handle parsing the data. serialport works out of the box on all 3 platforms.
If the drivers don't have an official option to present the device as a serial device, you may be able to find an unsupported way to make it happen with some searching.
If the GPS device's drivers don't expose the device as a serial device, you'll need to write a C++ module that interfaces with the driver. You'll need to write code for all three platforms; the device manufacturer should provide documentation/an SDK. (See here for advice about getting started with native modules on Windows.)
Last resort: you may be able to use the usb module to communicate directly with the device. This will probably involve reverse engineering the protocol that the device uses to communicate with the computer.
I recommend you to execute a command line script for that. Caution, it is platform-specific.
Actually you don't need any module you can use chrome usb api its already available for node webkit and electron applications https://developer.chrome.com/apps/usb
I am a Java developer. To speed some of our algorithms, we have decided to try CUDA.
But the Issue is, currently we have only one server with GPU installed and 3 developers have to work on it (by transferring the file each time over ssh and compiling and running it over there). This obviously is a tedious process.
What I would like to know is: On my machine which does not have GPU, can I using NSight work on CUDA by compiling and generating files locally. This can automatically be transferred to server to get the result.
If we can at least work on algorithm locally using NSight (or any other IDE) and not pure vim and then compile it to remove compile time errors, this would save quite some time.
On Linux you can do remote debugging using Nsight Eclipse Edition as documented here. This requires 5.5 or later. On Windows you need to start the Nsight monitor on the server and then just configure Nsight Visual Studio Edition to use the remote machine.
A project with the following technologies and components has surfaced: to up a Web stack solution initially composed with Ubuntu, JDK, JBoss, Spring MVC 3.0+, and MySQL.
In planning this project, I have been struggling to find answers to the following questions for first steps, best practices, and sequence:
1) Does the JDK (and JBoss) need to be installed as ‘root’? (I have seen articles that mention it is not a good idea to operate in root unless absolutely necessary due to the fatal consequences.)
2) Does Ubuntu need to be installed as a Server in order to accomplish all this, or can it also be installed as a Desktop? I have not been able to determine if having a JBoss and MySQL need to be installed on top of Linux as a server.
3) Does Maven need to be used within Spring STS in order to get JBoss, and MySQL (and in the future Hibernate) to work successfully together?
4) My intent is to install in this order: a) Ubuntu -> b) Java -> c) JBoss -> d) Spring STS -> and e) MySQL. Are there any blatant conflicts in this sequence?
JBoss will require Java (recommend Java 7) before it will do anything. I don't think it really "installs" per-say, but rather just unpacks to some directory (even if you install from the package manager, it just really extracts itself). I question your need for Spring since JBoss and Java EE in general really does everything Spring does, and better now-a-days. Unless you have a specific requirement for Spring, I'd question this extra dependency.
For linux - in a high level, any OS can be a "server", all it needs is to be capable of serving things (web pages, ssh connections, etc). In M$ world, different "levels" of the OS have been specially designed based on anticipated task/workload. So for example, while Windows 7 can indeed run as a server, it was not designed for it and therefore may not be optimized or include helper utilities and tools to make life easier as a sys admin of the system. Windows Server on the other hand does include all the "normal" server tools and lots of goodies to make maintaining and setting the server up easier.
In linux land, this is no such thing. Linux is the kernel that talks back and forth with the bare metal, etc... and Distro makers will take that and build an OS around the kernel, basically just attaching any packages they feel their distro needs... such as wget, or cat, or any other standard userland apps, plus some non-standard such as mysql or java or whatever they want.
Now, some distributions of linux will tailor themselves at being "server" ready, while others will tailor themselves at being a desktop OS. The difference? It's really just whatever default packages the distribution maker decides to include or not. For example, the overwhelming majority of linux servers are run completely headless, and therefore there is absolutely no reason to have X11 and a huge bloated GUI environment installed and/or running on that system... it's pointless. Also, an "average joe" user does not need MySQL installed by default on his desktop system since it would only bloat his system and he likely won't ever use it.
So basically it comes down to default installed packages.
Some linux server distros take this further and exercise extreme caution when making updates, patches, or new releases in the name of stability and security, while on the other hand most desktop distros are more haphazard with their updates since if it breaks a home users web browser, it's probably not a huge deal... but if a server update breaks the webserver application stack, now that's a serious problem.
So you'll find server OS's like CentOS (based on upstream RHEL) are extremely slow to bring in the "latest and greatest" features that desktop OS's get early on. Their goal is high security and long term stability.
Now, for Ubuntu. While I certainty know a lot of folks run Ubuntu as their server OS choice (partly due to Amazon choosing Ubuntu as the default linux VM for their ECS cloud), but I'd really question this. Ubuntu is not focused on being a server. It's focused on being a great all-around desktop oriented OS. Yes the LTS version is meant for long term stability, but it's based out of a desktop OS, so it's still not the focus.
IMHO, I'd go with CentOS because it's free and completely binary compatible version of RHEL - and RHEL is the de-facto standard for enterprise-grade linux servers. Be aware though, the RHEL way of doing things is a bit different than the debian way -- so there is no apt-get, you must use yum install instead. Startup scripts are different and some ways of doing things are different, but really, once you know linux, you know linux.
EDIT: Also check into Jenkins - its a free opensource continuous integration system that runs on JBoss or Tomcat or any other container, and can automagically pull your code from a repo (github, git, svn, etc) and compile/package it then push it to live deployment. You setup your ANT or Maven build scripts, and it can kick off on a schedule or however you configure it.
EDIT EDIT: I'd also recommend using OpenJDK -- as it's likely included in your package manager (for just about every disto) and will be more updated than the oracle version if it's in your package manager too. I've found most "server" distros will have OpenJDK 7 while only having Oracle java 6 in their package managers. Also, installing it via the package manager will enable you to keep it updated a ton easier.
Installed as root, why not? Run as root, probably not a good idea.
If you want a desktop, install a desktop distrib. If you want a server, install a server distrib. This doesn't change what can and can't be run in the OS. It only changes what is installed by default.
Maven is a build tool. JBoss doesn't care how you build your app. All it cares about is if the application you deploy is a valid Java EE application.
No. You need an OS, so Ubuntu must come first. JBoss and (AFAIK) Spring STS need a JRE to run, as they're Java applications, so Java should be installed before them. MySQL is independent of JBoss, STS and Java, so you can install it whenever you want.
Note that if you're struggling just with this installation part, be prepared to suffer with the rest. Building a Java EE webapp is not a piece of cake, and you should probably find some experienced developer to help you, as it seems you're only beginning with Java.
I'm reading a book which says there are these subsystems:
win32,os/2,posix,etc..
But I don't have any perceptual knowledge with these notations, can you explain it in short words?
I get the feeling the concept of a "subsystem" is somewhat ill-defined, or at least used with different meanings in different contexts.
According to MSDN documentation:
Environment subsystems are Windows NT processes that emulate different operating system environments. The Windows NT executive provides generic services that all environment subsystems can call to perform basic operating system functions.
Windows Internals book talks about the following two subsystems:
Windows subsystem of which it says - "this [subsystem] is special in that Windows can't run without it. (It owns the keyboard, mouse and display and it is required to be present even on server systems with no interactive users logged in. In fact the other two (which two?) subsystems are configured to start on demand, whereas the Windows subsystem must always be running."
Subsystem for Unix-based Applications, also known as SUA[POSIX] subsystem
Now, the /SUBSYSTEM option that can be sent to the Microsoft VS C++ linker in its documentation says and I quote
You can specify any of the following subsystems:
BOOT_APPLICATION
An application that runs in the Windows boot environment. For more information about boot applications, see About the BCD WMI Provider.
CONSOLE
A Windows character-mode application. The operating system provides a console for console applications.
Extensible Firmware Interface (EFI) Image
The EFI subsystem options describe executable images that run in the Extensible Firmware Interface environment. This environment is typically provided with the hardware and executes before the operating system is loaded. The major differences between EFI image types are the memory location that the image is loaded into and the action that's taken when the call to the image returns. An EFI_APPLICATION image is unloaded when control returns. An EFI_BOOT_SERVICE_DRIVER or EFI_RUNTIME_DRIVER is unloaded only if control returns with an error code. An EFI_ROM image is executed from ROM. For more information, see the specifications on the Unified EFI Forum website.
NATIVE
Code that runs without a subsystem environment—for example, kernel mode device drivers and native system processes. This option is usually reserved for Windows system features.
POSIX
An app that runs in the POSIX subsystem in Windows.
WINDOWS
An app that runs in the Windows graphical environment. This includes both desktop apps and Windows Store apps.
WINDOWSCE
The WINDOWSCE subsystem indicates that the app is intended to run on a device that has a version of the Windows CE kernel. Versions of the kernel include PocketPC, Windows Mobile, Windows Phone 7, Windows CE V1.0-6.0R3, and Windows Embedded Compact 7.
So there you go. Finally, people sometimes talk about the "Win32" subsystem, which I don't know if I should take to mean the "windows" subsystem or the "console" subsystem in the linker option sense.
Back to the Windows Internals book, it further says "each executable image (.exe) is bound to one and only one subsystem" which would explain the need to specify the subsystem your app is for at link-time.
Windows starting from NT (NT 3.1) is able to support semantics of different operating systems (or OS families) that existed at that time (1993). Microsoft called them Subsystems (today they would probably call them emulation layers).
When linking against a subsystem, it decides how your semantics will be. For the Win32 subsystem, for example, filenames are case insensitive (foo.txt and fOo.Txt refer to the same file) and device files (like con or nul) exist in every directory. For the POSIX subsystem, file names are case sensitive and device files exist only at one place. By linking existing (legacy) applications against a subsystem different from Win32, these apps "feel" more like the respective OSes and porting work is reduced.
If you want to know the subsystem of an EXE/DLL, you can open it in DependencyWalker - if it (directly or indirectly) depends on KERNEL32.DLL it is Win32 subsystem, if it (directly) depends on NTDLL.DLL it is native subsystem (Note that KERNEL32.DLL will itself depend on NTDLL.DLL, providing the compatibility layer for the Win32 subsystem).
This is mostly obsolete today. I say mostly as Microsoft included a new "Linux subsystem" in Windows 10 Anniversary update (which is a subsystem like Native, Win32 or POSIX), that behaves binary equivalent to Linux, making it easy to compile Linux applications to be run on Windows (or more precisely, its Linux subsystem).
The /SUBSYSTEM linker switch started out to do exactly the same, but was augmented with more options later (/SUBSYSTEM:CONSOLE also compiles for the Win32 subsystem but the application will allocate a console window if it did not inherit one from its parent process, /SUBSYSTEM:EFI_APPLICATION will compile an executable that cannot run on Windows at all, but will run in the Exensible Firmware Interface (EFI/UEFI) boot environment, etc.).
It might help if we knew which book you're referring to!
More generally, Win32 (which is 32-bit Windows, i.e. Windows NT 3.5 or later), OS/2 and the POSIX family are all operating systems. (POSIX is a standard family of APIs into the UNIX-like operating systems - see here for more.)
It sounds like what you describe is a program that can run on many different operating systems and which has operating-system specific components -- these would be the "subsystems".
However, creating an application in this way does sound like the kind of thing that was done fifteen or twenty years ago. That's about the time that people used to refer to those three families of operating systems, too...