pyscripter

Not possible I am afraid and not easier. You just need to add the patched System.RegularExpressionsAPI to your project uses clause.

Still unable to login. Who do I need to contact?

I am trying to link an .obj file generated using Visual Studio from C file. The C file makes Windows calls such as VirtualFree; When I try to compile the Delphi source code with {$L} directive in 32 bits Delphi complains about [dcc32 Error] ExtPCRE.pas(889): E2065 Unsatisfied forward or external declaration: '__imp__VirtualFree@12' Is there a way to resolve this without changing the C code? In 64 bits the name comes undecorated as __imp_VirtualFree and I am resolving this as: type TVirtualFree = function(lpAddress: Pointer; dwSize: SIZE_T; dwFreeType: DWORD): BOOL; stdcall; const __imp_VirtualFree: TVirtualFree = WinApi.Windows.VirtualFree; Is this correct? And a related question fpc provides for the following syntax: Var MyVar : MyType; external name ’varname’; The effect of this declaration is twofold: No space is allocated for this variable. The name of the variable used in the assembler code is varname. This is a case sensitive name, so you must be careful. Can you achieve the same somehow in Delphi?

Here it is https://github.com/pyscripter/Pcre-Jit-Delphi. Enjoy

@Mahdi SafsafiThanks!! Now it works in 32-bits as well. 32-bit benchmark Time | Match count ============================================================================== Delphi's own TRegEx: /Twain/ : 6.00 ms | 811 /(?i)Twain/ : 41.00 ms | 965 /[a-z]shing/ : 448.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 528.00 ms | 262 /\b\w+nn\b/ : 634.00 ms | 262 /[a-q][^u-z]{13}x/ : 543.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 896.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 1063.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 2980.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 3088.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 528.00 ms | 2 /[a-zA-Z]+ing/ : 918.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 548.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 775.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 312.00 ms | 8885 Total Time: 13321.00 ms ============================================================================== Delphi's own TRegEx with Study: /Twain/ : 6.00 ms | 811 /(?i)Twain/ : 40.00 ms | 965 /[a-z]shing/ : 318.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 24.00 ms | 262 /\b\w+nn\b/ : 619.00 ms | 262 /[a-q][^u-z]{13}x/ : 450.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 31.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 256.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 2875.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 2905.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 63.00 ms | 2 /[a-zA-Z]+ing/ : 829.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 569.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 685.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 56.00 ms | 8885 Total Time: 9746.00 ms ============================================================================== Delphi's own TRegEx with JIT: /Twain/ : 12.00 ms | 811 /(?i)Twain/ : 13.00 ms | 965 /[a-z]shing/ : 13.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 3.00 ms | 262 /\b\w+nn\b/ : 189.00 ms | 262 /[a-q][^u-z]{13}x/ : 154.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 22.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 64.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 371.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 497.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 12.00 ms | 2 /[a-zA-Z]+ing/ : 105.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 197.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 39.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 19.00 ms | 8885 Total Time: 1730.00 ms I will release it at Github (watch for announcement). Then @Kas Ob.you can try to get rid of __chkstk and see what happens.

@David Heffernan I explained why I am linking C code earlier... @Kas Ob.I would rather use the default options if I can. For example I am not sure of the performance implications of PCRE_NO_RECURSE. Now, if nothing else worked, I will try.

Well yes. I need a 32-bit __chkstk Here is the Visual Studio masm code page ,132 title chkstk - C stack checking routine ;*** ;chkstk.asm - C stack checking routine ; ; Copyright (c) Microsoft Corporation. All rights reserved. ; ;Purpose: ; Provides support for automatic stack checking in C procedures ; when stack checking is enabled. ; ;******************************************************************************* .xlist include vcruntime.inc .list ; size of a page of memory _PAGESIZE_ equ 1000h CODESEG page ;*** ;_chkstk - check stack upon procedure entry ; ;Purpose: ; Provide stack checking on procedure entry. Method is to simply probe ; each page of memory required for the stack in descending order. This ; causes the necessary pages of memory to be allocated via the guard ; page scheme, if possible. In the event of failure, the OS raises the ; _XCPT_UNABLE_TO_GROW_STACK exception. ; ; NOTE: Currently, the (EAX < _PAGESIZE_) code path falls through ; to the "lastpage" label of the (EAX >= _PAGESIZE_) code path. This ; is small; a minor speed optimization would be to special case ; this up top. This would avoid the painful save/restore of ; ecx and would shorten the code path by 4-6 instructions. ; ;Entry: ; EAX = size of local frame ; ;Exit: ; ESP = new stackframe, if successful ; ;Uses: ; EAX ; ;Exceptions: ; _XCPT_GUARD_PAGE_VIOLATION - May be raised on a page probe. NEVER TRAP ; THIS!!!! It is used by the OS to grow the ; stack on demand. ; _XCPT_UNABLE_TO_GROW_STACK - The stack cannot be grown. More precisely, ; the attempt by the OS memory manager to ; allocate another guard page in response ; to a _XCPT_GUARD_PAGE_VIOLATION has ; failed. ; ;******************************************************************************* public _alloca_probe _chkstk proc _alloca_probe = _chkstk push ecx ; Calculate new TOS. lea ecx, [esp] + 8 - 4 ; TOS before entering function + size for ret value sub ecx, eax ; new TOS ; Handle allocation size that results in wraparound. ; Wraparound will result in StackOverflow exception. sbb eax, eax ; 0 if CF==0, ~0 if CF==1 not eax ; ~0 if TOS did not wrapped around, 0 otherwise and ecx, eax ; set to 0 if wraparound mov eax, esp ; current TOS and eax, not ( _PAGESIZE_ - 1) ; Round down to current page boundary cs10: cmp ecx, eax ; Is new TOS bnd jb short cs20 ; in probed page? mov eax, ecx ; yes. pop ecx xchg esp, eax ; update esp mov eax, dword ptr [eax] ; get return address mov dword ptr [esp], eax ; and put it at new TOS bnd ret ; Find next lower page and probe cs20: sub eax, _PAGESIZE_ ; decrease by PAGESIZE test dword ptr [eax],eax ; probe page. jmp short cs10 _chkstk endp end

