Mike Hall on Choosing Embedded Linux over Windows

prostoalex writes "Mike Hall from Microsoft asks the audience why they would choose Linux over Microsoft for embedded projects. He provides a point-by-point description of benefits of Microsoft's products (Windows CE and Windows XP Embedded) and points out that starting out on Windows-based embedded platform might save development and testing time."

Comments

Re:OT Unix - like OS

[greed]

I think the important things about UNIX, aside from having the same libc.a APIs everywhere, is the filesystem.

To have a UNIX-like system, you need:

1. Single filesystem tree
2. Transparent mounting of filesystems into the tree
3. "Everything is a file" approach, all I/O types use the same APIs; so you only need special code for doing special things. (So "cat" can read from magnetic tape, raw disk, or a FIFO; but if you want to rewind the tape, you need a program that knows about it.)
   • Regular files
   • Directories
   • Sockets (TCP, UNIX, NetBEUI, AppleTalk, IPX/SPX--the difference is only in the names you use to open them)
   • FIFOs
   • Device-specials
4. fork(2)/exec(2)/wait(2) process model
5. "File mode" permission model (something that can be done with bitmasks), as opposed to an "Access Control List" model. (ACLs are available on many UNIXes, but very few programs support them. The OS still enforces them, but (say) "cp" won't preserve the ACL unless you update it.)

With those basic attributes, most batch UNIX programs stand a fair chance of working well.

I've worked on systems which implement only a few of them. Porting a UNIX combined file-and-network program to Windows is a massive pain, because the TCP sockets are not in the same identifier-space a s file handles--so you need to handle them separately. Similarly, any system which doesn't have "fork()" means you have to re-write all your co-processing code. AS/400's POSIX interface is particularly misleading--even more so than Windows. On Windows, you can at least run Windows .exe files fairly normally from the POSIX API; but on OS/400, non-POSIX stuff just doesn't work right (or didn't, back in 1997 when I last had to deal with it).

Even when there seems to be a good alternative, it may not work out well after all. So you can't fork()/exec() on Windows... well, so what, you just want to run a program and wait for it to exit, right? So spawn() is good enough, or CreateProcessEx() if you want more control.

But, launching a new process is very expensive on Windows; a make or shell program will be 10x to 100x slower on Windows than on a UNIX-ish system running on the same machine. When you write native Windows applications, you just don't code that way--you use threads, you use DLLs, you do everything you can in the same process image. You do NOT run external programs if you can help it. (You can, of course, do this on UNIX too if you like; but you don't have to....)

So even having [part of] the interface isn't going to save your code--if your application uses features which aren't handled well, or are simulated, it's going to suck on that system.