After asking how to use PathCchCanonicalizeEx with C++Builder 10.2, I was told to create missing import libraries using the tools IMPLIB or MKEXP. I've tested both apps and they are creating lib files based on KernelBase.dll of my Windows 10. Though, both file contents look different, they start with different headers, are differently large overall etc. MKEXP documents to Creates an import archive from an input file, but doesn't seem to explain what that actually means.
So, when to use which of the both tools? What is the difference in purpose, how they work, possibly what they do support, etc?
IMPLIB is for generating an import lib for a 32bit DLL.
MKEXP is for generating an import lib for a 64bit DLL.
Related
I have a legacy Windows project using the legacy 32 Bit C++ compiler. For various reasons I need to use the Windows 8+ function PathCchCanonicalizeEx. C++Builder seems to provide the header and some module definition file for that, but I can't find any library to link against:
[ilink32 Error] Error: Unresolved external 'PathCchCanonicalizeEx' referenced from C:\[...]\WIN32\DEBUG\TMP\FILE.OBJ
How am I supposed to fix this? Do I need to add a Windows 8.1 SDK? Is the necessary lib simply named differently and I can't find it? Something completely different?
According my tests, one has two options:
IMPLIB/MKEXP
I'm developing/testing a some Windows 10 21H2, which provides an implementation for PathCchCanonicalizeEx in some DLL already. So if that source DLL is known, one can use IMPLIB or MKEXP to create an import library manually. I did that and after adding the created library from IMPLIB to my project, the linker errors were instantly gone.
Though, it's not that easy to know where PathCchCanonicalizeEx is placed in. One pretty easily finds the api-ms-win-core-path-l1-1-0.dll, but that thing is NOT an actual file on the disk and therefore can't be used by IMPLIB or MKEXP. That name is only a virtual concept for the library loader to address the same named API set of modern Windows, the extension .dll doesn't mean it's a file at all.
You can use an API set name in the context of a loader operation such as LoadLibrary or P/Invoke instead of a DLL module name to ensure a correct route to the implementation no matter where the API is actually implemented on the current device. However, when you do this you must append the string .dll at the end of the contract name. This is a requirement of the loader to function properly, and is not considered actually a part of the contract name. Although contract names appear similar to DLL names in this context, they are fundamentally different from DLL module names and do not directly refer to a file on disk.
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets#api-set-contract-names
What you really need to work with is KernelBase.dll, which is even documented by MS.
implib "KernelBase x86.lib" C:\Windows\SysWOW64\KernelBase.dll
implib "KernelBase x86-64.lib" C:\Windows\System32\KernelBase.dll
Module Definition File
The downside of manually creating LIB files is that one needs to maintain those with the project. Things depend on if the target is 32 or 64 Bit, DEBUG or RELEASE, so paths might become a bit complex, one might need to create relative paths for libraries in the project settings using placeholders for the target and stuff like that.
It seems that all of this can be avoided with Module Definition Files, which's purpose is to provide IMPORT and EXPORT statements to either consume exported functions by other DLLs or make that possible for others with own functions. I've successfully resolved my linker problems by simply creating a file named like my app using the extension .def alongside my other project files. That file needs to be added to the project, though.
dbxml.cbproj
dbxml.cbproj.local
dbxml.cpp
dbxml.def
dbxml.res
[...]
The following content made the app use the correct function from the correct DLL. Though, what didn't work was using the API set name, which resulted in an error message by the linker.
IMPORTS
KernelBase.PathCchCanonicalizeEx
IMPORTS
api-ms-win-core-path-l1-1-0.PathCchCanonicalizeEx
[ilink32 Error] Invalid command line switch for "ilink32". Parameter "ItemSpec" cannot be null.
[ilink32 Error] Fatal: Error processing .DEF file
The latter is after restarting C++Builder, so I guess the format of the file is simply wrong because of the API set name.
I have a C lib and dll file from windows application. No source code with me.
Is it possible to use that in an IOS application.
I have seen mixed responses and am confused.
If we have source code , i think we need to create dylib and then we can use the same after including relevant header file.
Please share any expert ideas to guide me in right direction.
Appreciate your help .
mia
Dynamic Libraries are not permitted on iOS to begin with, but above that, the DLL file format is not recognized by Darwin or the underlying XNU Kernel at all, as the binary format is different.
Windows APIs are not usable on the Darwin OS either (Both Mac OS X and iOS are wrappers around the basic Darwin OS). You will need to rewrite the code from the DLL to use the POSIX and/or Objective-C APIs and compile it as a static library to use it.
You need to get a iOS compatible library, no other way around it. There are several reasons:
iOS doesn't support DLLs as they are windows format, but moreover, you can't use any dynamic library on iOS, as Apple restricts it.
DLLs are usually for intel CPUs, while iOS devices have ARM CPUs.
Most dlls are calling windows APIs - are you sure this one's not?
No. If you all you have is a compiled binary DLL, there is no way to use it on iOS. Unless you happen to have an ARM DLL for the upcoming Windows 8, your DLL contains either x86 or x86-64 machine code (or maybe IA64 if you have a lot of money), which absolutely will not run on iOS devices, which are all ARM architectures. Plus many more reasons.
If you have the source code, you can recompile it for iOS, either directly into your app, as a static library that can be linked in with your app, or as a dynamic library as part of a framework. But in all cases, you need to recompile it from source code using the iOS compiler.
You are going to have to recompile it as a static library (.a file). Apple doesn't allow dynamic libraries except for their own frameworks (so you can't compile it as a dylib).
I got an API for a lib file.
With that lib file .h files were supplied.
Now i want to call the lib file within the Delphi, and use its functionality.
how does the lib file get connected to the Delphi?
update: ok allot of work around is needed, what if i get a dll? how do i link that into the Delphi?
You can't use a lib file to link to a DLL from Delphi. The .lib file would be used by C or C++ clients of the DLL.
In Delphi you need to manually translate the .h header file into a Pascal import unit using the external keyword. An example of this of the Windows.pas unit in the Delphi source. The fact that you can't use the .lib file is actually not a big issue because you have to translate the .h file no matter what.
In certain cases it is possible to extract members of a .lib file using tools like the object file converter from Agner Fog (see http://www.agner.org/optimize/?e=0,34,36) to .obj files.
The syntax is
objconv.exe libname.lib -lx
to extract all members.
By extracting all members you can ensure that there are no members missing. However, if there are further dependencies (to other .lib files) these won't be resolved and must be resolved manually.
Also translating the header files is still required.
Note: The object file format can also be converted. Delphi only understands OMF, while Intel compilers (for exampl) spit out only COFF. Thus a conversion is required, which can be done by the tool as well.
As said this only works in certain cases and it surely need some expertise in this area, because the compiler won't help much with error messages (often the messages are irritating and misleading).
When compiling a OpenCV 2.3 project in Builder I get multiple errors starting with "_fm_atan2l is not a member of 'std'" and continuing with other math related errors in that form. I also get "Multiple declaration of '_Ctraits::_Isnan(double)' and other similar errors. This happens after I simply include the OpenCV header files and thus seems unrelated to anything I have done in the application itself.
The only file I have included so far is "cv.h" in OpenCV's include directory. Am I doing it wrong already or is there maybe something else I have to set up first?
You can download simple project combining 2.3.2 and c++ builder xe2 from my site:
http://www.compvision.ru/forum/index.php?showtopic=763
There are fixed headers for builder, and lib converter in archive.
There are also .lib files in archive, but it'll be better if you make them by yourself from original .lib files contained in your opencv distribution using LibConverter.exe utility.
And there is some strange thing: some dll files need to be renamed to something like .dl or .d. Compiled program will prompt you about it.
you can correct OCV atan2 issue with bcc32, including fastmath in std namespace (for more info see: https://forums.embarcadero.com/message.jspa?messageID=363384 [^]).... but more other issues are there after ...
Until now I'm unable to build OCV 2.3.1 with CBuilder XE2 :(
Has anyone used Bluetooth on Mac OS X with Lazarus or FreePascal? There is a bluetooth unit, but it currently only supports Linux.
Information about existing unit:
http://wiki.freepascal.org/Bluetooth
I plan to enhance this to support Mac OS, but it would be nice to know if anyone has written any code to use BlueTooth on Mac OS already to avoid duplicated work.
On the other hand, if you have used XCode to access Bluetooth, what libraries did you use? I am sure I can discover this with the XCode profiler by opening some Bluetooth applications.
Note: Mac OS X doesn't appear to use the BlueZ library that Linux has, so I don't think the solution is as easy as changing the library path. Instead, it has IOBluetooth "Framework", located at /System/Library/Frameworks/IOBluetooth.framework.
Having a look, it looks like:
kaikei.ocn.ntt.com:IOBluetooth.framework $ file *
CodeResources: XML document text
Headers: directory
IOBluetooth: Mach-O universal binary with 3 architectures
IOBluetooth (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
IOBluetooth (for architecture i386): Mach-O dynamically linked shared library i386
IOBluetooth (for architecture ppc7400): Mach-O dynamically linked shared library ppc
Resources: directory
Versions: directory
On the other hand, I think if anyone had done this already, I would probably be able to find it on Google.... On the off chance I am wrong, please reply and let me know.
Clarification: I have created bindings for normal shared libraries before (f.e. sqlite3), but not for a "framework". If nobody has created bindings or otherwise used the MacOS Bluetooth framework from FreePascal, advice on how to use framework functions from FreePascal in general woule be appreciated. (And normally the functions I am porting are C based, not Obj-C, so I am not sure how to declare Obj-C methods in FPK, although I am sure I will be able to find some samples if I keep searching).
The main svn repository for translated Mac OS X framework C headers is http://svn.freepascal.org/svn/macosxintf/trunk
From time to time, FPC releases are synchronised with the latest versions hosted there. Note that the files in that repository (in the MPPInterfaces subdirectory) are in a generic format that can be automatically translated into either FPC, GPC or CodeWarrior Pascal versions.
To generate the FPC versions, use "make fpcpinterfaces", and find the results in the Build/FPCPinterfaces folder.
To translate new headers, execute something like this from inside a checked out copy of the macosxintf repository:
./Scripts/Convert.pl /System/Library/Frameworks/IOBluetooth.framework/Headers/IOBluetooth.h FORCE MPPInterfaces
Afterwards, you'll still have to edit the resulting file to add/remove units and clean up some other things not handled by the automatic translation process. Once finished, you may want to submit a bug report at bugs.freepascal.org with the finished units.
(note: because I'm unregistered, I can only add in one url per post, so the next url's are a bit mangled to get around that restriction)
You can also subscribe to the Mac Pascal list (lists.sonic.net/mailman/listinfo/mac-pascal) and ask there whether someone already translated those headers.
The Bluetooth framework indeed also contains some Objective-C headers. Objective-Pascal support is only available in the latest FPC svn versions, as described on the FPC wiki (google FPC_PasCocoa). You need this support in order to interface with Objective-C.
Translating Objective-C is probably easiest using the script elsewhere in FPC's svn (svn.freepascal.org/svn/fpc/trunk/packages/cocoaint/utils/)
You may want to ask for help on the above-mentioned Mac Pascal list, as all people maintaining the aforementioned translations and translation tools are subscribed there.