There are no conversions needed for Win64. For Win 32 I have the issue of windows calls (such as __imp__VirtualFree@12. Fortunately there is just one obj file that makes such calls and I will find a way to work around it (see earlier posts). Why not use bcc32c... I have only access to the free tools that only compile x86 code pcre has a number of configuration steps and options and cmake makes it very easy and convenient to automate everything. It would be very hard to do that manually correctly. cmake has a generator for bcc32c but is rather new and I am not sure how well tested that is. Saddly, I have more trust in the Visual Studio compiler, especially for code that requires stack checking. Does bcc32c do that? When I finish I will release the stuff at github, so people can take a look and make adjustments. Embarcadero can use their own compiler if they wish.

PCRE16. This is what Delphi uses and for a reason. It avoids conversions between delphi strings and PCRE strings.

I would prefer to not mess around with the c files and I think that pcre_jit_compile needs the stack checking anyway. Could anyone help translate the LLMV code to Delphi PLEASE? The prize is that everyone gets a much faster System.RegularExpressions and we may even convince Embarcadero to implement the changes which are really minor.

Use @David Heffernan trick mentioned above. It works fine. Your ld stuff does not appear to work with Visual studio object files (only gnu). I have tried /Gs1000000 but did not help. and yes I am aware of the other stuff you mention and can work around them.

In Visual Studio /GsX is the same as /GcX in other compilers. I am pretty sure: With the current __chkstk a crash occurs when this is called (debugging using the CPU window) Replacing that with linking VSs chkstk.obj works very smoothly

You are confusing /Gs with /GS https://docs.microsoft.com/en-us/cpp/build/reference/gs-control-stack-checking-calls?view=vs-2019https://docs.microsoft.com/en-us/cpp/build/reference/gs-control-stack-checking-calls?view=vs-2019 Already using /GS.

I have tried with /Gs9999999 which suppresses the stack checking but I still got crashes. I suspect that pcre needs the stack checking. Please note __chkstk automatically allocates stack if needed. ;_chkstk - check stack upon procedure entry ; ;Purpose: ; Provide stack checking on procedure entry. Method is to simply probe ; each page of memory required for the stack in descending order. This ; causes the necessary pages of memory to be allocated via the guard ; page scheme, if possible. In the event of failure, the OS raises the ; _XCPT_UNABLE_TO_GROW_STACK exception. ; I understand that a DLL is a safer and easier option, but this is meant to be an enhancement of System.RegularExpressions which uses static linking of obj files.

Firstly I would like to report that the above works fine. Thanks @Mahdi Safsafi With minimal changes to System.RegularExpressionsAPI only, I got PCRE JIT to work in 64 bits (haven't fully sorted out 32 bits but I now know how to do it thanks to @Kas Ob.). I had one issue related to this Stackoverflow question that was resolved using @David Heffernan simple trick (thanks). Was it worth my while? Judge for yourselves. Here are the results of my standard re benchmark: Time | Match count ============================================================================== Delphi's own TRegEx: /Twain/ : 6.00 ms | 811 /(?i)Twain/ : 45.00 ms | 965 /[a-z]shing/ : 450.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 455.00 ms | 262 /\b\w+nn\b/ : 680.00 ms | 262 /[a-q][^u-z]{13}x/ : 610.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 836.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 991.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 2755.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 3021.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 464.00 ms | 2 /[a-zA-Z]+ing/ : 805.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 563.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 837.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 321.00 ms | 8885 Total Time: 12853.00 ms ============================================================================== Delphi's own TRegEx with Study: /Twain/ : 6.00 ms | 811 /(?i)Twain/ : 49.00 ms | 965 /[a-z]shing/ : 318.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 21.00 ms | 262 /\b\w+nn\b/ : 586.00 ms | 262 /[a-q][^u-z]{13}x/ : 417.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 27.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 216.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 2607.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 2768.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 49.00 ms | 2 /[a-zA-Z]+ing/ : 758.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 565.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 654.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 50.00 ms | 8885 Total Time: 9108.00 ms ============================================================================== Delphi's own TRegEx with JIT: /Twain/ : 12.00 ms | 811 /(?i)Twain/ : 13.00 ms | 965 /[a-z]shing/ : 11.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 4.00 ms | 262 /\b\w+nn\b/ : 126.00 ms | 262 /[a-q][^u-z]{13}x/ : 169.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 22.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 63.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 273.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 334.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 12.00 ms | 2 /[a-zA-Z]+ing/ : 86.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 158.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 36.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 18.00 ms | 8885 Total Time: 1356.00 ms Almost a 10 fold speedup. Now here is my next question. System.RegularExpressionsAPI resolves the __chkstk dependency as follows. procedure __chkstk; asm end; This created all sort of unpredictable crashes. I am not sure whether the crashes were a result of lack of stack checking or a difference in the calling conventions or both. I had to resolve __chkstk by linking to chkstk.obj provided by Visual Studio, however this is kind of problematic because there are licensing issues and you cannot distribute chkst.obj. I have looked around and saw the the LLMV projects defines __chkstk as follows: // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. // See https://llvm.org/LICENSE.txt for license information. // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception #include "../assembly.h" // _chkstk routine // This routine is windows specific // http://msdn.microsoft.com/en-us/library/ms648426.aspx // Notes from r227519 // MSVC x64s __chkstk and cygmings ___chkstk_ms do not adjust %rsp // themselves. It also does not clobber %rax so we can reuse it when // adjusting %rsp. #ifdef __x86_64__ .text .balign 4 DEFINE_COMPILERRT_FUNCTION(___chkstk_ms) push %rcx push %rax cmp $0x1000,%rax lea 24(%rsp),%rcx jb 1f 2: sub $0x1000,%rcx test %rcx,(%rcx) sub $0x1000,%rax cmp $0x1000,%rax ja 2b 1: sub %rax,%rcx test %rcx,(%rcx) pop %rax pop %rcx ret END_COMPILERRT_FUNCTION(___chkstk_ms) #endif // __x86_64__ Any help in converting this to a Delphi assembler function would be highly appreciated.

Ssh-Pascal is a new free and open source library providing ssh support to Delphi, based on libssh2. Libssh2 is a mature ssh library used by PHP (built-in), Rust and many other languages and applications. Features: Extensive ssh features Support for different authorization methods (publickey, password, agent, hostbased and keyboard-interactive) Known host management. Execution of commands on the host capturing stdout and stderr Comprehensive sftp support Port forwarding (currently only local to remote) scp support High-level pascal-friendly, interface-based wrapping of ssh functionality. Lower-level usage is possible.

I also found FileBinReplace. (16K utility).

Does this EMB compiler not decorate the DLL imports? If say you add WinApi.Windows to your uses clause does it automatically fix resolve the symbols?

This is only relevant for calls to the C runtime. I am already doing that -DPCRE_STATIC_RUNTIME=ON Has the same effect (activates the /MT option)

Is there a long answer? Is there a way around it? I am desperate as you see. Is there a way to tell the C compiler not to add the decoration?

$addPath = 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin' $regexAddPath = [regex]::Escape($addPath) $arrPath = $env:Path -split ';' | Where-Object {$_ -notMatch "^$regexAddPath\\?"} $env:Path = ($arrPath + $addPath) -join ';' $pcrePath = 'pcre-8.44' Remove-Item –path $pcrePath –recurse Expand-Archive -LiteralPath $pcrePath'.Zip' -DestinationPath . copy CMakeLists.txt $pcrePath pushd $pcrePath cmake . -G "Visual Studio 16 2019" -A Win32 -DBUILD_SHARED_LIBS=OFF -DPCRE_BUILD_PCRE16=ON -DPCRE_BUILD_PCRE8=OFF -DPCRE_SUPPORT_UNICODE_PROPERTIES=ON -DPCRE_SUPPORT_JIT=ON -DPCRE_STATIC_RUNTIME=ON -DCMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH=OFF cmake --build . --config Release copy .\pcre16.dir\Release\*.obj ..\Source\obj\pcre\win32\ popd Using the above Powershell script if that matters. I have added the /GS- compiler flag to avoid further dependencies. FYI I am trying to compile PCRE with JIT support. This is what makes the Windows calls.

Also bugs reported as fixed are not fixed: RSP-29271 [DelphiLSP] Code Insight adds unneeded () when changing procedures/functions

Thanks for the info. I would like to link the object files into Delphi avoiding the need to deploy DLLs. It would be great if you were able to do this. This link shows how to use cmake to compile the dll with Visual Studio. The project also supports nmake. @Vincent ParrettYou appear to be the original author of System.RegularExpressions. How did you compile the C code of PCRE avoiding the need to bring in c runtime dependencies.

Putty splits the ssh functionality into different executables. ssh is provided by plink.exe. The project converted to a dll only psfpt.exe.