🚀 go-pugleaf

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message
news:17vep0543qqovnp4nt11762l33o181lile@4ax.com...

> Seems to me that the compiler could create a jump
> table of all functions in the dll (used or not), and the
> startup could fill it all in.

That is exactly what it actually does.  But the thing is that when the OS
loader fills in that table at startup, if any of the table entries are not
resolvable, either because the DLL is not found or the function inside the
DLL is not found, then the loader fails and the entire process is aborted
without running any of the application's code at all.

> In this case, I figured the compiler/linker could have
> the table filled with default procs that would return errors.

Nope, because the OS loader will fail the process altogether if the table
can't be filled in entirely.  Any default procs the compiler/linker may
provide would never get a chance to execute anyway.

> That's the part that just seemed so wrong to me.

Talk to Microsoft about it.  There are several functions in the Win32 API
that are provided in Win9x as just stubs and only implemented in WinNT
systems instead.  Probably a compatibility "feature" on Microsoft's part.

> I mean, if it's a new function, what's it doing in an old kernel?

The functions in question already existed in the NT platform at the time the
"old" kernel was created for the 9x systems.  Why they are introduced into
the 9x kernel but not actually implemented, I have no idea.

> And if it's in the old kernel, why wasn't it implimented?

Since those particular functions are file related, I would guess that they
need certain file system capabilities that NTFS provides but FAT doesn't?
Ask Microsoft.


Gambit