Has anyone tried running a headless Windows XP system (no keyboard or monitor)? I have an application where I am upgrading a headless MS-DOS system with a modern OS. Linux is not a good option for me. In testing, I have been able to add my app to the startup menu and it will boot and run unattended. I wonder if this system can be reliable? Are there any changes that I must make to make it reliable? I know that XP Embedded would be an excellent option, but it is a low volume project and the buy in costs and learning curve are a bit steep.
What advantage does a GUI give you on a headless system, are you going to use VNC or something similar? It's a shame Linux is not usable as it is _ideal_ for remote equipment, with no overhead of a GUI. All the remote Windows machines I have installed have come to grief sooner or later, but as long as you allow for that, and screw everything down (no updates, tight firewall) then they can achieve reasonable uptimes. I believe that XP embedded is coming to the end of its service life (according to the Microsoft roadmap), so I'm not sure what you should be looking at.
WinXP-Pro lets you remotely access the headless computer's desktop through RDP, so it shouldn't be a problem to manage. But this service is not installed by default. If you're using WinXP-non-pro, where the service is not available, you can install RealVNC to do the same.
A few points to consider are:
There can be problems in headless operation specific to particular PC hardware. You need to check if the particular BIOS you will be using can be set to ignore missing keyboards and monitors (some will stop and report an error and wait for you to "press a key to continue").
At some point you may want to plug in a keyboard and mouse. If you use PS/2 connections, you usually have to re-boot before they are recognised. If you use USB connections, they are usually recognised right away (although this can be somewhat flaky under MS-Windows XP). I don't know if you can hot-plug a VGA monitor without risk, so I don't know what you would want to do there.
I don't know your application, but you might wish think about whether you can squeeze a permanently attached LCD monitor into it, and allow for a USB keyboard and mouse to be attached when necessary. MS Windows XP (or really any version of MS Windows) isn't really intended to be used in a "headless" application. I've never seen an installation yet where MS Windows didn't at some point need a kick to get it going again. At least if a monitor is there you can see what is going on. MS-DOS wasn't very sophisticated, but from a software stand point a system using it was usually as reliable as the application software itself.
I believe you will need to have the system auto log-in and the application auto-start. I don't know how much experience you have with this particular treat, so don't be offended if I am telling you something you already know (you said you have it auto starting already, so you have at least some of this done). This seemingly simple task is positively painful to configure for Windows XP Pro, and is even worse if you have to log into a network domain (e.g. a file server). This is simply something that MS Windows XP Pro just isn't intended to do and tries very hard to stop you from doing it.
There are a variety of ways of doing this though, and some of them involving hacking the MS Windows registry. I want to point out that you have to do this in a completely different way if you are logging into a network domain than if you are operating in stand alone mode. There is a program called "tweakui" that you can download from somewhere and install that makes this somewhat easier.
Will you be using a UPS? Most of them these days use a USB connection to the PC for control signals. The built-in power management software options in MS Windows XP Pro for this type of UPS are not really suitable for industrial control applications (it's not the same as the old serial handshake). You will end up installing someone's proprietary UPS software. If the customer has to replace the UPS with a different model in a couple of years, they will probably need to install different proprietary software for the new UPS. This means that monitor, keyboard, mouse, and CD-ROM access (and "administrator" log-in) may be needed just to change a UPS. There isn't much choice though, as this is how all the modern small UPSs work and MS-Windows XP Pro itself just isn't designed to handle this properly. The standard GNOME power manager in Linux does it properly though, so it isn't a limitation of the UPSs themselves.
I haven't used MS Windows XP Embedded, but from my own investigations into it, I agree that it doesn't seem to offer any advantages to someone who is just building a few systems. Where the benefit comes in is in being able to strip out some of the excess junk to squeeze it into less RAM and disk space, and so save some money on hardware. You have to put a lot of work into this though, so it really isn't worth it for most people.
Something to note about MS Windows XP is that it is an obsolete product and support ends in 2 years. While your software isn't going to suddenly stop working on that date, it means that within a couple of years you may have trouble finding hardware that is compatible with your software (any special drivers in particular could be a problem, as driver compatibility with MS Vista is poor).
On the other hand, I can't really recommend using MS Windows Vista at this time either. It is a real resource hog, and a lot of people are reporting a lot of problems with it. There are lots of reports of people giving up and replacing MS Windows Vista with XP. So, it seems there aren't any good answers to that problem.
There is something about moving MS-DOS applications to MS Windows that I thought I should mention. Some MS-DOS programs will push CPU usage to 100%. This is a factor of how they were written and what they had to do. When running on MS-DOS on an older PC this isn't a problem. On MS Windows though it can be serious if it bogs down the system and keeps it from doing anything else. You may wish to look into whether your application is doing this.
One last point, which has to do with future compatibility. Most of the newer desktop PC CPUs being sold today are 64 bit, and have been for a while. Most of them however are currently being used in 32 bit compatibility mode because MS Windows has been very slow to adapt to changing technology. The 64 bit x86 CPU hardware works though, and people have been using 64 bit Linux on them for some time now. At some point in the future, even MS Windows will change to 64 bit (MS Windows Vista has a 64 bit version). When this happens, 32 bit MS Windows will fade away, because vendors will stop producing 32 bit drivers for new hardware. The hardware will still have the 32 bit capability, but you won't be able to use it.
You might say "so what"? However, there is a technical problem which affects MS-DOS programs. In 32 bit mode, the x86 CPU also has a 16 bit mode available, which is what allows 16 bit MS-DOS programs to run at the same time. In 64 bit mode, the x86 CPU has a 32 bit mode available. But note, in 64 bit mode you can't access 16 bit mode anymore! MS-DOS programs won't run, nor will MS Windows 95/98/ME programs. At some point, that MS-DOS program is going to have to be rewritten, or at least ported.
As for marc sinclair's suggestion of using Linux, I agree that it is usually better suited than MS Windows for embedded applications. Again though, I don't really know what you are doing so I will leave it at that.
Thanks to all who answered, there were many good points...
I know how to make the system log in automatically, so that is not a major issue for me. The PC is an industrial model with no BIOS issues for a missing keyboard. We will have a video card present in the system.
We don't have any plans for a UPS at this time, I have suggested one though.
I plan to use RDP or more likely VNC to maintain the system.
There are no MS-DOS application issues, as I have rewritten the app from the ground up in C# for .NET.
I know that Linux might be good for this, but I am not having much luck with drivers for my particular hardware. I tried using Linux and gave up. I may try it again in the future.
I have not looked at the end of service date for XP Embedded, but that issue makes it even less attractive.
I will add my new comments directly below each of your statements.
> Thanks to all who answered, there were many good points...
> I know how to make the system log in automatically, so that is not
> a major issue for me. The PC is an industrial model with no BIOS
> issues for a missing keyboard. We will have a video card present
> in the system. <
I think what I was trying to say in my previous message (in a rather long winded and round about manner) was that for MS Windows XP Pro, auto log-in and start-up requires a completely different set-up if you are operating networked than if you are stand-alone. This sort of set-up seems to be outside the experience of a typical IT person with an MSCE certificate. Be prepared for some problems in this case unless you are doing it yourself (or don't need to connect to an SMB network).
> We don't have any plans for a UPS at this time, I have suggested
> one though. <
To clarify my previous comments, if you use a UPS with an RS-232 handshake, the software that comes with MS-Windows XP is written by APC, who know what they are doing. If you plug in one with a USB
connection, you get a different set of menus written by Microsoft, who apparently don't know what they are doing when it comes to a UPS. If you end up with a USB UPS, try to get one that has some good control software (perhaps someone else could make a recommendation on this).
> I plan to use RDP or more likely VNC to maintain the system. <
No comments other than I take it you have some means for the electricians to do a controlled shut-down rather than just pulling the plug?
> There are no MS-DOS application issues, as I have rewritten the app
> from the ground up in C# for .NET. <
So the comments in my previous message on this subject do not apply.
> I know that Linux might be good for this, but I am not having much
> luck with drivers for my particular hardware. I tried using Linux
> and gave up. I may try it again in the future. <
I've had applications that I couldn't move from MS-DOS to MS-Windows, or from one version of MS-Windows to another version of MS-Windows because of no drivers for the hardware. I had wondered how you were going to be able to move an embedded MS-DOS program to MS-Windows, but as you mention above, it was really a complete re-implementation anyway.
As one aside though, you mentioned that you were using C#. There is a Linux clone of C#/DotNet put out by Novell called "Mono". Some people report good luck with it, while others report that compatibility is not 100% (Novell isn't trying for 100% anyway). There is also apparently a VB compiler for it as well. If you happen to want to use C#, Mono might work for you or it might not. Other than Novell though, nobody doing work on Linux or Unix has much interest in C# (Novell has customers porting existing vertical applications to Linux).
You might want to have a look at Python though. Portability of applications written in Python is surprisingly good (i.e. I've done moves between Linux and Windows with no code changes). It is a good language for doing small to medium size custom applications because it accommodates rapid development and testing. The library selection is excellent as well, and there are lots of third party libraries as well (free of course). It is about as widely used as C# (or perhaps a bit more so), so there are lots of books, etc. available for it (O'Reilly has a good series). I would recommend it regardless of which operating system you use.
> I have not looked at the end of service date for XP Embedded, but
> that issue makes it even less attractive. <
The end of service date I mentioned for MS-Windows XP Pro, not Embedded. That is, regular MS Windows XP is obsolete *now*, and support ends in two years (or perhaps less at this point).
At the last I heard, Microsoft is not coming out with a direct replacement for MS-Windows XP Embedded. Supposedly they will have "MS Windows Vista for Embedded Systems", but that will just be regular MS Windows Vista Business or MS Windows Vista Ultimate with some features stripped out. It seems that product line was not successful enough to be worth continuing in future. The support life
for "MS-Windows XP Embedded" might be a bit longer than the regular desktop version, but it would be a bad idea to design a new project around it now.
If your application works on regular MS-Windows XP, there is really not much point in using the Embedded version anyway. The point about "Embedded" was to strip out unused components to squeeze it down onto cheaper hardware, and to allow the integrator to put some of their own branding on some of the screens. It was never really a true embedded OS anyway.
Windows Embedded has one feature that I would really appreciate, it can be booted from a Live CD. There you have a static system that cannot be changed. IMHO, that would be far more troublefree. (as long as the CD is not removed or physically damaged, that is) XPE can create a temporary RAM disk for its runtime data, then it starts all over again on the next reboot. I would simply mount a flash drive of some sort to store MY data files.
It also generally runs XP programs and can hopefully use XP driver libraries. You cannot say the same for CE or Linux.
I think that XPE is a great idea, too bad it hasn't caught on better. The $1000 buy in might have something to do with that. I'm sure there are other issues also.
I haven't used XP Embedded, but I've used embedded NT in the past. I've heard from others that you can get your system running on flash and then "lock it in" to where it will do the Ramdrive trick and not commit changes to the hard drive. New versions of Virtual PC also work like this. So, from what I hear, the learning curve for embedded XP probably isn't that bad.
Disclaimer: I'm not a die hard MS fan, its just that if you have to use it, make it work as well as it can for embedded style applications. Avoid windows installation rot, and hard drive failures by not allowing windows to write to your flash drive and you should be golden.
Linux, of course does all of that without the $1000 buy in. And using XP libraries and programs might well make the embedded part moot as they are pretty large. But if the CD image part is attractive, I'll bet the regular version could be coerced to change where it puts it's stuff. That was one of the ideas behind the registry, I think. Then a little DOS magic to create the ramdisk before calling Windows and you would be home free. I'm not sure which libraries and programs are that attractive that I wouldn't just use Linux and the wealth of free stuff. But it is a little strange that there are hundreds of people who have created their own Linux distribution while it seems almost nobody hacks Windows. I suppose because the information is simply not available from the monopoly. I am curious to see how much of the embedded world has gone to Linux. I was tracking that for a while but I lost touch. I know Motorola is mostly Linux, but I wonder who else.
My customer uses Galil PCI bus motion cards. Galil has a Linux driver, but I don't like it. It appears to be ported from an old DOS library, full of FAR calls and stuff like that. It is also written as an DOS app, no open/close/read/write Unix API. It is also missing many features that are present and fully supported in their Windows version. If I could convince him to switch to an Ethernet version, life would be simpler, but he a large user base of PCI systems.
They also occasionally have the need for PLC comm drivers. They are easy to find (buy) for Windows but somewhat scarce for Linux.
I worked on a Linux version in my spare time for several months before I gave up. I was able to build a usable system in C# in a few weeks.
In reply to William Sturm: With regards to an Ethernet version of the application, you might mention to the customer that PCI bus is at the end of its life, just like ISA bus was a while ago. PCI bus is being replaced by PCI Express, which is not physically compatible with PCI.
Ethernet would give him more hardware independence in his next (post PCI) hardware generation and would also give him more flexibility in machine layout. Some of the things we talked about previously (e.g. diskless operation) are worth thinking about at the same time.
I'm not familiar with your application, so I don't know if the PCI card hardware has any performance advantages over the Ethernet versions.
Lack of vendor interest is a problem. Another is that some companies assume that everyone who wants to use Linux is a kernel hacker and they only give enough to get an idea of how to control their hardware. And, yes, far too often they provide "C code" and not a proper driver. But several companies have actually hired or otherwise convinced a Linux programmer to write them a driver. I think one thing that the community could do is form a pool of people who are qualified to write drivers and offer this as a service to companies with desirable hardware. The problem is that these folks are usually pretty busy already. I have had some success in getting companies to provide information so that I can add a feature or two, but yes, you have to want or need the feature pretty badly to dig in. We do have some very generous folks who have written many drivers, And quite a few get written as school work or to make a hardware project go. Free cool hardware would go a long way towards getting some of the more special stuff written. I'm messing with a frame grabber driver in fits and starts, but the project kinda died and I don't personally own a card. It takes a lot less to stop these efforts than it does to start them. Often, a $100 card would get you a driver. This is the kind of threshold that Linux was created to eliminate, but hardware still costs money. You can now become a *nix programmer without being employed as one. But to write drivers, you need a freebie or an interested company to buy the hardware or a genuine burning desire strong enough to get you to buy the hardware. There are enough people to write all the drivers Linux users need, but a little help from the other side would reap enormous ROI.
In reply to Curt Wuollet: Pretty often user mode "drivers" for embedded hardware don't actually do much other than add an extra layer of complexity to the application. The vendors provide a "driver" because customers expect a "driver". If the hardware is reasonably well documented, you can often just talk to it directly a lot more easily than you can use the vendor's user mode driver. Typically, you will only use 10% of the features in a piece of hardware, so you don't need to cover all the possible functionality.
If the driver is for a standard protocol, third party drivers are often a lot better than vendor provided drivers. The hardware vendor drivers are often just repackaged "demo" code from the original chip designers that was never intended for production use.
I don't intend to imply that no hardware vendor can produce good software. However, many hardware vendors are very tight on costs, so they can't afford to pay someone to write a really good driver that covers all the features. They compromise by paying someone to write a not very good driver that at least demonstrates all the features.
The quality of the MS-DOS and MS-Windows drivers are usually equally bad as well, but normally it's not as obvious because they provide them as a pre-compiled binary (because MS-DOS and MS-Windows systems don't normally come with a C compiler).
The reason why a Linux driver might look like an MS-DOS driver is because the drivers for MS-DOS, MS-Windows, and Linux would all be based on the same set of code with various hacks added to adapt it to each OS.
Some software developers did a study a while ago into why so few OEM written kernel mode vendor drivers for embedded hardware were making it into the mainline Linux kernel while drivers written by third parties were. The conclusion was that vendors were submitting drivers, but the quality of the code was typically so poor that most were being rejected for quality reasons. The kernel mode drivers that were being accepted were from people with previous experience working with operating system code. The general conclusion by the kernel developers was that they would prefer to just have documentation on how the hardware worked so that someone else could write the drivers and this is the basis they have been working on for some time now.
Microsoft has recognised this problem as well, but I'm not sure how they intend to deal with it. They do have a quality certification program, but it doesn't seem to be very successful and it is unlikely to cover much embedded hardware.
No argument here, but miscellaneous C code that reads and writes to hardware from userland is not a driver and presents many problems, not the least of which is being preempted. What are needed are Linux (kernel) Drivers in the strict sense so that you can use DMA, etc. and with RTAI and the recent kernel facilities, achieve real time operation. Interrupts are an issue, but ways have been found to make them work so intelligent hardware can be used to good advantage. COMEDI is an example of what is needed to really make use of DAQ cards, for example. Something similar for the Woodhead protocol cards would be really great as well, they might then sell enough to get the price down where it's feasible to use them.
In reply to Curt Wuollet: The reason why almost nobody creates and distributes their own version of MS Windows is because it is illegal to do so. That tends to put a damper on experimentation.
Yeah, I suppose so, I imagine the ridiculous
shrinkwrap license bans you from changing
anything. But people did quite a bit of DOS
hacking when it was king. It's interesting
that the older Windows becomes, the less
people know about it.
This is what Embedded XP is for, and it is a legal MS product. I've run machines on Linux and in a lot of ways I like it better, but if the company wants to use MS you have to go the MS route which is to buy Embedded XP.
I suppose it depends on what you do. If all you
do is run other people's software and you have
lots of money, EXP is an option. If you are
going to develop your own embedded class
software, Linux has a lot of advantages, like
you can fund development out of pocket,
and it will stay running indefinitely if you
do your part. Projects for sale are becoming
Linux territory because you make a _lot_
more money at commodity pricing if you
don't pay royalties to several companies.
And for headless apps, no one cares
what it runs on, as long as it runs.
In reply to Ken Emmons Jr.: MS Windows XP Embedded may be a legal product, but only if you happen to be Microsoft. It is illegal for you yourself to take a copy of it, modify it, strip out Microsoft's trademarks, and sell it as your own product. That is called copyright violation.
On the other hand, it is perfectly legal for you to take a copy of one of the more popular commercial Linux distributions, strip out their trademarks and logos, remove some of their packages, add in some different ones, and then offer it as your own product. As long as you include an offer of source code for any GPL licensed software in your version, you have complied with all copyright obligations. And in fact, people do this all the time to produce a distribution that is oriented towards particular applications.
And even less restrictive, you can take a copy of OpenBSD (or substitute your favorite BSD tree here) and strip out their logos and add your own and distribute it as yours without having to give anyone anything. You don't even have to give the customer code or the rights to redistribute as you do with the GPL. Of course, if you're a small shop, and you don't want the customer to hound you to death, you can also give them the BSD code, which won't cost you anything. (And it's the morally correct thing to do anyway.)
In fact, this is so completely legal that Red Hat used OpenBSD as the base for their secure web server edition a few years ago that was *NOT* freely distributable and didn't come with the code. Why? Because the BSD license was the only way they could get an existing code base that didn't obligate them to allow redistribution.
Michael R. Batchelor
Industrial Informatics, Inc.
3281 Associate Dr.
N. Charleston, SC 29418
843-329-0342 x111 Voice
In reply to Michael Griffin:
The original post did not mention that he was stripping microsoft trademarks, just that he wanted a Windows machine that was reliable and did not want to go to linux or Embedded XP. I was just mentioning that is you want a reliable microsoft machine with read only filesystems you should purchase Embedded XP. Of course if you are reselling a product without paying for it you are in violation of the law, I don't believe I ever mentioned anything of the sort.
I personally prefer Linux for these types of applications, but there are times when it is not practical for your project.
In reply to Ken Emmons Jr.: You replied to my message, which replied to Curt Wuollet's message who... The discussion had by that time (as often happens) gone far off the original topic.
Curt Wuollet was asking why so few hobbyists are digging as deeply into MS-Windows as compared to "the old days" of MS-DOS. I was pointing that this was due to the licensing terms of MS-Windows. An OS with "free" licensing terms allow people to not just modify the OS, but also to distribute their modifications to other people who in turn add their own twist to it. You can't do this with MS Windows XP Embedded.
That may not be relevant to some people. It does however explain why (as Mr. Wuollet asked) there is relatively little interest these days in how MS-Windows actually works inside.
Back in the good old days of DOS 3.1, I was able to convert my US keyboard into a German one (I was studying German at the time and wanted the umlauted vowels, etc.) by using Debug to examine memory and change the character tables which translated the codes returned from the keyboard into ASCII characters. The tables were quite recognisable in a hex dump. Then I upgraded to DOS 3.2 and tried to do the same thing. The tables were still there but no longer used recognisable representations for the characters... It wasn't that we weren't willing to have a go - it is just that it became soooo time-consuming trying to figure out what was going on.
I suppose it helped that computers were more of an end in themselves, rather than just a tool at the time. I got a chance to dust off that ancient knowledge today resurrecting a printing press console that ran DOS on a screaming 386SX16 Pilz industrial computer that was past it's prime. They estimated $5k to repair so, when I quit laughing, I rehosted it on a brand new 3Ghz P4 IBM Think Centre (still has a serial port) with a 15" LCD monitor for a total of about $600. I had to mess with the system files and revector the serial port to COM2. I even had to play some keycode games because the DOS was a German version. Sort of overkill to the max to run that old DOS application, but it all works, runs fine and uses less power.
Check out this product from Intelligent Instrumentation
I have had a system running Win2K SP4 with no keyboard or mouse now for 3 years. Plant power failures (2) were the its only reboots. I monitor the system thru Famatech's Remote Administrative software. The system runs a MySQL database service and a VB6 winsock client program for three QSI Touch Panels.