Not sure who would know this besides Ville...
When a process creates a interupt 40.. does the
kernal do a linear search through a table to find out where to
jump to the kernal side API code?
Is there only one copy of the API code at all times and multiple "pages"
of it (to permit interupt multitasking)
Or does the kernal API get copied into seperate blocks to permit this?

Im asking these question because I had an idea tthat might speed up
kernal processing quite abit. Instead of searching a table (servetable: ?)
in the kernal.. couldnt we make every API in the kernal take up the same
amount of space (based on the biggest API).. and then make the interupt
call do a direct jump to a HASH based on the eax value?
(this might require some reordering of kernal API addresses/code)
(and it would definately enlarge the kernal size with blank areas)

Just an idea... hashes are nice and fast... linear searches are slow...
Wishing

Hash tables are already done. Look at SYS32.INC, you'll find smth like:

THat looks more like a jumptable than a hash table to me?
Also, if you wanted a "non-massive" table, order the entries and do a binary search.

The system table will never be massive, so a table lookup is a sensible choice ( 4 bytes per entry, 60 odd entries ).

Mike.

Ahh yes... that is a hash.

to f0dder:
A binary search would be slower than a hash. In a hash there is no need to search at all.. you automatically know where to go by mathematicle means. Thats what the jmp dword[eax*4+table] is.
The table just makes it so you dont ahve to do my silly version fo block-ifying the API... odd i didnt think of that

Thanks for clearing this up for me. Im glad the menuet kernal is as sophistimacated as i had hoped ^_^
Now if we could only load and unload hardware drives without recompiles