Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |
| en:demo [2013/05/18 19:34] – adm | en:demo [2014/06/06 23:53] (current) – valerius |
|---|
| ==== osFree demo CD (some technical details) ==== | ==== osFree demo CD (some technical details) ==== |
| |
| We have uploaded our new [[downloads:osfree-demo-0.0.4.1.zip|osFree ISO image 0.0.4.1]]. Since the previous [[downloads:osfree-demo-0_0_4.zip|osFree ISO image 0.0.4]], it has some advancements. For example, the previous setup used a small 500-byte executable, which used only one OS/2 API function – DosPutMessage, imported from a single msg.dll (which is a forwarder to doscalls.dll), the new setup includes a bigger minicmd.exe LX executable (9 kilobyte in size), which uses more OS/2 API's. | We have uploaded our new {{downloads:osfree-demo-0.0.4.1.zip?nocache|osFree 0.0.4.1 ISO image}} Since the previous {{downloads:osfree-demo-0_0_4.zip?nocache|osFree ISO image 0.0.4}}, it has some advancements. For example, the previous setup used a small 500-byte executable, which used only one OS/2 API function – DosPutMessage, imported from a single msg.dll (which is a forwarder to doscalls.dll), the new setup includes a bigger minicmd.exe LX executable (9 kilobyte in size), which uses more OS/2 API's. |
| |
| It must be noted, that these executables still have no thunks for calling 16-bit API's. For that, we use our own invention, sub32.dll, which stands for “VIO/KBD/MOU 32-bit Subsystems”. This DLL is treated a special way by our LX loader – an executable is linked against EMXWRAP.DLL, which is a 32-bit wrapper over VIO/KBD/MOU 16-bit API's, taken from EMX. This way gcc compiler and other GNU packages can work with only 32-bit API's, and do not use 16-bit ones. The same way, we use 32-bit API's only. But when our LX loader sees the reference to EMXWRAP module, it resolves this reference by linking with SUB32. So, SUB32.DLL is a kind of EMXWRAP alias. Our L4 implementation of OS/2 API, in our demo, runs a mincmd.exe test executable, linked with SUB32 and DOSCALLS, whereas on IBM's OS/2, it depends on EMXWRAP.DLL from EMX runtime. But when EMX EMXWRAP.DLL wraps 16-bit API's by 32-bit ones, osFree SUB32 is a real 32-bit implementation, which does not depend on 16-bit API's. | It must be noted, that these executables still have no thunks for calling 16-bit API's. For that, we use our own invention, sub32.dll, which stands for “VIO/KBD/MOU 32-bit Subsystems”. This DLL is treated a special way by our LX loader – an executable is linked against EMXWRAP.DLL, which is a 32-bit wrapper over VIO/KBD/MOU 16-bit API's, taken from EMX. This way gcc compiler and other GNU packages can work with only 32-bit API's, and do not use 16-bit ones. The same way, we use 32-bit API's only. But when our LX loader sees the reference to EMXWRAP module, it resolves this reference by linking with SUB32. So, SUB32.DLL is a kind of EMXWRAP alias. Our L4 implementation of OS/2 API, in our demo, runs a mincmd.exe test executable, linked with SUB32 and DOSCALLS, whereas on IBM's OS/2, it depends on EMXWRAP.DLL from EMX runtime. But when EMX EMXWRAP.DLL wraps 16-bit API's by 32-bit ones, osFree SUB32 is a real 32-bit implementation, which does not depend on 16-bit API's. |
