While trying to make TASM and MASM samples for SolOs Applications

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 ;)
Posted on 2004-05-29 05:39:16 by BogdanOntanu
It works with ds:

API_Window_Create EQU ds:1000h
...

mov eax,
Posted on 2004-05-29 06:32:17 by Dr. Manhattan
unfortunately this way i get :

mov eax,

but i need:

mov eax,
Posted on 2004-05-29 14:03:22 by BogdanOntanu
How about...

mov eax,DS:

compiles as...

A1 00 10 00 00
Posted on 2004-05-29 14:20:19 by donkey
Well it works like this



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
Posted on 2004-05-29 15:47:40 by BogdanOntanu
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.
Posted on 2004-05-29 19:26:29 by tenkey
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 ?
Posted on 2004-05-30 07:41:43 by BogdanOntanu
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]
Posted on 2004-05-30 15:01:02 by ThoughtCriminal
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.
Posted on 2004-05-30 16:03:30 by rea
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
Posted on 2004-05-31 13:44:55 by hartyl
heh, that thiny with your


mov eax, [API_Create_Window]
call eax


won't be easy then... damn. - not only the mov, but also the call....
Posted on 2004-05-31 13:53:20 by hartyl
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:



;================================================
;
; 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
Posted on 2004-05-31 16:53:44 by BogdanOntanu
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...)
Posted on 2004-06-01 13:50:13 by hartyl
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.
Posted on 2004-06-09 21:42:51 by BogdanOntanu