Im experimenting using syslinux creating a program that start on PMode, the problem is, I used interupt for the hardware use, I switch to realmode and back. Do you think it is slower than using the I/O Port?
Yes, it's slower.
You can do I/O directly from p-mode once you set up the process' port mask.
Of course, that requires you to then write a proper driver and not rely on BIOS.
I had a kernel32.dll from RTOS I want to load it, do you know how to do that?
Or maybe, you can point me to I/O interface reference, I hope it standard on every computers.
Oh on the source code I got a code like this
call far ptr 0:53h
I dont know what is that mean. That code was executed on the protected mode from the RTOS kernel. I never know that selector 0 is able to be used. But what is the 53h mean? I saw that every function is defined as, 01h,02h,033 ... etc. How can it point to an IP address where the different is only 1 byte?
must be an ordinal - somewhat similar to resource ordinals
the actual code address is probably stashed away in some table
As far as I know "call far ptr 0:53h" is 16-bit code. For 32-bit code I believe you would need to use fword in place of far.
Quote from: Farabi on October 10, 2011, 12:57:19 PM
I had a kernel32.dll from RTOS I want to load it, do you know how to do that?
Or maybe, you can point me to I/O interface reference, I hope it standard on every computers.
Most likely it will only work within the same environment provided by RTOS, so you probably can't just rip it out and start using it.
You'll have to be more specific what you mean by I/O Interface - the in and out instructions are the I/O interface, but I presume you want something more high-level.
Quote
Oh on the source code I got a code like this
call far ptr 0:53h
I dont know what is that mean. That code was executed on the protected mode from the RTOS kernel. I never know that selector 0 is able to be used. But what is the 53h mean? I saw that every function is defined as, 01h,02h,033 ... etc. How can it point to an IP address where the different is only 1 byte?
You're right, trying to use the null selector would cause an exception - so I'd have to assume it's actually real-mode code. And it references a vector that contains the actual pointer of the function to be called (though it's strangely at an odd address - unless you just made this example up?) The first value is the segment, so the difference isn't 1, it's 16 -- 02h:20h would be (02h*10h)+20h=40h
I think you have a lot of theory to read up on :wink
On the Kernel it had a null terminated string function. When I just call it without setting the base image it work, but when I set the segment to the base image it did not come back to my program. Should I really set the selector to the base image? Or just leave the base image?
Also I got code like this
;The base image is 7C900000
; And the function is located at 7C901207
; I saw this
Mov ecx, ds:7C901207
; It obviously it loaded the function location to ecx using the selector that had a base address
push bla
push bla
call ecx
add esp,8
I tried the same thing but failed, but when I used it like this, it worked
base equ 7C900000
mov ecx,7C901207
sub ecx,base
push bla
push bla
call ecx
sub esp,8
Should I just ignore the base address?
OK, so I decided to ignore the base image and it worked. Now I loaded another dll and it need an import table, should I just load the import table without the image address or what?
The base is the address at which you load the image. If you load it at an address other than the one specified, you'll need to 'fixup' all of the absolute offsets. For a simple string function this won't matter because the offsets will be relative, for other functions it will.
The import table will give pointers to functions in other modules - that should also have been loaded correctly first. This is part of the OS environment I mentioned, which means you can't just rip a dll from one OS and start using it on a completely bare system.
As I've already said, you have a lot of theory to read up on. Add the PE specification to this list.
Okay Thanks tedd, Im on it.
Anyway, do you know what this opcode mean?
9A 7B 00 00 00 02 00
The mnemonic is:
call far ptr 0:7Bh
What was the 0x02 used for?
IS it the same like?
mov ax,2
mov ds,ax
mov eax,7bh
call dword ptr ds:[eax]
?? Because I got the GDT and the IDT table.
I saw on the source he coded it manualy using a macro, and then set the value on the fly. Damn. It make things difficult, and on the lisence agreement he said it was free for any purpose. :green
For your concern, Im not doing anything ilegally http://www.rdos.net/rdos/ here is the source. I did not dissasmbling any MS Kernel, anyway, with that MS OOP coding style, I rather kill my self :lol
Debug assembles:
call far ptr 0:7b
To:
9A7B000000
And this agrees with the Intel reference for CALL ptr 16:16 (call far, absolute, address given in operand)
But it was had 02 00 behind it. Maybe it was the 0x20 selector table, I know what table it was.
Anyway, I got the import table with the name list, should I just replace the address with another address from another dll it want to import? I got too many error, but some are worked. Late or soon I will figuring it out, but it worth to ask. Save some time.