Similar to the CE5 kernel that we're used to, the CE7 kernel is a 32 bit OS and runs a 4GB Virtual Address space. Similar to CE5, 2GB is reserved for the kernel and 2GB is reserved for user space.
This is where it begins to differ. CE5 handled the user space by splitting the process memory up into 32 slots of 32MB each. (This accounts for 1GB of user space, the rest is used for memory mapped files, fixed up modules, etc.) Any app currently in the foreground was swapped into slot 0 during execution, and swapped back into it's slot while it's backgrounded.
CE7 similarly uses 1GB for the process code, however now it's handled differently. Each running process is mapped to the entire 1GB space, allowing the full 1GB of VM available for use without the trickery needed to accomplish using more than 32MB of VM in CE5. This should allow for much more rich apps to be developed (whenever MSFT decides to allow us to write native code, which is coming at some point...)
This 1GB VM space will be dedicated to the process, and not accessible by any other process. The remaining 1GB of user space has to be utilized for inter-process memory sharing.
There are 256 priority levels as with CE5, for each individual thread within an app. Scheduling is handled on a round-robin basis for threads sharing the same priority level. Priority level 0 functions as a "real time" priority level and any thread running at this level will run through til completion before the scheduler runs another thread. True multitasking will not be accessible to programmers initially, though MSFT intends to unlock that later down the line (presumably around the time native code is allowed). There is no hard limit to the number of threads a program can utilize, it is only limited by the system resources available.
Regarding the limited APIs available to us "normal" programmers - OEMs and MOs will have access to an extended set of Managed APIs and a limited set of Native APIs that "normal" programmers won't get access to. This likely includes things like RIL.
This is where it begins to differ. CE5 handled the user space by splitting the process memory up into 32 slots of 32MB each. (This accounts for 1GB of user space, the rest is used for memory mapped files, fixed up modules, etc.) Any app currently in the foreground was swapped into slot 0 during execution, and swapped back into it's slot while it's backgrounded.
CE7 similarly uses 1GB for the process code, however now it's handled differently. Each running process is mapped to the entire 1GB space, allowing the full 1GB of VM available for use without the trickery needed to accomplish using more than 32MB of VM in CE5. This should allow for much more rich apps to be developed (whenever MSFT decides to allow us to write native code, which is coming at some point...)
This 1GB VM space will be dedicated to the process, and not accessible by any other process. The remaining 1GB of user space has to be utilized for inter-process memory sharing.
There are 256 priority levels as with CE5, for each individual thread within an app. Scheduling is handled on a round-robin basis for threads sharing the same priority level. Priority level 0 functions as a "real time" priority level and any thread running at this level will run through til completion before the scheduler runs another thread. True multitasking will not be accessible to programmers initially, though MSFT intends to unlock that later down the line (presumably around the time native code is allowed). There is no hard limit to the number of threads a program can utilize, it is only limited by the system resources available.
Regarding the limited APIs available to us "normal" programmers - OEMs and MOs will have access to an extended set of Managed APIs and a limited set of Native APIs that "normal" programmers won't get access to. This likely includes things like RIL.
Last edited:
