 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle nous apporta ses lumieres en ce 2007/11/30 16:35:
> Orchid XP v7 wrote:
>> I'm just being nosy now... How do you call OS functions on Windoze?
>>
>>
>> Back in the days of the Commodore 64, the "operating system" (I use
>> the term loosely) was stored in a big ROM chip. To call the OS
>> (assuming you actually wished to do such a thing!) you simply jump to
>> the right magic address. Since it's in ROM, it never moves. And
>> indeed, you could buy big tables of addresses and the expected
>> parameters...
>
> Commodore released a manual for the C64 that had EVERYTHING about the
> machine, including schematics. It contained everything you needed to
> write any application.
>
Apple did the same with the Apple ][. In fact, one of the included manuals
included the source code of the ROM and the scematics. Still have them.
There where also several third party sources for much of what's in the Applesoft
basic ROM.
--
Alain
-------------------------------------------------
A true friend is someone who reaches for your hand and touches your heart.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 wrote:
> Warp wrote:
>> Orchid XP v7 <voi### [at] dev null> wrote:
>>> How does this stuff work with Windoze?
>>
>> When you have your compiler installed, you download the Windows SDK
>> which contains the necessary header files. Then you call the functions
>> defined in these header files.
>
> Fair enough, but how exactly does it work under the covers? As in, how
> does it ultimately find the address of the code you want to call?
>
> (I'm sure in the normal course of events you'll never need to know or
> care about this stuff. I'm just curios...)
The compiler recognizes that you are calling functions that aren't being
directly compiled into the code, and leaves dummy values in the Jump
instructions. During the linking or loading phase, those values are
replaced by addresses in memory.
At a lower level, the object files/DLL have a table that instructs the
linker/loader as to how far into that file a certain function is. When
that gets loaded into memory, in the case of a DLL at run time, the
linker/loader can take that memory location and basically do a search
and replace.
There is another level of misdirection, in that most of the time the
library is loaded into the user processes' virtual memory. This means
the address isn't really the actual location of the library in RAM, but
that is more a hardware level thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 <voi### [at] devnull> wrote:
> Fair enough, but how exactly does it work under the covers? As in, how
> does it ultimately find the address of the code you want to call?
AFAIK the system libraries perform kernel calls (in both Windows and
Linux). Basically the kernel knows the library and accepts its calls
(while it's not possible to do it directly from user code). A kernel
function call is probably little more than a 'call' machine code to
a certain address in the kernel space. A 'call' machine code is more or
less equivalent to 'gosub' in BASIC. (The CPU can be instructed to allow
or disallow such calls depending on what code is attempting to do it.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> Addison-Wesley released a very extensive set of docs for the Amiga,
> consisting of five volumes.
Yup. Or any Amiga compiler came with it. Considering I owned both the
books and a couple of compilers in college, I don't think it was *that*
much money. $99 for a C compiler, if I recall. I think I still have the
books somewhere.
>> How does this stuff work with Windoze? (Or Linux, for that matter...)
>
> For Windows, I think that the library code is mostly in DLLs, and that
> your linker will add the appropriate OS calls to get any needed DLLs
> into memory.
Yep. That's what user.dll, graphics.dll, stuff like that are.
At the lowest lowest level, I'm pretty sure the libraries load up
arguments into registers and execute an INT instruction, which is a
"software interrupt", aka a trap, which causes a branch to an address
loaded into a specific area of memory. I.e., just like handling an
interrupt, or just like branching to a jump table in a library, except
that you get privilege bits flipped around.
I don't know of any modern multiuser OS that doesn't use that technique
to get into the kernel, as it's pretty much the only way to bypass
memory and execution permissions in a controlled way.
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> Fair enough, but how exactly does it work under the covers? As in, how
>> does it ultimately find the address of the code you want to call?
>
> AFAIK the system libraries perform kernel calls (in both Windows and
> Linux). Basically the kernel knows the library and accepts its calls
> (while it's not possible to do it directly from user code). A kernel
> function call is probably little more than a 'call' machine code to
> a certain address in the kernel space.
That's called a "call gate". Not many CPUs use that any more, especially
those with memory mapping and VM handling.
Wikipedia is your friend: http://en.wikipedia.org/wiki/System_call
(BTW, this is why C isn't particularly better than any other language
for this stuff. There's no way to specify something like "load register
EAX with 0x80 and then do a system interrupt call.)
BTW, even CP/M on the 8080 and DOS on the 8086 used interrupt calls to
dispatch to the OS, even tho there were no privilege reasons to do so.
If you're not familiar with how modern systems do interrupts and
privileges and such at the assember/hardware level, it's hard to go into
too much detail. If you *are* familiar, then it should be pretty
obvious. :-)
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Dec 2007 11:39:20 +0000, Orchid XP v7 wrote:
> Fair enough, but how exactly does it work under the covers? As in, how
> does it ultimately find the address of the code you want to call?
A lookup table of some sort.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Dec 2007 10:08:03 -0800, Darren New wrote:
> (BTW, this is why C isn't particularly better than any other language
> for this stuff. There's no way to specify something like "load register
> EAX with 0x80 and then do a system interrupt call.)
I don't know about GCC, but I know in BorlandC and TurboC, you could do
inline assembler - I used to use that functionality a lot back in the
dark ages...
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> I don't know about GCC, but I know in BorlandC and TurboC, you could do
> inline assembler - I used to use that functionality a lot back in the
> dark ages...
Yup. Note that inline assembler isn't C. :-) I was thinking more of
Ada, which actually has language constructs for hooking and invoking
interrupts, for example. You can declare a procedure as one that gets
executed by an interrupt at a certain priority, and where it gets its
arguments from, and so on.
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Dec 2007 13:36:42 -0800, Darren New wrote:
> Yup. Note that inline assembler isn't C.
Well, true. :-)
But it wouldn't be hard to write a function that does the low-level
stuff, either, I don't think - just a question of linking to a library
with an appropriate function.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> But it wouldn't be hard to write a function that does the low-level
> stuff, either,
Unless you're going to do something like write into a char[], then cast
the char[] to a function pointer, I'm pretty sure you can't invoke
arbitrary machine code from C. :-) *Somewhere* there's assembler.
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
