Re: [fpc-pascal] opening a serial port in a dll called from dot net fails
El 11/3/24 a les 11:38, Elmar Haneke via fpc-pascal ha escrit: Presumably the problem is caused by calling your function from a different thread. Perhaps it is a solution to put the SerOpen in a thread created by FPC and signal that thread from your dot-net-called function. Nope, I tried, same error. Am 09.03.24 um 16:24 schrieb Luca Olivetti via fpc-pascal: I'm writing a dll that is used by a dot net application (32bits). If I call SerOpen in the initialization section of the dll there is no problem, but if I call it from one of the exported functions it gives me an access denied (GetLastError gives me a 5), and I really need to call it from a function (due to some quirks in the calling program which is not under my control). A search in the usual places tells me that in dot net opening a serial port with CreateFile (which is what SerOpen does) is forbidden, that you should use the SerialPort class (which I don't think I can do from my dll written in freepascal). Is there any way to solve my problem? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] MachO $indirect symbols
When compiling for aarch64 with fpc 3.3.1 on macOS 14.2, I notice some new entries in the Mach-O symbol table of the produced executable, e.g. apart from SegmentName = __DATA_CONST SectionName = __const SymbolName = _VMT_$SYSTEM_$$_TOBJECT n_type = 15 there is now also an entry SegmentName = __DATA_CONST SectionName = __const SymbolName = _VMT_$SYSTEM_$$_TOBJECT$indirect n_type = 15 etcetera. I don't know if the new entries are specific for aarch64, for fpc 3.3.1 or for the linker and assembler used. Also the segment name seems to have changed from __DATA to __DATA_CONST. Just wondering what's behind this. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] opening a serial port in a dll called from dot net fails
Presumably the problem is caused by calling your function from a different thread. Perhaps it is a solution to put the SerOpen in a thread created by FPC and signal that thread from your dot-net-called function. Am 09.03.24 um 16:24 schrieb Luca Olivetti via fpc-pascal: I'm writing a dll that is used by a dot net application (32bits). If I call SerOpen in the initialization section of the dll there is no problem, but if I call it from one of the exported functions it gives me an access denied (GetLastError gives me a 5), and I really need to call it from a function (due to some quirks in the calling program which is not under my control). A search in the usual places tells me that in dot net opening a serial port with CreateFile (which is what SerOpen does) is forbidden, that you should use the SerialPort class (which I don't think I can do from my dll written in freepascal). Is there any way to solve my problem? Bye ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
