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.
Related
I am using the Dart's package:resource/resource.dart to load a file, it works.
But when I use dart2native to compile, it shows me the Unsupported operation: Service isolate is not available. May I know how can I resolve it?
The line for me to use the resource:
await Resource('package:core/assets/dev/ca.crt').readAsBytes()
The resource package is not doing anything clever, it's just running dart:io code to load files and using Isolate.resolvePackageUri to figure out where the file is.
My guess it that the latter does not work when you compile to native. That makes a kind of sense - if you compile to native, you can move the executable somewhere else. It no longer has access to the source code. The resource package tries to load resources stored in package libraries, which is where the program source is also located, and a native application doesn't have that available.
I'm not sure if there is a way to make it work using the resource package.
I'd probably instead move the resource I need so it's distributed along with the executable, and then try to find the file relative to the executable path (if you can find that). Avoid using a package: URI, they generally won't work well with ahead-of-time compilation.
Delphi 10 Seattle introduces Winapi.Security.pas. The project (a package) I'm trying to upgrade already has a Security.pas file. Short of removing Winapi from the list of scope names for the project (huge undesirable ripple effect), is there a way to tell the IDE and compiler to use the project's Security.pas file instead of Winapi.Security.pas?
I already tried renaming the projects Security.pas, but that caused even more problems with the compiler generating errors that have nothing to do with the code it was complaining about, so that's a rathole I'd rather not go down right now. This project builds just fine unchanged in XE7, FWIW, so this isn't due to any code changes in the project.
Updates:
Renaming the file and using a unit alias doesn't work.
The compiler behavior for a package differs from an application.
Looks like this might actually be related to the Winapi.Security unit rather than something as generic as you suggest in the question. For instance, the following package compiles just fine:
package Package1;
requires
rtl;
contains
Windows in 'Windows.pas'; // blank unit named Windows.pas in project folder
end.
Note that I have, like you, included Winapi in the project's list of unit scope names.
On the other hand, this package does not compile:
package Package1;
requires
rtl;
contains
Security in 'Security.pas'; // blank unit named Security.pas in project folder
end.
The compiler fails with:
[dcc32 Error] Package1.dpk(7): E2200 Package 'rtl' already contains unit 'Winapi.Security'
If the issue was purely related to unit scope names then either both packages would compile, or both would fail. Hence my conclusion that there is something out of whack with Winapi.Security.
I can find no source code for Winapi.Security. I wonder what it actually is. [Nicholas Ring located the source for me, inside the rtl\win\winrt directory.]
Anyway, I think it's time to submit a QP report. The package below that fails to compile is probably the starting point for that QP report. [Your submitted report is here RSP-12469.]
It seems clear to me that in the short term you must rename your unit if you wish to adopt Seattle.
FWIW, here are some other units that behave the same way as Winapi.Security:
Winapi.ApplicationModel
Winapi.CommonTypes
Winapi.Devices
Winapi.Foundation
Winapi.Gaming
Winapi.Globalization
Winapi.GraphicsRT
Winapi.Management
Winapi.Media
Winapi.Networking
Winapi.Storage
Winapi.UI
Winapi.WebRT
These are all newly added WinRT units which I expect is important.
If you put both Winapi.Security and your local Security in the same uses clause then you are able to access the members of both of them without issue. If you put them in separate uses clauses (Interface vs. Implementation) then you will get the error:
E2004 Identifier redeclared: 'Winapi.Security'
If I only include Security.pas in the uses clause (and it is included in the project) then it accesses its members just fine.
Perhaps I need more information about what error you are running into? I'll send you a sample project that shows this working.
I might well be wrong, but I believe that if Security.pas is in the uses clause of the dpr file, along with its full path, it will be preferred over whichever file can be found via the namespaces and search paths.
Open project settings, in the Delphi Compiler section remove "Winapi" from "Unit scope names".
This way, when you need the Security unit shipped with Delphi, you'll have to write Winapi.Security, and if you write Security, it will use your custom Security unit.
I am currently building a program using GLEW, compiled with MinGW ( in Eclipse ). I built the GLEW libs from the source provided by the GLEW website.
I have been able to use the GLEW declared functions without a problem if I link with the .DLL. However, if I try to link with the static library ( libglew32.a ) with the "GLEW_STATIC" flag defined, I get an error for the function "glewInit()":
undefined reference to `imp_glewInit#0'
If I open up libglew32.a in a hex editor, I can see that there is an entry, but it is named _glewInit#0. So it seems like the disconnect is that my program's compile is trying to append this "imp" string to the front of the function name in the library.
It seems like there must be mis-match of the calling convention here, but I don't know what would cause it yet. There are certainly lots of different ways that GLEW declares the api functions in the header depending on what compiler definitions are set, but I haven't narrowed it down yet.
Any ideas out there?
It looks like that imp prefix gets added for function stubs that are intended to be loaded at runtime from a .DLL. In other words, I wasn't actually staticly linking against GLEW. It turned out that I didn't quite have my eclipse C++ symbols set up correctly, so GLEW_STATIC was not being defined. After making sure that it was set up in the g++ call, it links just fine.
I have two projects in an F# solution.
1. main project with [EntryPoint] and set as the StarUp project.
2. support, the second project, holds a group of support modules. I.e. they are only called and never initiate anything nor serve as the entry point nor are the StartUp project.
For the last module in the support project, compiling in Visual Studio gives
warning FS0988: Main module of program is empty; nothing will happen
when it is run
While using compiler option nowarn inline as #nowarn "988" in the module causing the warning does suppress the message I would rather add something like a dummy function with comments that resolves the issue.
How does one make such a dummy function to resolve the warning?
EDIT
Jack is correct in that my support project was setup as a Console Application instead of a Class Library. Changing to Class Library resolved the warning. It is also nice to know about do () for the other case.
EDIT
While it seemed odd that I would have set a support project as a Console Application, I recently found that for some reason when I made a change to the code in the project, something changed the Output type from Class Library to Console Application. I suspect it has to do with the F# PowerPack and it's build rules, but it's only a guess.
Are you building the support project as a Library or as a Console Application? (This is set via the project properties page.)
If you're building it as a library, then you may need to add a do() at the end of the last file in the project. This is necessary to make the F# compiler happy in a few specific scenarios, like when you create a module which contains only assembly-level attributes (because they're applied to the assembly, the module appears "empty" to the compiler).
You can see an example in my code here:
https://github.com/jack-pappas/FSharp.Compatibility/blob/master/FSharp.Compatibility.OCaml/AssemblyInfo.fs
I've implemented a blackberry application using JRE5.0, it's running well on any device with OS5.0 and OS6.0
When I try to open the same application on 9900 which has OS 7.0, I got the following error:
Error Starting myAppName: Module 'MyAppName-4' has verification error
3337. (Codfile version 78)
where myAppName is the application name (name of the cod file)
as in the following image:
I checked the event logger, here what it contains (older to newer):
a System - VM:LINK MyAppName
a System - VM:VECPs=my.Package.Name.Containing.Screens
a System - VM:VECCs=oneOfMyScreenClassNames
a System - VM:VECMm=functionInOneOfMyClasses()
Module 'MyAppName-4' has verification error 3337 (codfile version 78)
Linker error: 'VerifyError' for MyAppName
Error starting myAppName: Module 'MyAppName-4' has verification error 3337 (codfile version 78)
Here is the content:
E System - JVM:INFOp=2100000a,a='7.0.0.296',o='4.0.0.127',h=7001204
For those who are interested, I found the solution.
In the logs there were:
a System - VM:VECCs=oneOfMyScreenClassNames
a System - VM:VECMm=functionInOneOfMyClasses()
I did the next steps in the whole class "oneOfMyScreenClassNames" indicated in logs
Here are the steps:
If you started by building a Java Archive (JAR) file and then used the RIM Application Program Compiler (RAPC) to create .cod files, make sure you turn obfuscation off when building the JAR file. The RAPC compiler performs its own obfuscation and issues may occur if the code is already obfuscated.
Remove any System.out.* calls. These generally do nothing on the BlackBerry smartphone, but they might cause verification errors.
Remove unused import statements.
Explicitly specify the access for each function or variable. For example, make sure each one is specified as public, private, or protected.
If you are working with a MIDlet, make sure the MIDlet class is declared as public.
Verification errors may occur if the COD file is corrupted or if it was not signed correctly. Make sure that you perform a clean rebuild and that you re-sign your application. Reinstall the application on the BlackBerry smartphone.
Comment out any non-executable code. Verification errors might be related to the size of the main code file and the library files. If you comment out non-executable code, the file sizes change, which may correct the problem.
If you have created any classes that inherit from RIM classes, change the name of any custom methods and members that you created in those classes. This makes sure that you have not named any methods or members of the same name in the internal RIM classes.
If your application is using BlackBerry® Device Software 3.8 or later, verification errors occur when an application that implements the javax.microedition.rms.RecordStore class is compiled using BlackBerry® Java® Development Environment (BlackBerry JDE) earlier than version 4.0. This occurs if the application uses either the addRecordListener or removeRecordListener methods of the RecordStore class. To resolve this issue, recompile the application using BlackBerry JDE 4.0 or later.
There is a problem with how the BlackBerry® Java® Virtual Machine (BlackBerry JVM) handles the referencing of a class directly within the constructor of another class. The following is an example:
Class1 class1= new Class1(Class2.class.getName()); To work around this issue, do not make the class call within a constructor
Remove references to a static instance variable from an inner class. There are a few ways you can remove these references, such as creating get/set methods for var in the outer class or modifying the logic to pull MyInnerClass out of MyOuterClass.
The build procedure normally compiles from the java source file with the javac command, and then runs preverify.exe file and then RAPC. Add the following command line arguments to javac to help avoid issues in earlier versions of the RAPC:
javac.exe -source 1.3 -target 1.1
Some methods that are very long can cause verification errors. By breaking these methods into helper methods, you can reduce the likelihood of verification errors.
Although not as likely, some very long method definitions (with 10 or more parameters), and some very long constant definitions (long package structure and/or long names) can also cause verification errors.
Source: http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/832062/Support_-_Preventing_verification_errors.html?nodeid=1499031&vernum=0
PS, I also removed "instanceOf" usage in code