ghaerr
Restore or drop the i286 protected mode
I had some success running an application compiled for ELKS in protected mode. Actually ELKS is designed so all user application can run in protected mode as well. Independent of kernel internals all application must follow a very clean userland implementation, dont use privileged operation that modifies kernel state. In that way it would be a nice to have if the CPU actually can check that at runtime.
The main reason is that architecture wise I like that clean separation between kernel, priviliged operations and user code. So for educational reasons it is much easier to work on and demonstrate ELKS code. That may be one of the strong points for future use of ELKS.
The builder of the 386 had similar idea in their mind. We can leave everything as it is keep the kernel in a V86 environment and move user task into their own address space. We can keep even the 16-bit segment and pointer limitations.
Would it still be allowed to think of protected user tasks?
Hello @anchorz,
Are you talking about running applications on ELKS that execute their own code to change in and out of 286 protected mode, or instead desiring the enhancement that the ELKS kernel prepares a 286 protected mode (or 80386 V86 mode) environment before running the ELKS application?
Also, which compiler / linker development environment are you using?
Either approach will be quite complicated, but wanted to understand your request before commenting further.
Thank you!
