While trying to make TASM and MASM samples for SolOs Applications
What can i make to convince TASM and MASM to accept this:
I need it to assemble into:
as opposed to what i get:
Must be something very simple that i am missing ?
Neddless to say that NASM and FASM samples work as intended ;)
What can i make to convince TASM and MASM to accept this:
API_Window_Create EQU 1000h
...
mov eax,[API_Window_Create]
I need it to assemble into:
mov eax,[100h]
as opposed to what i get:
mov eax,1000h
Must be something very simple that i am missing ?
Neddless to say that NASM and FASM samples work as intended ;)
It works with ds:
API_Window_Create EQU ds:1000h
...
mov eax,
API_Window_Create EQU ds:1000h
...
mov eax,
unfortunately this way i get :
mov eax,
but i need:
mov eax,
mov eax,
but i need:
mov eax,
How about...
mov eax,DS:
compiles as...
A1 00 10 00 00
mov eax,DS:
compiles as...
A1 00 10 00 00
Well it works like this
But unfortunately i think this is more clear and safer:
At least now i know why i have to finish my own assembler :grin:
i just do not get it what was in the mind of those assemblers developers when they assume that
somehow translates to simply number and not ?
Besides they assume a word value in a 32bits segment or worst inside a 32 bits model... and i have to use LARGE... doh things seemed to work so nice in Windows :P
mov eax,ds:[LARGE API_Window_Create]
Call eax STDCALL,0,32,32,300,200,0,WND_TYPE_TOP
But unfortunately i think this is more clear and safer:
mov eax,API_Window_Create
mov eax,[eax]
Call eax STDCALL,0,32,32,300,200,0,WND_TYPE_TOP
At least now i know why i have to finish my own assembler :grin:
i just do not get it what was in the mind of those assemblers developers when they assume that
somehow translates to simply number and not ?
Besides they assume a word value in a 32bits segment or worst inside a 32 bits model... and i have to use LARGE... doh things seemed to work so nice in Windows :P
I know TASM needs LARGE/SMALL, but MASM doesn't have those keywords. A little adjustment I had to make when I ported some TASM Win32 code to MASM.
Well i do not dislike LARGE / SMALL so much... because i guess I could move that to the EQUs , anyway i would have been normal to consider values as 32 bits in a 32 bits segment and 16 bits in a 16 bits segment ... eh...
But what I dislike a lot is the "ds:" reference ... again that is default... so whay do i have to say that either?
Well such is life ;) i guess i will live
Yet another problem is:
How to easy make (binary) position independent code?
Now i can call my API from binarys of some assemblers out there... but i have no idea where the OS will load that binary image :D and considering this how will have access to applications variables ?
But what I dislike a lot is the "ds:" reference ... again that is default... so whay do i have to say that either?
Well such is life ;) i guess i will live
Yet another problem is:
How to easy make (binary) position independent code?
Now i can call my API from binarys of some assemblers out there... but i have no idea where the OS will load that binary image :D and considering this how will have access to applications variables ?
Not sure I totally understand what you are going for, but this works:
API_Window_Create TEXTEQU <ds:[1000h]>
mov eax,
00401056 A1 00 10 00 00 mov eax,dword ptr ds:[00001000h]
API_Window_Create TEXTEQU <ds:[1000h]>
mov eax,
00401056 A1 00 10 00 00 mov eax,dword ptr ds:[00001000h]
How to easy make (binary) position independent code?
I dont understand, are you questioning how you make relocation bits? if that, you wioll need a loader that check the address that need be relocated when you whant load a programm. Pherhaps?.
Have a nice day or night.
afaik, you're using some kind of "emedded application"-style for your kernel. is it still like this? or do you now want to load the programs dynamically?
in the first case, it sould be no problem as you have to compile the kernel (with all its labels, code and data) completely new.
in the other case, you'll have to allocate space, which will be in a different location every time. you could create a new selector for each program (a data-selector too), which is loaded. now, the location always starts with cs:00000000 and it's kinda independent. unfortunately, you're limited to 8192 selectors...
greets, hartyl
in the first case, it sould be no problem as you have to compile the kernel (with all its labels, code and data) completely new.
in the other case, you'll have to allocate space, which will be in a different location every time. you could create a new selector for each program (a data-selector too), which is loaded. now, the location always starts with cs:00000000 and it's kinda independent. unfortunately, you're limited to 8192 selectors...
greets, hartyl
heh, that thiny with your
won't be easy then... damn. - not only the mov, but also the call....
mov eax, [API_Create_Window]
call eax
won't be easy then... damn. - not only the mov, but also the call....
hartyl,
The "Call eax" stuff will be just fine because the PAI table is fixed starting at 1000h going upwards ;)
The real problem is while accessing variables ;)
I use the delta trick to get the location of the loaded executable and offset each memory variable with this value at runtime (or other relocable items) ...
Some sample for a set I am preparing:
So yes the old style kernel embeded application is there (to stay) as it best suites small engines or appliances without HDD/CD etc. It is also good for drivers and applications/services that are surely going to be needed and/or always running.
But i also want to make external ("dynamic") loading applications .. and in fact i have sucessfully done this already. Of course i have some "minor" problems as you migth have seen in above discussions...
I also think i will have to code my own assembler / relocator / loader to solve this more elegantly.
Some segmentation + callgates might also work esp for sndboxing applications.
But using the delta trick and manually offseting variables will work also... for the time beeing :D
I am preparing samples for: TASM,MASM,NASM and FASM
The "Call eax" stuff will be just fine because the PAI table is fixed starting at 1000h going upwards ;)
The real problem is while accessing variables ;)
I use the delta trick to get the location of the loaded executable and offset each memory variable with this value at runtime (or other relocable items) ...
Some sample for a set I am preparing:
;================================================
;
; SolOS TASM Sample 2:
; -Creates a translucent window
; -Setup a caption
; -OS will deal with move/resize/close
;================================================
.386p
LARGESTACK
LOCALS
.model flat,stdcall
.code
Start:
nop
Start1 PROC STDCALL
LOCAL @@app_addr:dword
LOCAL @@wnd_handle:dword
;--------------------------------
;save base pointer on stack ;)
;on entry esi=app base offset
;--------------------------------
mov [@@app_addr],esi
;-------------------------------
; Create the Window
;-------------------------------
mov eax,API_Window_Create
mov eax,[eax]
Call eax STDCALL,0,32,32,300,200,0,WND_TYPE_TOP
mov [@@wnd_handle],eax
;---------------------------------------------------
; we have to offset global variables with app base
; this limits our movement a little ...
; hopefully a loader / relocator will fix this
;---------------------------------------------------
mov edi,offset sz_tasm_sample
add edi,[@@app_addr]
;--------------------------
;Set caption
;--------------------------
mov eax,API_Window_Set_Caption
mov eax,[eax]
Call eax STDCALL,[@@wnd_handle],edi
;-----------------------------
; finish app initialization
;-----------------------------
mov eax,0
ret
ENDP
.data
sz_tasm_sample db "TASM App Sample_02",0
include ../include/sol_tasm_inc.asm
end Start
So yes the old style kernel embeded application is there (to stay) as it best suites small engines or appliances without HDD/CD etc. It is also good for drivers and applications/services that are surely going to be needed and/or always running.
But i also want to make external ("dynamic") loading applications .. and in fact i have sucessfully done this already. Of course i have some "minor" problems as you migth have seen in above discussions...
I also think i will have to code my own assembler / relocator / loader to solve this more elegantly.
Some segmentation + callgates might also work esp for sndboxing applications.
But using the delta trick and manually offseting variables will work also... for the time beeing :D
I am preparing samples for: TASM,MASM,NASM and FASM
hm, i don't know if there's a better way, but currently your solution doesn't seem "elegantly" to me...
i thought of a different version i'm not sure about, if it works. but read on:
the kernel has a code- and a data-segment for the code itself and the stack - these are only used for the kernel.
every dynamically loaded app will get its own selectors as well. when it comes to accessing global vars, the app might use the code-selector of the kernel.
this way, an app should be completely independent, i think.
btw, both ways (yours as well) don't seem to involve that much security, does it? every app could just modify the api-vectors in order to "hook" em - have you thought about it? or is security no main aspect of your project (i respect that, i also don't put that any high...)
i thought of a different version i'm not sure about, if it works. but read on:
the kernel has a code- and a data-segment for the code itself and the stack - these are only used for the kernel.
every dynamically loaded app will get its own selectors as well. when it comes to accessing global vars, the app might use the code-selector of the kernel.
this way, an app should be completely independent, i think.
btw, both ways (yours as well) don't seem to involve that much security, does it? every app could just modify the api-vectors in order to "hook" em - have you thought about it? or is security no main aspect of your project (i respect that, i also don't put that any high...)
Yeah,
I agree that is not very "elegant"... i am still searching other solutions but for now this will do, and i do not know if there is another solution after all... yes your ideea should work also... but it breakes out of the flat memory model :D so i will implement that also but using segments to separate applications it is not too high on my list
Security?
This reminds me of a guy(or a girl) with a gun and some encryption for HDD files and a password to lock computer down... and a race that dreams it has evolved in other ways but technical.
Protection?
Well i curently do not care for this paranoia of protetcing every time against every application at runtime. So it is my design option to value sharing speed and cooperation much more than protection, separation, and paranoia. For one thing protection never really worked and it might never work in modern OS because of speed issues
For reference: it is my intention to make a super tight protected SolOS version, just for beeing able to compare the 2 options (no protection versus super tight protection) in almost the same environment/OS...and to help protection lovers... but again not high on my list. And indeed on this issue the segmentation+ring protection even if slow and complicated it is inexpugnable also.
However in my view of protection i will provide a sandbox for developing/debugging and testing applications, or for users to check if an application can be included in a "circle of trust"... after that the application could be moved inside the circle and need no more useless checking at each run / time .
Yes i have thought about it... but for SolOS applications to be able to hook API calls and to be able to share and to be able to fully use hardware (ports etc) without restrictions and in full conscience is very important and an design option.
I agree that is not very "elegant"... i am still searching other solutions but for now this will do, and i do not know if there is another solution after all... yes your ideea should work also... but it breakes out of the flat memory model :D so i will implement that also but using segments to separate applications it is not too high on my list
Security?
This reminds me of a guy(or a girl) with a gun and some encryption for HDD files and a password to lock computer down... and a race that dreams it has evolved in other ways but technical.
Protection?
Well i curently do not care for this paranoia of protetcing every time against every application at runtime. So it is my design option to value sharing speed and cooperation much more than protection, separation, and paranoia. For one thing protection never really worked and it might never work in modern OS because of speed issues
For reference: it is my intention to make a super tight protected SolOS version, just for beeing able to compare the 2 options (no protection versus super tight protection) in almost the same environment/OS...and to help protection lovers... but again not high on my list. And indeed on this issue the segmentation+ring protection even if slow and complicated it is inexpugnable also.
However in my view of protection i will provide a sandbox for developing/debugging and testing applications, or for users to check if an application can be included in a "circle of trust"... after that the application could be moved inside the circle and need no more useless checking at each run / time .
Yes i have thought about it... but for SolOS applications to be able to hook API calls and to be able to share and to be able to fully use hardware (ports etc) without restrictions and in full conscience is very important and an design option.