Porting serial daemon + PHP to Windows - windows

I have a Linux system with:
a daemon that communicate with another device via RS232 port.
a php + javascript web site that talks to the daemon through a
socket.
Now the boss wants to find out how much of an effort is required to port all these onto Windowze.
Having never really programmed on Windows before, I'd like to ask how easy/hard this is going to be and what the options are.
Thanks,

PHP will probably run as is. Javascript runs in the web browser, and will run as is. Your daemon is a service on windows. Apparently it listens on a socket for commands from the web page via javascript.
You did not state what language you are targeting for the service. Some languages such as C# dot Net, have built-in libraries for making clean services that can pause, stop, start, and interact with the Windows Service Control system. C# would be a good choice to make a service that can install and remove itself easily, and it supports nice high level socket control to listen to the PHP and javascript code. I have used perl, C#, C++, and even Visual Basic running as a service, so the choice is yours.
If your choice of Windows language is that compiles to some .EXE, then a low-level way to add a service is as follows. You will need INSTSRV.exe and SRVANY.EXE, which come on the Windows Resource Kit, or can be downloaded easily with a quick web search.
The short version :
After you get the server runnign when you are logged in and debugged, install the APP server as normal to the C:\Program Files\APP directory. This would be the app that connects to the serial port and does what you want via sockets.
Copy instsrv.exe to your C:\WINDOWS\system32 directory/
Copy SRVANY.EXE to C:\Program Files\YOURAPP
From command prompt, run this command – INSTSRV YOURAPP "C:\Program Files\YOURAPP\srvany.exe"
Run the Registry Editor (REGEDT.EXE)
Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YOURAPP: create a ‘Parameters‘ key (folder)
Under the this key, create a REG_SZ string value called Application and add in this data C:\Program Files\YOURAPP\YOURAPP.exe
Close Regedit, then open the services console in administrative tools, or start, run, services.msc, confirm it is set to start automatically and the logon account is LocalSystem. Then unclick the Allow Service to Interact with Desktop. If you click this, it will interrupt you on Windows 7 boxes whenever it writes to the screen.
Start the service, check in Task Manager, you will see YOURAPP.exe inthere, and if you stop the service then YOURAPP.exe will disappear.
The long version
Details on this are at http://support.microsoft.com/kb/137890

Related

Windows Service unable to open COM port

