Et Windows XP embedded?

Citation :
Ben ecoute j'ai vu tourner XP sur un terminal avce meme pas 128 de RAM,

Citation :
Ce n'est pas un windows classique, il n'a pas toutes les fonctionnalités et son architecture est très fermée vu que normalement c'est destiné au marché de l'informatique embarquée et pas au marché du pc.

Citation : Mais tu peux oublier pour la zik quand même: embarqué ici = RT (real time, temps réel), et entre autre... Les drivers doivent être totalement repensés. Par exemple, un système temps réel "dur" doit assurer qu'un truc prendra pas plus qu'un certain temps donné. Sur windows, aucune garantie que ton truc va pas prendre 10 ans au lieu d'une seconde. Le temps de latence entre une interruption et sa gestion est pas prévisible, je crois, sous windows, alors qu'il l'est sur XP embedded.

Citation : Bref, c'est comme pour linux: t'es baisé, si tu prends l'option RT, ça veut dire de nouveaux drivers.

Citation : meme pas 128 de RAM

Citation :
Euh j'ai pas bien saisi la mais bon ...

Citation :
Software causes of latency
A switch from Windows XP to RTSS happens on an interrupt, either from the RTX high-speed clock or from another device generating RTX interrupts. Therefore, achieving RTX ISR determinism requires reducing Windows XP interrupt latency. Let us examine the sources of Windows XP platform ISR latencies without RTX present.

The most significant latency is IRQ masking by the Windows XP kernel and drivers, routinely done for periods up to several milliseconds through Windows XP KeRaise/LowerIrql calls. The Windows XP kernel, HAL, and certain special drivers also perform processor-level masking of all interrupts through x86 STI/CLI instructions, for periods of up to several microseconds.

Windows XP and RTX interrupt processing naturally, masks interrupts, thereby adding to ISR latency. Although Windows XP relies very heavily on interrupts in many situations (for example, raising software exceptions or unwinding a thread's stack), the Windows XP interrupt sequence is reasonably compact in its contribution to the worst-case ISR latency.

Hardware causes of ISR latency
The most obvious hardware-related problem is cache dirtying and flushing by applications and the operating system. This category also includes refilling of the TLBs. Video drivers are particularly aggressive users of caches, causing contention-related flushes when an RTX interrupts starts running. Histograms of ISR behavior in the presence of cache-dirtying applications would typically have a double-hump profile, with most samples near the best-case band, and another large number of samples in the flushing-related band (see Figure 3).

Power management, especially on portable devices, creates occasional long-latency events when the CPU is put in a low-power-consumption state after a period of inactivity. Such problems are usually quite easy to detect. A typical system can disable those features through basic input/output system (BIOS) setup.

Some systems, again typically notebooks, use the Pentium processor's System Management Mode (SMM) to perform specialized keystroke or other processing in BIOS firmware. While in SMM, the processor does not field interrupts that adds to ISR latencies.

Fortunately, new generations of system platforms, starting with Advanced Configuration and Power Interface (ACPI) platforms and Windows 2000, use the operating system and not BIOS to provide power management. As a result, these sources of latency are now minimal.

Bus mastering events can cause long-latency CPU stalls. Such cases include high-performance DMA small computer system interface (SCSI) devices, causing CPU stalls for periods of many microseconds, or video cards that insert wait cycles on the bus in response to a CPU access. Sometimes the behavior of such peripherals can be controlled from the driver, trading off throughput for lower latency.

Although no operating system can protect an application against such hardware factors, RTX offers tools to diagnose platform-related latencies, and to identify the misbehaving peripherals. Being mindful of such factors and using RTX tools to qualify one's development platform are essential for a system's overall performance.