I am running Delphi XE8 and have the GetIt AsyncPro for VCL 1.0 installed. It works fine when I compile my application for 32 bit but fails for 64 bit.
The failure is:
[dcc64 Error] OoMisc.pas(2771): E2065 Unsatisfied forward or external declaration: 'Trim'
When I open OoMisc.pas is see:
{$IFNDEF Win32}
function Trim(const S : string) : string;
{$ENDIF}
The Trim function does not seem to be defined. The unit does have SysUtils in its uses clause.
AsyncPro supports only Win32 platform. It cannot be used as-is for Win64 bit.
It contains plenty of 32bit inline ASM code that would have to be replaced either by Pascal code or ported to 64bit ASM code. Besides that part there might be other incompatibilities with Win64 bit platform.
Converting 32-bit Delphi Applications to 64-bit Windows - Inline Assembly Code
If your application contains inline assembly (ASM) code, you need to
examine the ASM code and make the following changes: Mixing of
assembly statements with Pascal code is not supported in 64-bit
applications. Replace assembly statements with either Pascal code or
functions written completely in assembly.
Porting assembly code from IA-32 to Intel 64 cannot be done by simply
copying the code. Consider the architecture specifics, such as the
size of pointers and aligning. You may also want to consult the
processor manual for new instructions. If you want to compile the same
code for different architectures, use conditional defines. See Using
Conditional Defines for Cross-Platform Code in "Using Inline Assembly
Code."
RAD Studio supports Intel x86 through SSE4.2 and AMD 3dNow, and for
x64, Intel/AMD through SSE4.2.
Using Inline Assembly Code
Update:
There is Win64 port of AsyncPro provided by Johan Bontes:
I have a version for Win64 on my Github:
https://github.com/JBontes/AsyncPro
It compiles, but I have not been
able to test it comprehensivly. Feel free to file an issue if you get
stuck anywhere.
I bet that is a relic from Delphi 1 when Win32 was used to distinguish from Win16. You may safely remove those lines.
I converted AsyncPro to XE8 but it only supports Win32.
OoMisc.pas had a Trim function, that was removed from the implementation part. However somebody forgot to remove it from the interface part. That didn't hurt for x32 because it was inside of the $IFNDEF.
Win32 is not defined for x64, so the compiler will complain. The solution for this particular issue is to delete the following 3 lines that were intended for Delphi 1.0.
{$IFNDEF Win32}
function Trim(const S : string) : string;
{$ENDIF}
Of course that does not make AsyncPro compatible with x64 as there will be other issues.
Related
Why can't I uses Generics.Collections or Generics.Default or even just Generics in Lazarus?
Uses
Generics.Collections;
Uses
System.Generics.Default;
Uses
System.Generics.Collections;
Uses
System.Generics.Default,
System.Generics.Collections;
Uses
SysUtils,
Generics;
Cannot find Generics.Collections used by uTest of the Project Inspector.
Cannot find Generics.Defaults used by uTest of the Project Inspector.
Cannot find Generics used by uTest of the Project Inspector.
Lazarus is the IDE for the open-source FreePascal compiler. Neither of them have ANYTHING to do with Delphi. FreePascal is a completely separate Pascal compiler than the one Delphi uses.
FreePascal has a Delphi compatibility mode, and does implement various Delphi units and classes, to help users port existing Delphi code to FreePascal.
But as far as Generics is concerned, FreePascal provides its own Generics syntax and implementation that is different from, and not compatible with, Delphi's Generics (actually, support for Delphi-style Generics was added in FreePascal 2.6, but "still may be not 100% compatible" with Delphi. Also see delphi language features which fpc does not have - Generics Syntax).
Read FreePascal's documentation for more details about its flavor of Generics:
http://wiki.freepascal.org/Generics
http://www.freepascal.org/docs-html/ref/refch8.html
The System.Generics.Default and System.Generics.Collections units are only available in Delphi, they do not exist in FreePascal. However, there is a 3rd party implementation of these units available for FreePascal.
Generics.Collections library (with Generics.Defaults module) has been added to FPC trunk as rtl-generics package in r34229. Latest version of precompiled FPC trunk (with Generics.Collections) for Win32 + Lazarus trunk available at http://newpascal.org . The repository of Generics.Collections ( https://github.com/dathox/generics.collections ) will be still used for maintenance (should be synced often with FPC trunk).
I recomend you to use the Generics.Collections package made by Maciej Izak.
I'm creating a Delphi package using OpenGL and the GLEW extension. I downloaded GLEW from the official website. That was a painful way to make it usable with Embarcadero, but I finally succeeded. At this point, I'm able to compile and use GLEW in any C++ Builder or Delphi application project.
However, I experiment difficulties to use GLEW in my Delphi package. As GLEW is a DLL, I declare the external functions that I need as in the following example:
procedure glBindVertexArray(glArray: GLuint); external 'glew32.dll' name '__glewBindVertexArray';
This works well when I compile an application project, so I'm sure that the declaration is correct. I can compile and link my package without problems. However, when I try to use it in a demo project, I receive the following link error:
[ilink32 Error] Error: Unresolved external '__glewBindVertexArray' referenced from C:\USERS\PUBLIC\DOCUMENTS\EMBARCADERO\STUDIO\15.0\DCP\QRMODELS.LIB|TQRMD2_OpenGL
So my GLEW functions are not found by the linker. The problem is that I don't know how to link an external DLL into a Delphi package. When I try to add the DLL in the "Requires" section, my package can no more be compiled and I receive the following error:
[dcc32 Fatal Error] QRModels.dpk(35): E2202 Required package 'glew32' not found
I also tried to add glew32.lib in my package, and tried to link GLEW in my target project, but without success.
So, what is the correct way to link an external standard DLL, that isn't a .dcp, in Embarcadero Delphi packages? I remember you that I can use this DLL without problems in any Delphi application project, and I own the corresponding .lib too, that is already converted to be used with Embarcadero compiler.
Regards
NOTE: As suggested in the comment posted by David Heffernan, I tried to create a small package that includes an external function to the user32.dll. This worked well. I also tried to include one of my GLEW external function. Now the issue is different: the package links and builds well, and the target project too. But when the exe runs, I get an error message saying that glew32.dll is missing on my computer. So my issue is basically a bad installation of the GLEW library. However, all my other projects using GLEW works well, including those I create with other compilers, as e.g. Code::Blocks.
I also compared my package options, and the only thing that is different is that the package I create is divided in 2 projects, one for the design time and one for the runtime. I already created such other packages without problems, but I never tried to include external DLL in them.
Here is my test unit:
unit Unit1;
interface
uses OpenGL;
function MessageBeep(uType: Cardinal): LongBool; stdcall; external 'user32';
procedure glBindVertexArray(glArray: GLuint); stdcall; external 'glew32.dll' name '__glewBindVertexArray';
type
TTest = class(TObject)
public
procedure TestBeep; virtual;
procedure TestGlew; virtual;
end;
implementation
procedure TTest.TestBeep;
begin
MessageBeep($40);
end;
procedure TTest.TestGlew;
begin
glBindVertexArray(0);
end;
end.
Regards
is it possible for the linker to find 'glew32.dll' (is it in the search path or in the working path of the Debugger)?
maybe this can help you
http://rvelthuis.de/articles/articles-cobjs.html
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Link_object_file_(Delphi)
https://hub.packtpub.com/implementing-c-libraries-in-delphi-for-hpc-tutorial/
The last article is part of Delphi High Performance from Packt (a very good book on Delphi)
By the way, if you want to include a .lib file in Delphi, it is not enough to just add the .lib file to the project. You have to include the .lib file with {$ L 'LibName.lib'}
here's an Embarcadero Link http://docwiki.embarcadero.com/RADStudio/Sydney/en/Link_object_file_(Delphi)
You just have to make sure that your .lib file is in the correct format e.g. OMF, COFF, ELF coz Visual Studio uses COFF, Delphi OMF and C++ Builder ELF
Delphi 64-Bit Windows Compiler http://docwiki.embarcadero.com/RADStudio/Sydney/en/DCC64
Delphi 32-Bit Windows Compiler http://docwiki.embarcadero.com/RADStudio/Sydney/en/DCC32
C++ Builder 64-Bit Windows Compiler http://docwiki.embarcadero.com/RADStudio/Sydney/en/BCC64
if your .lib file is not in the correct format, you can use the following open source project to convert it
https://github.com/gitGNU/objconv
How and where can I write ARM Assembly codes in Embarcadero Delphi XE5 with Android?
That would be the best, if I can write it inline.
Delphi mobile compiler do not support the asm ... end blocks.
But the "old good way" is still available, since we are talking about a Native compiler.
What you can do is compile your own module with an external assembler (e.g. GNU AS), then link it to your Delphi XE* application.
For instance, System.RTTI uses low-level asm tricks via external statically linked files:
procedure RawInvoke(CodeAddress: Pointer; ParamBlock: PParamBlock);
external 'librtlhelper.a' name 'rtti_raw_invoke';
procedure RawIntercept;
external 'librtlhelper.a' name 'rtti_raw_intercept';
Take a look at this Japanese article - Google translate is your friend!
It is not possible.
Use Atomic Instrinsics Instead of Assembly Language.
Quote:
The Delphi mobile compilers do not support a built-in assembler.
The Delphi mobile compilers do not support inline assembler. The documentation makes this clear:
The inline assembler is available on:
DCC32.EXE, the Delphi Command Line Compiler
DCC64.EXE, the Delphi 64-bit Command Line Compiler
DCCOSX.EXE, the Delphi Cross Compiler for OS X
You'll need to find an assembler to create something that the Delphi mobile compiler can consume, for instance a shared library.
You can not.
LLVM - which is the engine behind Delphi Mobile - has its kind of an assembler language: http://llvm.org/docs/CommandGuide/llvm-as.html
But it would hardly be ARM kind or x86 kind, since LLVM tries to be CPU-agnostic.
Anyway Delphi officially has no support neither for CPU-native assembling language nor for LLVM kind of it.
http://docwiki.embarcadero.com/RADStudio/XE4/en/Migrating_Delphi_Code_to_iOS_from_Desktop#Use_Atomic_Instrinsics_Instead_of_Assembly_Language
http://docwiki.embarcadero.com/RADStudio/XE4/en/Using_Inline_Assembly_Code
My 32 bit Delphi 2010 application links to a number of C object files using the $LINK compiler directive. Can I do this in Delphi XE2 when targetting 64 bit?
I am currently compiling using bcc32 version 5.5, but I don't mind which compiler I use if it turns out that the Embarcadero C compiler does not yet output 64 bit objects.
Yes. You must compile the "C" objects files to COFF format. This usually means either the Intel and/or MSVC++ compilers. The same caveats apply to 64bit object file linking that apply to 32bit. You must ensure that all external references are properly resolved, either by providing another .obj which has that symbol, or from Delphi code. When building the "C" code, make sure you disable any stack checks or other run-time verification code generation. Many times such codegen relies on a specific version of the C/C++ RTL from the given tool.
Something else worth noting is that while Delphi 64bit can link to COFF object files (eventually it will also support ELF64), 32bit Delphi supports linking with C++Builder built OMF object files and, new to XE2, 32bit COFF object files which can be built with MSVC++. The same caveats apply.
Yes, you can link to OBJ files in 64-bit XE2 projects, but the OBJ files have to be 64-bit code.
In Delphi 2007, working on a project which includes a custom component, I'm getting this set of warnings as the first four in Messages when I do a full build (but not when I do a straight compile):
[DCC Warning] Dialogs.pas(1426): W1002 Symbol 'TFileOpenDialog' is specific to a platform
[DCC Warning] Dialogs.pas(1446): W1002 Symbol 'TFileSaveDialog' is specific to a platform
[DCC Warning] ComCtrls.pas(6757): W1036 Variable 'Section' might not have been initialized
[DCC Warning] ComCtrls.pas(19268): W1023 Comparing signed and unsigned types - widened both operands
I generally try to eliminate compiler warnings where I can, but these are "stock" Delphi units. Are these warnings the indirect result of something in my code? If so, how do I figure out what/where? If not, what should I do about them?
I believe it is because you have the stock Delphi source in your build path. If you remove the Delphi source directories, then it should build without these warnings.
The reason they show up only when doing a Build is that the compile command only compiles source which has changed since the previous compile. While the Build command recompiles everything in the project regardless of changes.
The warnings are most likely caused by the Delphi source folder being included in the project search path. Removing it and deleting the dcus in your project's folder will tell you if anything in the project required the Delphi source when you recompile. In my experience you should need the Delphi source if you have found a bug in Delphi's implementation and made a custom copy of a Delphi class to correct the bug. If this is the case when you try to build without the Delphi source you will usually get:
Unit '%s' is compiled with unit '%s'
in '%s' but different version '%s'
found (F2446)
Where %s will be some low level Delphi class.
If you don't get any error's it didn't really need the Delphi source.
This can also happen if the Delphi source is in the environment search path.
The first two warnings you mention (along with a few others) are to make you aware that the code you're currently using won't compile across different platforms Delphi supports. For Delphi 2007, there isn't much, but it carries the remnants of Kylix (the Linux version that's gone) and Delphi for .NET (which is also gone).
More recent versions of Delphi support cross-platform (Win32/Win64, OS X, iOS, and Android), where these messages are relevant again when developing Firemonkey applications (or VCL apps if there are differences between Win32 and Win64). They indicate the points in your code where you will have to make adjustments in your code for different operating systems. (For instance, the two you cite are for Windows-specific dialogs; you'd need to use a different dialog based on the target platform, and use {$IFDEF} statements around the areas that are platform-specific to keep them from being compiled in for other platforms.
As your current code can't be ported directly (even in a modern Delphi version) to anything other than Windows because it's VCL-based, you can safely turn off those warnings. Use Project->Options->Compiler Messages, and uncheck the following messages (or use the compiler define I've included in your code):
Library Symbol {$WARN SYMBOL_LIBRARY OFF}
Platform Symbol {$WARN SYMBOL_PLATFORM OFF}
Library Unit {$WARN UNIT_LIBRARY OFF}
Platform Unit {$WARN UNIT_PLATFORM OFF}
Unsafe type (.NET remnant) {$WARN UNSAFETYPE OFF}
Unsafe code (.NET remnant) {$WARN UNSAFECODE OFF}
Unsafe typecast (.NET remnant) {$WARN UNSAFECAST OFF}
The last two you've mentioned I can't reproduce with D2007 (IDE version 11.0.2804.9245), so I'd suspect that skamradt's answer is correct - it's because you have the VCL source directories in your search path, and you shouldn't. It should be set to $(BDS)\Lib. If you need to be able to step through the source, use the Project->Options->Compiler page, and check the Use debug DCUs option under Debugging instead.
I spent ages getting these problems (well, your first two anyway) and in my ignorance actually uninstalled Delphi and reinstalled it to no avail. I finally found that it is caused by the lack of project settings. At least atfirst, if you migrate a projects from an earlier Delphi, your existing project settings get converted but for no apparent reason Delphi can start forgetting about this and gives you a 'blank' set of project settings. You can see this by opening Project-Options where you will find Base, Release and Debug. Check out the active one (it is bold in the project manager) and you should see that it has no directory paths as well as all hints and warnings at their defaults. Most of these defaults are fine but 'Platform Symbol' and 'Platform unit' should be disabled (at least for Win32 stuff).
Regards,
Brian
If you want to continue explicitly compiling the VCL source into your project you can make a copy of the units that are raising the compiler hints/warnings and "fix" the hints/warnings in that copy.
Put the updated/"fixed" copies of those VCL units in another folder and make sure you add the path to that folder to your project's Search path BEFORE the path to the Delphi VCL source.
E.g. my project search path looks something like this: "C:\Dev\Source\MyFixedVCLUnits;C:\Program Files\CodeGear\RAD Studio\6.0\source"
To give an example of the simple fixes required to remove these warnings, here is one of the functions in the Dialogs.pas that now lives in my
"C:\Dev\Source\MyFixedVCLUnits" folder:
{$WARNINGS OFF}
function TFileOpenDialogWrapper.CreateFileDialog: TCustomFileDialog;
begin
Result := TFileOpenDialog.Create(nil);
Result.OnExecute := OnExecuteEvent;
end;
{$WARNINGS ON}
In this case, just add the {$WARNINGS OFF} etc as required.
TFileOpenDialog will work only on Windows Vista and up. You should use TOpenDialog instead of TFileOpenDialog, in newer Delphi versions it will detect what OS it is running and display proper dialog.
https://forums.embarcadero.com/thread.jspa?threadID=70498
If you develop only for specific platform open project source and add
{$WARN SYMBOL_PLATFORM OFF}
Compiler warnings can be disabled individually (separate per warning type) in the project options under 'Delphi Compiler | Hints and Warnings'