We have a windows service (written in C#) that uses a 3rd party DLL to communicate with a COM printer.
Already tested the windows service in 4 local machines, and in every case the printer works correctly.
We also have this windows service already deployed in production in several clients and it also works correctly, but now we where deploying it to a new client and in every test we make the DLL is unable to open the COM port (already checked to see if it's in use by another application and nothing).
But the strangest thing is that if we launch the service .exe from command line it works correctly, so we tried launching the service as the user connected to the machine (instead of Local System) and even so it doesn't work.
What can be causing this? Is there any way, either by Windows configuration or by some software, to prevent Windows Service to communicate with the COM port? Or is there any other explanation?
Sorry to all of you that came here looking for a solution to your problem, but my solution was to change the 3rd party DLL.

standalone web application

Is there way to run web application as standalone desktop application? Could be web application written using PHP, MySQL and Apache converted to standalone application which meets following requirements:
1. Application should be called as http://myapp.localhost.
2. Application should have desktop icon which directly opens browser with application's URL.
3. Source code of web application should be hidden from users.
4. Installation for end user must be as easy as possible.
Now I do steps 1-2 using xampp and manually creating shortcut. I was interested in some wrapper, installer which do above steps automatically. But I have no idea about 3rd step.
Regarding item 3, see Can you "compile" PHP code?. This would allow you to develop in PHP and deploy the application via an installer.
There are several installer packages which would allow you to automate these steps, depending on your development environment.
PHP and MySQL require to have a web server running. That means you will need to copy the code over to the client's machine and then run the web server locally still on the client's machine.
If that's what you want, look into the Microsoft IIS Express (here).
In short, IIS is a web server that can host and run a server side web application, written in ASP.NET or PHP.
Here are the steps you need to take:
Install IIS express on the client's machine (one-time process, and I think quite acceptable - treat this as a runtime installation).
Create a designated (hidden) folder for the source files of the web application that you want to deploy (one-time process).
Create a windows batch file (bat or cmd) that starts the IIS (as described here) and then opens the website's URL so that the default browser starts. This file will serve as a shortcut, so you can place it on the desktop or wherever appropriate (one-time process).
Deploy your web application to the hidden folder from step 2 above (repetitive process - deploy to the same folder when you want to upgrade the clients to a new version).
Please have in mind that I am basing my suggestion on your requirement to host and run the application locally (on localhost).
However, if there's an option to run the application on a separate machine (not a localhost), then you could simply place a desktop shortcut to the network or internet address URL that would open the default browser without problems.
i would suggest Pouchdb http://pouchdb.com/api.html and Adobe Air http://www.adobe.com/devnet/air/air-sdk-download.edu.html. This way you can code with html and javascript and package it with Adobe Air.
I'm afraid it's not that simple.
If you want to use this approach (and I highly discourage it), you will have to deploy a webserver of some sorts on the client. You should be able to run the Apache/IIS Express and MySQL/SQLite executable and start a simple webserver and database.
If you'd also like a icon, you can create an installer that creates this icon and points to the URL you wish.
I'm afraid that's not possible. PHP is and always will be a scripting language. You might be able to obfuscate it somehow, but anyone who can download your application will be able to de-obfuscate it.
Again, you can create an installer. Inno Setup is pretty good from what I've heard.

Detect software uninstallation on Windows

I would like to log the uninstall event onto my own web-server for my desktop application. Is there a way I can detect the uninstallation on Windows?
Your installer override the Installer.OnAfterUninstall method
http://msdn.microsoft.com/en-us/library/system.configuration.install.installer.onafteruninstall(v=vs.100).aspx
There, you can call back to your web server.
Be sure to program for the possibility that there is no internet connection at the time of uninstall. Also, note that some firewalls may block your attempt to connect to your server from the uninstall program, or prompt the user for permission to allow the connection.
If you are using an installer other than Microsoft's (e.g. NSIS or whatever) for the desktop application, there is probably a similar hook.

Starting a Windows service in an interactive session

A colleague has a batch script program which needs to to run on a Windows Server in console mode, so that it has access to a Windows interactive session. The server is rebooted at regular intervals automatically (there's an unrelated closed-source application that runs on this machine that we have no control over). After a reboot he wants to automatically start a Windows interactive session and have this script run, plus the service needs to also have access to network resources (CIFS drives, in particular).
Here's what we've tried so far:
Start as Windows service. This failed, since a Windows service can either have access to interactive session or to network resources, but never both.
Used Microsoft management console to add the script to run at startup, however this did not work.
Used an HKLM registry key to start to run this script, however it only gets started when we manually open a remote desktop session on the server.
Creating a scheduled task. The program invoked did not have access to interactive windows session.
Any other suggestions? (Or maybe he missed something when he set up one of these suggestions?)
In case "Interact with desktop" on the service is not enough (I have seen a handful of cases where it is not), you can combine it with AutoAdminLogon. Create three (or four for a domain) REG_SZ values under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
DefaultUsername
DefaultPassword
DefaultDomain
AutoAdminLogon
AutoAdminLogon should be set to the string "1", the others are self-explanatory.
Obviously this has security issues big enough to fly Jupiter through.
Have you tried having your script run as a Windows service, but allowing it to interact with the desktop?
Specifically:
Go to the service properties page
Click on the "Log On" tab
Select "Local System account"
Check "Allow service to interact with desktop"
See my similar question and real answer to it: How to start a process from windows service into currently logged in user's session
NOTE: "Interact with desktop" checkbox is not enough at all.
I recommend going about this another way. You could build another Windows app that communicates via IPC to the Windows Service and that could be what deals with the closed souorce application. But if you must, you can specify an option in the service (you can do this through MMC, registry, etc). Basically, you can see this option by going to Computer Management->Services and Applications->Services->Right click your service->Change account to Local System and check "Allow system to interact with desktop."
However, again, I recommend choosing another path.
I had to do something similar recently; a route that I found but discarded due to security concerns is to have the interactive service set self as running in interactive mode and then run the ImpersonateUser function in the win32 API, which I think will provide the benefits of both a user and the interactive session available from the LocalSystem.
Needless to say, if someone broke into a service that did that, they would have total control of the machine.

What can Services do under Windows?

Does anyone have a good guide to capabilities of Windows Services under XP? In particular, I am trying to find out what happens when a program being run as a service tries to open windows, but hasn't been given permission to interact with the desktop.
Basically, I have a program that is/was a GUI application, that should be able to run as a service for long term background processing. Rewriting the program to not display the GUI elements when doing background processing is a major effort, so I'd like to see if there is just a way to ignore the UI elements. It is sort of working now, as long as too many windows aren't opened. I'm trying to figure out what limits I might be running into. Ideally, there would be an MSDN page that discusses this, but I've had no luck finding one yet.
Generally, services should be designed to not have any visible UI. The entire point of a service is to run in the background, without UI, unattended. (Think SQL Server, IIS, etc.)
In most scenarios, a separate application controls the service's operation, should a GUI be needed. (Continuing the samples I just mentioned, SQL Server Management Studio, IIS Manager, etc.) These separate applications configure and manipulate the service (and occasionally, if needed, bounce said service).
If your service requires occasional UI, and said UI can't be isolated to a control app, then you probably should reconsider the fact that you're using a service to begin with. Perhaps a UI application which resides in the system notification area is the right pattern to use? (E.G., Windows Live Communicator.)
A service in Microsoft Windows is a program that runs whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as directory replication, process monitoring, or services to other machines on a network, such as support for the Internet HTTP protocol
Usually it is implemented as a console application that runs in the background and performs tasks that don't require user interaction.
The installed services can be configured through the Services applet, available from
Control Panel --> Administrative Tools in Windows 2000/XP.
Services can be configured to start automatically when operating system starts, so you dont have to start each of them manually after a system reboot.
Creating a Simple Service - MSDN Article
Writing Windows Services Made easy - Code Project Article
Five Steps to Writing Windows Services in C - DevX Article
If you should be thinking of eventually migrating to a newer OS such as Vista or Server 2008, you will find that you cannot give a service permission to interact with the desktop at all. Therefore, from the point of view of forwards compatibility, you should design your service to not require it.
A service in Windows XP can interact with the Desktop if its "Allow Service to Interact with Desktop" property (MMC -> service properties -> Log On tab) is checked. It is also possible to do so by doing the following:
hWinstation = OpenWindowStation("winsta0", FALSE, MAXIMUM_ALLOWED);
SetProcessWindowStation(hWinstation);
hDesktop = OpenDesktop("default", 0, FALSE, MAXIMUM_ALLOWED);
SetThreadDesktop(hDesk);
But be aware that presenting UI from a service process in Windows XP will almost always lead to a security problem (see Shatter attack). You should try to break out the UI part of your application from the service.
Usually the service won't have permission to write to the window station and desktop, so it will fail; even running applications that load user32.dll can fail simply because user32 has initialization code that wants to talk to the window station and can't get access to it unless the service is running as an administrator.

Resources