C++ version Alexandria crashes but building with Tokyo 10.2 works fine

[dan27125]

C++ version Alexandria compiled for 32 bit crashes but Tokyo 10.2 works fine. i.e. Building 32 bit APPs with Tokyo 10.2 works fine.
Can someone help me fix the Alexandria package?

I have a high volume outbound Fax Server APP that was built 20 years ago using C++ Builder 6 and a AsyncPro. I recently got the app to compile and run OK using C++Builder/Rad studio version 10.2 Tokyo.

When built with C++ version Alexandria the app crashes immediately. I have spent several days trying to use Alexandria. I'm the Alexandria package files from AsyncPro-master.zip from here on github. First I open the runtime package AsyncProCR. I set the platform to 32 bit release. It compiles just fine. Next I close the runtime package. Next I open the open the development package. I set the platform to 32 bit release. It compiles just fine. Next I add the package by going to Component | Install Package. I maneuver to C:\Users\Public\Documents\Embarcadero\Studio\22.0\BPL I select AsyncProCD280.bpl (D for design) The package installs fine. Next I close the Package. Next I open my outbound fax app.

Next to overcome compiler error E2109 Not an allowed type in a number of places within AdFax.hpp. As a temporary workaround I'm manually editing AdFax.hpp by simply changing "__published:" to public: in a number of places. The app compiles fine but it crashes immediately when you send a test fax.

I have a different parent folder for all of the files when I'm trying to use Alexandria vs Tokyo 10.2. When I use C++ version Tokyo 10.2 everything works fine. (Note: I'm a paying Embarcadero customer with a subscription so I can run any version of Rad studio. I have tried all versions of Alexandria. Results are the same. It crashes immediately when you send a test fax.

I'm a C/C++ programmer with very little Delphi Pascal experience. I'm not sure how to debug / fix this this. It using using the exact same Asyncpro source folder pascal files. Other then the Rad Studio compiler version The only difference are the package files Alexandria vs Tokyo. This is a 32 bit app.

Maybe my HPP header file fix is not really fixing things ? Maybe there is a structure alignment size problem ? Or maybe its something else? Maybe there is something wrong in the Alexandria package ?

Does anybody have any clues, tips or suggestions to troubleshoot and fix this ?

What about fixing the E2109 Not an allowed type in a number of places within AdFax.hpp?

Best regards

Dan C/C++ Software engineer Saint Louis Missouri USA

[romankassebaum]

I'm not a C++ specialist, so that I do not know how to fix this. I would suggest that you contact David Millington from Embarcadero, he knows everything about the C++ Builder.

[dan27125]

How do I reach David Millington with Embarcadero?

On Tue, Feb 28, 2023 at 9:26 AM Roman Kassebaum @.***> wrote:

I'm not a C++ specialist, so that I do not know how to fix this. I would suggest that you contact David Millington from Embarcadero, he knows everything about the C++ Builder.

— Reply to this email directly, view it on GitHub https://github.com/TurboPack/AsyncPro/issues/35#issuecomment-1448381449, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4BZSJPX33HRDO5ZZO4NDLTWZYKK7ANCNFSM6AAAAAAVIWJ5OY . You are receiving this because you authored the thread.Message ID: @.***>

[dan27125]

Do you have much experience with Delphi ? If yes, read this update. I may have a fix. I need someone with Delphi experience to answer one question about the string array declaration string[255]; vs string; i.e. with size braces [255] and without it; After investigating it looks like changes made 10-15 years ago in the delphi pascal code version tpapro_5.00 were lost. There are old notes and a post from 2006 on Stackoverflow that say ++ Builder does not like delphi string declarations with sizes. So tpapro_5.00 was created with just a few changes. In about 5 places that use string[xx] the code was changed to string. For example in oomisc.pas at about line 143 ... //TPassString = string[255]; TPassString = string; // SBD: Originally: string[255]; which are AnsiChars.

When I put back these changes in the pascal code from tpapro_5.00, (i.e. change from string[x] to string) everything compiles and builds fine. The C++ Builder APP compiles clean and seems to run OK. NO more Borland C++ compiler errors. So the Delphi questions are:

1) It looks like all of the changes made tpapro_5.00 are gone. Did somebody fork the wrong version of tapro when they created and posted this on github ?

2) Is it legal, safe,OK,kosher acceptable to remove the array size [xx] from string ?

3) Is there a better, more desirable object to use instead of string ?

On Tue, Feb 28, 2023 at 9:26 AM Roman Kassebaum @.***> wrote:

I'm not a C++ specialist, so that I do not know how to fix this. I would suggest that you contact David Millington from Embarcadero, he knows everything about the C++ Builder.

— Reply to this email directly, view it on GitHub https://github.com/TurboPack/AsyncPro/issues/35#issuecomment-1448381449, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4BZSJPX33HRDO5ZZO4NDLTWZYKK7ANCNFSM6AAAAAAVIWJ5OY . You are receiving this because you authored the thread.Message ID: @.***>

[romankassebaum]

A string[255] is a so called ShortString. The first byte of this string, which is at the position 0, contains the length of it. Since it is only a byte, the length is limited to 255.

The biggest differnce to a LongString, which uses the keyword "string" is, that ShortStrings are AnsiStrings, whereas LongStrings are Unicode Strings.

Unicode Strings have been introduce with Delphi 2009, so that in the year 2006 with Delphi 2005 LongStrings were still AnsiStrings.

If you would now change a declaration from a ShortString to a LongString, you have to ensure that you fix all Move, FillChar, GetMem and casts to a PAnsiChar statements.

If the String only contains bytes, then TBytes which is an array of bytes, would be a better choice.

I cannot imagine that the C++Builder has problems with ShortStrings, but to be sure, you should ask David Millington.