What is the difference or advantage between the two functions? I have both the lib and dll.
Also I asked this before but to reconfirm - is there any way to link libraries (lib, obj, dll) INTO the exe so that it will not need to be distributed? Some explanations on the net explain that static linking with an obj file means that the dll is not required at runtime - that the used functions are extracted and compiled into the exe. (not talking about including the dll in memory )
Is this correct and maybe only that PB is not able to link this way?
All explanations are welcome - great way to learn.
OpenLibrary vs Import
Re: OpenLibrary vs Import
With lib you make a early-binding, with dll a late-binding (dynamically). The early-binding is faster, but gives immediately acoder14 wrote:What is the difference or advantage between the two functions? I have both the lib and dll.
error, after start the exe, and won't start without the dll!
This is not correct, but the lib must be designed to not only wrap a dll. The depedency-libs have to link (Import) also.coder14 wrote:Is this correct and maybe only that PB is not able to link this way?
PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Re: OpenLibrary vs Import
Thank you ts-soft. I think I understand about the early and late bindings - something like constants and variables. So OpenLibrary is dynamic and Import is static, right?ts-soft wrote:With lib you make a early-binding, with dll a late-binding (dynamically). The early-binding is faster, but gives immediately acoder14 wrote:What is the difference or advantage between the two functions? I have both the lib and dll.
error, after start the exe, and won't start without the dll!This is not correct, but the lib must be designed to not only wrap a dll. The depedency-libs have to link (Import) also.coder14 wrote:Is this correct and maybe only that PB is not able to link this way?
But what do you mean the lib must be designed to not only wrap a dll? PB is not able to include the lib functions directly into the EXE right? In all cases the DLL is required right?
Re: OpenLibrary vs Import
It gives different libs, mostly for dll like you can create with polib. This one can't used without DLL.
The other libs, a designed to use without dll (no dll created). This one you can also import, but you have to make sure,
all dependency (other libs, like runtimes) a solved.
SQLite is imported in PB or you can use MemoryModule.lib without DLL.No dll required (only a DLL to use )
The other libs, a designed to use without dll (no dll created). This one you can also import, but you have to make sure,
all dependency (other libs, like runtimes) a solved.
SQLite is imported in PB or you can use MemoryModule.lib without DLL.
Code: Select all
CompilerIf #PB_Compiler_Processor = #PB_Processor_x64
#MemoryModule_Lib$ = "MemoryModule64.lib"
CompilerElse
#MemoryModule_Lib$ = "MemoryModule.lib"
CompilerEndIf
Import #MemoryModule_Lib$
MemoryLoadLibrary(*MemoryPointer)
MemoryGetProcAddress(hModule, FunctionName.p-ascii)
MemoryFreeLibrary(hModule)
MemoryFindResource(hModule, lpName.p-ascii, lpType.p-ascii)
MemoryFindResourceEx(hModule, lpName.p-ascii, lpType.p-ascii, wLanguage.w)
MemoryLoadResource(hModule, hResInfo)
MemoryLoadString(hModule, uID.l, *lpBuffer, nBufferMax.l)
MemoryLoadStringEx(hModule, uID.l, *lpBuffer, nBufferMax.l, wLanguage.w)
MemorySizeofResource(hModule, hResInfo)
EndImport
PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Re: OpenLibrary vs Import
Thank you ts-soft. I think I understand now.ts-soft wrote:It gives different libs, mostly for dll like you can create with polib. This one can't used without DLL.
The other libs, a designed to use without dll (no dll created). This one you can also import, but you have to make sure,
all dependency (other libs, like runtimes) a solved.
SQLite is imported in PB or you can use MemoryModule.lib without DLL.No dll required (only a DLL to use )Code: Select all
CompilerIf #PB_Compiler_Processor = #PB_Processor_x64 #MemoryModule_Lib$ = "MemoryModule64.lib" CompilerElse #MemoryModule_Lib$ = "MemoryModule.lib" CompilerEndIf Import #MemoryModule_Lib$ MemoryLoadLibrary(*MemoryPointer) MemoryGetProcAddress(hModule, FunctionName.p-ascii) MemoryFreeLibrary(hModule) MemoryFindResource(hModule, lpName.p-ascii, lpType.p-ascii) MemoryFindResourceEx(hModule, lpName.p-ascii, lpType.p-ascii, wLanguage.w) MemoryLoadResource(hModule, hResInfo) MemoryLoadString(hModule, uID.l, *lpBuffer, nBufferMax.l) MemoryLoadStringEx(hModule, uID.l, *lpBuffer, nBufferMax.l, wLanguage.w) MemorySizeofResource(hModule, hResInfo) EndImport
Re: OpenLibrary vs Import
I know, I'm a bit late, but shouldn't the .l-datatypes be .i-datatypes?ts-soft wrote: ↑Sun Jan 08, 2017 2:56 pm It gives different libs, mostly for dll like you can create with polib. This one can't used without DLL.
The other libs, a designed to use without dll (no dll created). This one you can also import, but you have to make sure,
all dependency (other libs, like runtimes) a solved.
SQLite is imported in PB or you can use MemoryModule.lib without DLL.No dll required (only a DLL to use )Code: Select all
CompilerIf #PB_Compiler_Processor = #PB_Processor_x64 #MemoryModule_Lib$ = "MemoryModule64.lib" CompilerElse #MemoryModule_Lib$ = "MemoryModule.lib" CompilerEndIf Import #MemoryModule_Lib$ MemoryLoadLibrary(*MemoryPointer) MemoryGetProcAddress(hModule, FunctionName.p-ascii) MemoryFreeLibrary(hModule) MemoryFindResource(hModule, lpName.p-ascii, lpType.p-ascii) MemoryFindResourceEx(hModule, lpName.p-ascii, lpType.p-ascii, wLanguage.w) MemoryLoadResource(hModule, hResInfo) MemoryLoadString(hModule, uID.l, *lpBuffer, nBufferMax.l) MemoryLoadStringEx(hModule, uID.l, *lpBuffer, nBufferMax.l, wLanguage.w) MemorySizeofResource(hModule, hResInfo) EndImport
PureBasic 6.04/XProfan X4a/Embarcadero RAD Studio 11/Perl 5.2/Python 3.10
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
Re: OpenLibrary vs Import
probably not unless its a pointer, windows mostly uses ints for parameters so .l longs or short int .w/.u
Re: OpenLibrary vs Import
Sorry for asking again, but isn't it possible that the address the pointer is pointing to is above MAXINT in a x64-system?
PureBasic 6.04/XProfan X4a/Embarcadero RAD Studio 11/Perl 5.2/Python 3.10
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
Re: OpenLibrary vs Import
yes a pointer can of course point to a larger value, like values in XMM/YMM/ZMM registers 128/256/512