![Delphi-PRAXiS [en]](https://en.delphipraxis.net/uploads/monthly_2018_12/logo.png.be76d93fcd709295cb24de51900e5888.png){kind=logo}
pyscripter
-
Content Count
788 -
Joined
-
Last visited
-
Days Won
43
Posts posted by pyscripter
-
-
-
@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 msI will release it at Github (watch for announcement). Then @Kas Ob.you can try to get rid of __chkstk and see what happens.
-
1
-
-
3 hours ago, pyscripter said: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.
@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.
-
2 minutes ago, Mahdi Safsafi said:Good luck ! if you need some help let me know.
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
-
19 minutes ago, Mahdi Safsafi said:From what I understood from your comment, you're going to compile using MSVC and then use some tools to convert the output ? why not give bcc32c a chance ? if it does not work ... you can simply use plan B.
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.
-
Just now, Kas Ob. said:@pyscripter Out of curiosity, why are you suing 16bit version of pcre ?
Are 8bit and 32bit slower than 16bit ?
The sum size of 32bit obj's is 380kb -DPCRE_BUILD_PCRE32=ON -DPCRE_BUILD_PCRE8=OFF
while the sum size of 16bit obj's 409kb -DPCRE_BUILD_PCRE16=ON -DPCRE_BUILD_PCRE8=OFF
PCRE16. This is what Delphi uses and for a reason. It avoids conversions between delphi strings and PCRE strings.
-
27 minutes ago, Mahdi Safsafi said:The ___chkstk_ms function that you post is incomplete !!!
ja 0x2b is jumping to some location that is not with function body ! Perhaps DEFINE_COMPILERRT_FUNCTION is doing something here.
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)
Anyway I compiled (using CLANG) a simple c code that I tweaked to use chkstk. and then I dumped the function and edited it to be compatible with Delphi :
procedure chkstk(); asm .NOFRAME sub rsp, $10 mov [rsp], r10 mov [rsp+8], r11 xor r11,r11 lea r10, [rsp+$18] sub r10,rax cmovb r10,r11 mov r11, qword ptr gs:[$10] cmp r10,r11 db $f2 jae @@L1 and r10w,$F000 @@L2: lea r11, [r11-$1000] mov byte [r11],0 cmp r10,r11 db $f2 jne @@L2 @@L1: mov r10, [rsp] mov r11, [rsp+8] add rsp, $10 db $f2 ret end;
That works and produces the correct results!! Thanks. So win64 is complete and I will now try to get win32 right.
I would love to know what this function is doing though... What I understand is that it just "touches" the stack and if an _XCPT_GUARD_PAGE_VIOLATION error occurs the OS traps that and grows the stack. In the event of failure, the OS raises the _XCPT_UNABLE_TO_GROW_STACK exception.
Sounds like magic. -
12 minutes ago, Kas Ob. said:ou can turn stack probes on or off by using the check_stack directive. /Gs and the
check_stackpragma have no effect on standard C library routines; they affect only the functions you compile.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.
-
5 minutes ago, Fr0sT.Brutal said:The main issue I hadn't solved is a specific order of linking obj's when they have wide dependencies on each other. Probably "ld -relocatable .\ReleaseDLL\SomeDir\*.obj -o OneObj.o" would help
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.
-
6 minutes ago, Mahdi Safsafi said:Yes disabling stack check will not suppress ___chkstk_ms. Only /GcX will do provided that this option is supported by your compiler and X is higher than probe size.
Now. are you sure that the crash comes from ___chkstk_ms ? also have you disabled other runtime check ?
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
-
5 minutes ago, Kas Ob. said: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.
-
8 minutes ago, David Heffernan said:Just compile the C++ code with options that suppress stack checking.
Seriously though, putting all this in a DLL is a far better approach.
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.
-
On 7/23/2020 at 3:17 AM, Mahdi Safsafi said:Yes this is correct. and it has a lazy form too :
const __imp_VirtualAlloc: Pointer = @VirtualAlloc; __imp_VirtualFree: Pointer = @VirtualFree;
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 msAlmost 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.
-
-
5 minutes ago, Mahdi Safsafi said:Now to your linking issue. your best choice is to use a dll. If that is not an option, you can compile your c code for x86 using bcc32c and link the output with delphi. I did this several time and it works. EMB offers c/c++ compiler tool chain at no cost (only for x86). https://www.embarcadero.com/free-tools/ccompiler/
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?
-
5 minutes ago, Kas Ob. said:Here an SO question and answers for https://stackoverflow.com/questions/5159353/how-can-i-get-rid-of-the-imp-prefix-in-the-linker-in-vc
most likely the third answer is the solution you are looking for, if didn't work then try other answers.
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)
-
10 minutes ago, Remy Lebeau said:Short answer - no
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?
-
10 minutes ago, David Heffernan said:How did you compile the C code?
$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.
-
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?
-
Also bugs reported as fixed are not fixed:
RSP-29271 [DelphiLSP] Code Insight adds unneeded () when changing procedures/functions
-
On 7/12/2020 at 9:53 AM, Kas Ob. said:is the case is to only build libssh2 without OpenSSL, or libssh2 be linked as object files directly into Delphi not using DLL
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.
-
5 hours ago, Edwin Yip said:I guess it's quite easy to also add SSH functions because the header's already translated
Putty splits the ssh functionality into different executables. ssh is provided by plink.exe. The project converted to a dll only psfpt.exe.
-
1
-
-
7 minutes ago, Edwin Yip said:to hear about your options
I guess you mean opinions 😀.
I was not aware of tgputtylib, but it is commercial and only covers sftp.
The other options had reasonable sftp functionality (however no handling of ~ in paths) but
- were based on old versions of libssh2
- had numerous C to Delphi translation issues especially related to 64bits that needed fixing
- did not provide for remote execution of commands and port forwarding which was important to me and fundamental part of ssh.
-
Help wanted:
libssh2 can be compiled so that it uses Windows CNG instead of OpenSSL, thus avoiding any dependence on other dynamic libraries. I wonder whether it would be possible to compile it into C obj files that can be linked into the Delphi executable. This would simplify the deployment greatly.
Any help on this would be greatly appreciated.
-
1
-
Is quality.embarcadero.com down?
in General Help
Posted
I am not able to login for some reason.