OS/2, eCS & ArcaOS - Technical > Programming
native mainframe mini-clone
kerravon:
--- Quote from: Lars on September 14, 2025, 11:25:10 am ---You might want to have a look at:
https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/system/drivers/misc/SysCall_3-0.wpi
That is a package that I have written to run code in Ring 0.
It comes with full source code. Which would allow you to adapt/extend it to your needs.
The idea was to have an interfacing DLL to be used by an application. That DLL will return to the caller an entry point that will allow the caller to execute user functions in Ring 0.
It uses the syscall/sysret instructions as the fastest way to enter Ring 0.
--- End quote ---
Looks exactly what I need - thanks!
There are some competing priorities for what I should do next though - a strategy for this being the most interesting at the moment:
https://gcc.gnu.org/pipermail/gcc/2025-September/246666.html
(I need a solution different from the x32 solution which I now know is 0x67 override)
Lars:
Correction: it is sysenter/sysexit that is used and not syscall/sysret.
For exactly this reason: only sysenter/sysexit are available in x32 for both, Intel and AMD. The interfacing DLL/the Syscall device driver makes no attempt whatsoever to switch from x32 to x64. Everything remains in x32 mode.
For syscall/sysret it is more complicated. I think for Intel it only works for x64 (long mode) (or was it AMD ? I cannot remember ...)
kerravon:
--- Quote from: Lars on September 15, 2025, 09:43:01 am ---Correction: it is sysenter/sysexit that is used and not syscall/sysret.
For exactly this reason: only sysenter/sysexit are available in x32 for both, Intel and AMD. The interfacing DLL/the Syscall device driver makes no attempt whatsoever to switch from x32 to x64. Everything remains in x32 mode.
For syscall/sysret it is more complicated. I think for Intel it only works for x64 (long mode) (or was it AMD ? I cannot remember ...)
--- End quote ---
Hi Lars.
I'm not sure if you've used the wrong terminology or I'm just confused.
x32 is a target of gcc. I'm not very familiar with it, but I believe it uses x64 instructions, but 32-bit addresses. And it does the latter (as I just found out) by using 0x67 override (which isn't appropriate if you were really running in x86 mode).
So this is very different from x86, and that's why the different target exists. ie it isn't i386.
What you described above sounds like you are describing x86 (aka i386 aka 80386).
Lars:
--- Quote from: kerravon on September 21, 2025, 09:45:53 am ---
--- Quote from: Lars on September 15, 2025, 09:43:01 am ---Correction: it is sysenter/sysexit that is used and not syscall/sysret.
For exactly this reason: only sysenter/sysexit are available in x32 for both, Intel and AMD. The interfacing DLL/the Syscall device driver makes no attempt whatsoever to switch from x32 to x64. Everything remains in x32 mode.
For syscall/sysret it is more complicated. I think for Intel it only works for x64 (long mode) (or was it AMD ? I cannot remember ...)
--- End quote ---
Hi Lars.
I'm not sure if you've used the wrong terminology or I'm just confused.
x32 is a target of gcc. I'm not very familiar with it, but I believe it uses x64 instructions, but 32-bit addresses. And it does the latter (as I just found out) by using 0x67 override (which isn't appropriate if you were really running in x86 mode).
So this is very different from x86, and that's why the different target exists. ie it isn't i386.
What you described above sounds like you are describing x86 (aka i386 aka 80386).
--- End quote ---
Correct. The system stays in "protected 32-bit" mode, aka x86. It does not change to long mode.
kerravon:
--- Quote from: Rich Walsh on September 13, 2025, 01:15:54 am ---You would need a device driver which operates at Ring 0. In the UEFI version of ArcaOS, the bootloader stub which remains after the OS is running will switch to long-mode to read the machine's NVRAM variables, then will switch back. While doing so, all of OS/2 must stop because it is 100% *incompatible* with long-mode. Why? Because the kernel and device drivers are all 16-bit code, and the flag that signals "16-bit code" on an x86 signals "64-bit code" when long-mode is enabled. You can have 16/32 code or 32/64 code but not 16/32/64.
--- End quote ---
I think you might have been misinterpreted, and you are in fact correct, but could you please answer the below?
https://bttr-software.de/forum/board_entry.php?id=22728
That’s what I thought, but it is incorrect. Long mode can deal with all three code segment sizes at the same time, as indicated by the very first table in the system programming volume of AMD’s architecture manual (“Operating Modes”). What you cannot have is VM86 mode. I verified PM16 on my current Linux installations last week (from a 32-bit task). One significant piece of functionality is missing, although this is just a limitation of Linux, not the machine architecture: having your own SIGSEGV handler intercept general protection faults from that 16-bit code segment. Unfortunately, the kernel does not understand this kind of code and will kill the faulting process directly instead of invoking its signal handler.
Thanks. Paul.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version