Jands Vista S3 and PC based consoles

[merlin24]

a maxxyz is windows XP under the hood, so, of course, is the vista in all its flavours

 

Just to correct you on that Vista itself is not embedded XP, it runs on Linux, so way more stable. The only element of XP would be if you were actually running VISTA PC from an XP machine, but don't forget you can also use a MAC. The software is available for both platforms.

 

Regards

Andy

[mac.calder]

And you really do have to remember that "Embeded XP" is a hell of a lot different to the XP that you install on your PC. Basically, a good programmer will only include the things that are needed to make the application interface with hardware and run the application - things like the TCP/IP stack, GUI, process management etc. It is not like they install bog standard XP, install their application and shove it into the startup menu.

 

It is a bit like why apple was (is) able to make a far more efficient system than your IBM compatable system, their software is designed and compiled to make use of the specific hardware (and all the special instructions) to a level that is impossible to do with a miss match system (like most IBM compats), without recompiling everything with appropriate optimisation etc.

 

Now I said as a general rule, a desk will be better than a PC, this is of course, assuming that the desk is the right sort for the application, and has been developed properly. Obviously, there are certainly some desks which do not meet acceptable standards.

[Tomo]

And you really do have to remember that "Embeded XP" is a hell of a lot different to the XP that you install on your PC. Basically, a good programmer will only include the things that are needed to make the application interface with hardware and run the application - things like the TCP/IP stack, GUI, process management etc. It is not like they install bog standard XP, install their application and shove it into the startup menu.

A friend of mine who develops for XP-Embedded tells me that it's nowhere near that simple - XP-E has a huge list of strange interdependancies, so things that appear to be unnecessary end up being forced into the compilation to make the bits you actually want work properly.

Unix-based operating systems (eg OS X and Linux) don't have that issue.

 

Which is why I always wonder why so many companies use XP-E. I don't see any real advantages to it, as the training to go from Win CE would have been similar to the jump to some flavour of Unix. Add to that the fact that Linux licences are free (support is not, and should not be free)...

I be confuzzled.

[mac.calder]

I have never played with embeded XP, I am a linux boy myself, so my small foray into the world of embeded systems covered embeded linux only (linux on my PDA)

[jfitzpat]

Which is why I always wonder why so many companies use XP-E. I don't see any real advantages to it, as the training to go from Win CE would have been similar to the jump to some flavour of Unix. Add to that the fact that Linux licences are free (support is not, and should not be free)...

I be confuzzled.

 

XP-E is, quite literally, XP. The only two significant differences are a duplication and distribution mechanism that vendors can use themselves and the ability to use a configuration builder to drop some portions of the system for image size.

 

The reason a company would use XP-E is if they are developing a larger application that is most useful in a turnkey package that is not especially price sensitive (like the Maxxyz).

 

The reasons to pick XP-E over Linux for many of these cases are pretty strong. Everything from 3rd party hardware and drivers to development tools and available developers leans pretty heavily towards XP. The primary reason that Linux gets selected for embedded applications is cost. Especially among developers not intimately familiar with the OS there is a perception that it is some form of free RTOS, which it is not.

 

Personally, I think that the cost benefit of Linux is a bit over estimated. Several studies seem to show that time to market runs longer on Linux based projects and that have a larger average team size. To my mind, the care-and-feeding of a group of software developers for even a single fiscal quarter can offset a lot of per unit license fees.

 

The idea that there is some inherent structural cleanness in Linux that there is not in XP-E is probably the result of not really understanding the pieces and architecture of both. Both kernels have demonstrated platform portability. The XP/NT kernel has also demonstrated Posix support, including compatible threads, signaling, and security. The XP/NT kernel was one of the first major attempts at a micro-kernel and fully embraced both layered drivers and an object interface. OS X provides very similiar functionality, however Linux does not (later versions of Linux do mimic some of the functionality, like a 'Virtual File System' but a kernel object model is not uniformly used).

 

Where your friend is probably confused is in the fact that only a small number of developers ever directly access the XP/NT kernel. Most work exclusively in 'application space' for the 'Win32 Subsystem'. This portion of the total OS is large, complex, and convoluted. Some of that undoubtedly comes from design, but a lot is also due to long success and legacy support. But complex interrelationships in a GUI subsystem is hardly limited to XP.

 

Remember, when most developers embed Linux, they include only the kernel. That is because the 'GUI' subsystems (X86Free is the most common) are enormous, a bit slow, and complex. If a developer were to try to pick and choose features from one of these subsystems they would find tons of mysterious interelationships. The typical path for the unititiated is: A) find out X86 is too big for the target, B) find out what 'written by a mob with no real plan' really means and waste considerable amount of time trying to lighten X86 (or one of the other free GUIs), then C) buy one of the smaller commercial GUI packages and learn yet another GUI 'api'...

 

Frankly, I'm pretty much an OS agnostic. Having watched processors, languages, and OS's come and go I've reached the point where they are just tools to me. Some are better suited than others for the job at hand, but none are typically the reason that a product fails to deliver.

 

I actually see controllers somewhat along the same lines. Like American baseball player Barry Bonds said when other players started mimicing his use of maple wood bats, "It's the warrior, not the weapon." Some of my best lighting ever was operated on toggle switches, wearing gloves so I wouldn't get shocked no less. Like all controller manufacturers we try to build tools that help 'warriors' get the job done more easily. But, at the end of the day, I don't think the controller makes or breaks the show.

 

-jjf

[BlueShift]

I have to agree jfitzpat. I do think though, particularly in our case, where we want to achieve moderately complex looks with mostly inexperienced operators that our choice of console can dramatically influence whats practically possible.

[Liam FitzG]

Afternoon,

I am not a fan of windows based machines. I've operated in the region of two thousand performances and the only machines that have ever given me hassle to any great extent were the ones running on windows. From the lightwave research desk running Win3.1 (which I lost an entire days programming on 30 mins before curtain) to the Maxxyz which I had for ten minuets before I was looking at a XP screen. Granted the Maxxyz was two years ago and they are meant to be tougher now. But I have never crashed out into DOS or UNIX in a desk.

 

And for what it's worth I would put a 300 in the church, maybe with a graphics tablet for the more complex movers busking shows.

 

Liam