12-28-2004, 04:57 AM
12-28-2004, 07:14 AM
12-28-2004, 07:17 AM
12-28-2004, 09:35 AM
12-28-2004, 10:27 AM
Here is what I figured out.
make your subs/functions as modular code blocks, I think it might be safe to keep your declarations etc in the same .bas file. compile without linking. (fbc options can be found by typing fbc.exe and hitting enter with no optionis or anything). Once fbc.exe has made your .o (object) file, use ld.exe to link it.
ld.exe -dll blah.o blah.dll
I know somewhere in the above you are supposed to tell the linker to point an entry point in the linking process. I don't quite know how to do that just yet. Perhaps like what Nek had suggested by making the functions availble to a Win_Main block(that's empty.. not sure). The Win_Main block should act as said entry point I think(or at least set the dll up as a Gui subsystem dll). As far as getting the runtime functions accounted for in the linking process, again I am at a loss there too.
Setting an entry point and embedding the fbc runtime is the big mysteries so far. I wish I knew more to help ya with..
make your subs/functions as modular code blocks, I think it might be safe to keep your declarations etc in the same .bas file. compile without linking. (fbc options can be found by typing fbc.exe and hitting enter with no optionis or anything). Once fbc.exe has made your .o (object) file, use ld.exe to link it.
ld.exe -dll blah.o blah.dll
I know somewhere in the above you are supposed to tell the linker to point an entry point in the linking process. I don't quite know how to do that just yet. Perhaps like what Nek had suggested by making the functions availble to a Win_Main block(that's empty.. not sure). The Win_Main block should act as said entry point I think(or at least set the dll up as a Gui subsystem dll). As far as getting the runtime functions accounted for in the linking process, again I am at a loss there too.
Setting an entry point and embedding the fbc runtime is the big mysteries so far. I wish I knew more to help ya with..
12-28-2004, 03:54 PM
I think I got this figured out finally...
ld -dll -e fb_winhello_entry -o winhello.dll winhello.o -L i:\freebasic\lib -l fb -l crtdll -l kernel32 -l user32 -l gdi32 -subsystem windows
-dll sets the linker to make a dll
-e fb_yourbasfilename_entry sets the entry point
-o yourbasfilename.dll sets up your *output* filename
-L sets the library path for linker
-l loads a libary to be embedded in your resultant dll (runtimes plus any libs loaded with an $include metastatement)
-subsystem what kind of dll do ya want: windows, console, native, or posix
w00t!
winhello.dll is now born. :-) I have run dependancy walker on it...
It's valid. The tree lists all former libraries dynamically linked to it, however no functions are exported.
I would have figured that at least the Win_Main function would have been. dependancy walker also lists the dll file as a console dll.
Now to figure out how to make gui/window dll's as well as having exported functions..
ld -dll -e fb_winhello_entry -o winhello.dll winhello.o -L i:\freebasic\lib -l fb -l crtdll -l kernel32 -l user32 -l gdi32 -subsystem windows
-dll sets the linker to make a dll
-e fb_yourbasfilename_entry sets the entry point
-o yourbasfilename.dll sets up your *output* filename
-L sets the library path for linker
-l loads a libary to be embedded in your resultant dll (runtimes plus any libs loaded with an $include metastatement)
-subsystem what kind of dll do ya want: windows, console, native, or posix
w00t!
winhello.dll is now born. :-) I have run dependancy walker on it...
It's valid. The tree lists all former libraries dynamically linked to it, however no functions are exported.
I would have figured that at least the Win_Main function would have been. dependancy walker also lists the dll file as a console dll.
Now to figure out how to make gui/window dll's as well as having exported functions..
12-28-2004, 08:09 PM
12-28-2004, 08:57 PM
12-28-2004, 09:48 PM
12-29-2004, 07:15 AM
Still no luck in finding a way to make entrypoints for individual functions (none visible with dependancy walker anyway). I am wondering about a couple things:
1.)
Would it be possible to acquire the memory address of a function just as it runs, display it with print(or whatever floats the boat), then recompile it using the displayed address as your entrypoint, then use that entrypoint as an alias to load the function back into freebasic/vb/etc at declaration time?
2.)
<jk>or am I trying to hard? </jk> :lol:
The only downside I can see with the above, other than trickyness, would be that if it did work, there would only be 1 sub or 1 func for each dll file made.
1.)
Would it be possible to acquire the memory address of a function just as it runs, display it with print(or whatever floats the boat), then recompile it using the displayed address as your entrypoint, then use that entrypoint as an alias to load the function back into freebasic/vb/etc at declaration time?
2.)
<jk>or am I trying to hard? </jk> :lol:
The only downside I can see with the above, other than trickyness, would be that if it did work, there would only be 1 sub or 1 func for each dll file made.