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
Related
Can I create a webapplication on my windows 10 IOT running device (R-PI 3)?
On other PI's I've got Debian running with LightHttpd, but I can't seem to find anything on a webserver on Win10 IOT device.
I did see some examples on self creating a -very simple- webserver (ie listening on a port) but there should be more than that?
PS
I added 2 tages: Windows IOT and Windows-10-IOT-Core.... are these the same?
Can I create a webapplication on my windows 10 IOT running device
(R-PI 3)?
Yes, you can start with Hello blinky official sample. There are also Python and Node.js supported.
Using ASP.NET, you can publish Web Application on Windows IoT core. (Note the version of ASP.NET, more detailed information is here.)
And, restup is a HTTP server for universal windows platform (UWP) apps that can run on Raspberry Pi with Windows IoT core.
PS I added 2 tages: Windows IOT and Windows-10-IOT-Core.... are these
the same?
Windows IoT core is an edition of Windows 10 differs from desktop and mobile editions. It is optimized for smaller devices with limited resources, such as Raspberry Pi 2 and 3.
Window IoT is something about Internet of Things you can create with Windows.
For tags in SO, "Windows IoT core" and "Window IoT" have identical function.
There are a couple of ways to do this that I've come across which might interest you:
1) As you suggest, it is very simple as you suggest to write you're own server app or app service that listens on a port and responds. Here is a decent example which was easy to follow and implement:
https://sandervandevelde.wordpress.com/2016/04/08/building-a-windows-10-iot-core-background-webserver/
2) Also, it is possible to develop a plugin for Windows Device Portal (WDP) by following the instructions here:
https://learn.microsoft.com/en-us/archive/msdn-magazine/2017/october/windows-device-portal-write-a-windows-device-portal-packaged-plug-in
I have tried this and it works very nicely. It demonstrates how to serve static content and dynamic content either from the foreground or a background task.
I am able to generate & install windows phone build in my Microsoft Lumia 640. Its running on Windows OS 8.1.
But as soon as I run application generated by CN1 build server, it gives error
An internal application error occurred: java.lang.RuntimeException Unsupported operation as per below screen shot.
For a testing purpose I created new CN1 Project and without changing any code / theme.res I just sent windows phone build and it ended up with the same error.
Unfortunately I didnt get any log output from windows phone, as it doesnt support Logcat like Android. Also I tried to grab Isolated Storage by WP Power Tools but there was nothing in it.
Anyone faced / facing this in Codename One windows phone build ?
The Windows Phone port is the least mature of the Codename One ports having gone thru 3 rewrites due to changes from Microsoft.
We are now debating the 4th rewrite, in the meantime some community members did their own port which should be more complete:
https://github.com/Pmovil/CN1WindowsPort
So as the short answer I suggest using that. For an explanation on how we got here read on.
The reason we didn't already start with the 4th port was Microsofts project astoria that they suddenly (might have) canceled. We were relying on this project for future Windows Phone support but now that its status is unclear we are in a bind.
We also have the JavaScript port & the Windows desktop port as options for targeting windows phone alleviating some of the problem.
If MS cancels the project for good we'll dedicate the resources for a complete rewrite of the port, but that will take time. However, we don't want to start off on such a huge effort and suddenly be faced with a huge shortcut of Android compatibility.
I heard that few of the Win32 APIs are not supported in Windows 8.1 phone. I have an c++ application which is using some Win32 APIs. How to check whether my application will work on Windows 8.1 phone?
You can find the list of supported Win32 functions on MSDN. However, since it can be hard to match supported functions with your code, you might as well try to compile the code yourself and check the errors (if any).
It mostly depends on what you were doing with win32. The list of functions is quite limited IMHO.
The best way is to run the WACK (Windows Application Certification Kit).
Right-click project, choose Store, then Create App Packages...
Say "No" to upload packages, then click Next
Select ARM & x86 release builds, then click Create
Click Launch WACK on the next screen
You might have to download a WACK update before you can certify (it changes pretty regularly as new APIs are enabled).
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?
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...