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).
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.
Even if I have found a lot online I still am not able to find how to really use resourcestrings. I have an iOS only application made with seattle and I have a file called italian.pas which is the following:
unit italian;
interface
resourcestring
word1 = "parola1";
test1 = "prova1";
implementation
end.
I don't want to use localization tools. From what I have understood the compiler generates a .drc file containing my resourcestrings. What to do now to localize my iOS app? (or android)
I have created other 2 files like above called french.pas and american.pas. They are the copy of italian.pas but the string values are of course different according with the language. In this answer Allen Bauer said:
This .drc file can then be translated or otherwise processed and then recompiled into a .res file This .res file can then be linked into a special "resource-only" dll with a specific extension other than ".dll" that indicates the language.
First of all consider that I am not a Delphi expert! From what I have understood here the compiler should generate somewhere a drc file from my italian.pas and the drc is going to contain my strings. Now (from the quote above) I should edit the drc adding the localization that I need.
How do I edit the drc file with the localization? Also I guess that the edited drc files containing the localizations must be linked with the executable somehow. Do I really need to create 3 different pas files files or I just need a single drc file and then localize it?
At the moment there is no easy way to localize mobile Delphi applications. The reason is that those platforms do not support resource libraries such as resource DLLs in Windows. When compiler compiles code where is a resource string the compiler takes the strings and inserts it a string resource inside the application file. Of course you can modify this after compilation but it is not easy because you also have to calculate all internal references inside the ELF (Android) or Mach (iOS) file.
The only viable solution is not to use resource strings at all but uses some kind of translate function (similar to gettext) and to uses some kind of translations component that stores the translations in some format and the on runtime changes the form strings and provides the right language strings for the translate function. The problem however are the several resourcestring used in RTL and FireMonkey libraries. There is not just any easy way to localize them.
Is there a way to share types across fsx files?
When using #load to load the same file containing a type from multiple FSX files they seem to be prefixed into a different FS_00xx namespace each time, which means you can't pass them around.
Are there any ways around this behaviour without resorting to compiling into an assembly?
As for
http://msdn.microsoft.com/en-us/library/dd233169.aspx
[.fsx files are] used to include informal testing code in F# without adding the test code to your application, and without creating a separate project for it. By default, script files are not included in the build of a project even when they are part of a project.
This means that if you have a project with enough structure to be having such dependency problems, you should not use .fsx files, instead write modules/namespaces using .fs files. That is, you really should compile them types into an assembly.
The f# interactive interpreter generates assembly for each loaded files. If you load a file twice, the bytecode is generated twice, and the types are different even if they have the same definition and the same name. This means that there is no way for you to share types between two .fsx files, unless one of them includes the other.
When you #load a file which has the same types as ones already present in your environment, the f# interactive interpreter can use two different strategy:
refuse to load the file if conflicts with existing names arises (complaining that some stuff is already defined)
put the names in FS_00xx namespace (so that they are actually different types from the ones you already loaded), eventually opening the resulting namespace so that names are available from interactive session.
Since fsx files are supposed to be used as informal test it is more user-friendly to use the second approach (there are also technical reason for which the second approach is used, mainly dependent on .net VM type system, and the fact that existing types cannot be changed at runtime).
[Note: This is a more specific answer to a more specific question that is a duplicate of this one.]
I don't think there is a nice and easy solution for this. The one solution I have been using in some projects (like the F# snippets web site) is to have only one top-level fsx file that loads a number of fs files. For example, see app.fsx.
So, you would have common.fs, intMapper.fs and stringMapper.fs that would be loaded from caller.fsx as follows:
#load "common.fs"
#load "stringMapper.fs"
#load "intMapper.fs"
open Common
Inside stringMapper.fs and intMapper.fs, you do not load common.fs. The common types will be loaded by caller.fsx before, so things will work.
The only issue with this is that intMapper.fs now isn't a standalone script file - and if you want to get autocomplete in an editor, you need to add a fsproj file that specifies the file order. In F# snippets project, there is a project file which specifies the order in whch the editor should see and load the files.
Have all the #load and #open directives in the file you actually run from fsi.exe (C in the example below), and make sure the loaded files themselves do not #load their own dependencies:
Files A.fsx, B.fsx, C.fsx. B depends on A. C depends on B and A.
B contains
//adding the code below would cause the types defined in A to be loaded twice
//#load "A.fsx"
//#open A
C contains
#load "A.fsx"
#open A
#load "B.fsx"
#open B
Unfortunately this then makes all the files hard to edit from Visual Studio - the editor doesn't know about their dependencies and shows all sorts of errors.
Therefore this is a bit of a hack, and the recommended way seems to be to have a single .fsx file and compile everything else into a .dll :
// file1.fsx
#r "MyAssembly.dll"
https://msdn.microsoft.com/en-us/library/dd233175.aspx
I'm currently porting a rather big project from C++ Builder 5 to the newest version, C++ Builder XE. It's my first experience with C++ Builder. I'm stuck with an error in a file, but I don't want to include this file anyway (it's code of a component not required anymore). I was not able to find out where and how this file is included, however. The compiler error does not give any hint at all apart from the error itself. How do you usually find out where a file is included?
The preprocessor is perfect for this. Right click on the cpp file which gives you the error in the project manager then choose "preprocess"
The output from this tells you every file and line number in the order they are processed. You can then search for the file in question, and the line above it is the file that included it.
This could conceivably be another header file as well, so it could be a long chain, but you can determine exactly where it comes from.
In the Project Options, enable the compiler's general messages. When the compiler encounters an error, you will be able to see the chain of includes that lead to the erroneous code.
If the files in question are rather sizable, a tool like Doxygen can be helpful in showing you the include dependencies (as well as call paths, etc.).
If it's just once or twice you'll have to do this, David Dean's suggestion of the preprocessor is golden.
J2ME lacks the java.util.Properties class. Although it is possible to put application settings in the JAD file this is not recommended for many properties. (Since, some platforms limits the size of JAD file.) I want to put a configuration file inside my jar file and parse it. And I do not want to go with XML because it will be overshooting for my case.
Question is, is there an already existing library for J2ME that can parse properties files or something similar such as INI file. Or would you recommend another method to solve the initial problem?
The best solution probably depends on what is going to be generating the properties files.
If you've got other non-JavaME projects using the same properties files, then stick with them, and write or find a parser. (There is a simple one from GoBible available on Google Code)
However you might find it just as easy to keep your configuration as static final String myproperty="myvalue"; in a Configuration.java file which you compile, and include in the jar instead, since you then do not need any special code to locate, open, read, and parse them.
You do then pick up a limitation on what you call them though, since you can no longer use the common dot separated namespacing idiom.