This is a pretty much pointless task. A plain vanilla VCL forms application will load the system msvcrt library. Yes, this is a system library. It is distributed as a standard OS library. All systems have it. In that regard it is no different from user32, advapi and so on.
So, by removing the dependency that the regex code has on msvcrt will not make your program have any fewer dependencies. What's more, there's nothing to be afraid of in taking a dependency on a system library.
You might ask why a Delphi application has a dependency on msvcrt. It comes about because of this:
- The
WideString type is a loose wrapper around the system BSTR type.
- The implementation of
BSTR is provided by the oleaut32 library.
- A plain vanilla Delphi program, that uses no units at all, has a load-time dependency on
oleaut32 in order to provide, for instance,
SysFreeString.
- The oleaut32 library in turn has a dependency on msvcrt.
So, not matter what you do, you will not be able to remove the dependency on msvcrt.
However, to answer your question, because I enjoy answering questions, especially ones on linking compiled objects, here is what you need to do:
- Take a copy of
System.RegularExpressionsAPI.pas and place it in your project's source folder. Add it to the project. This is now the unit that the rest of the regular expression library stands on top of.
- At the top of the implementation section, remove the reference to
System.Win.Crtl.
- Compile your project.
You will find that the code will not compile, and gives the following errors:
E2065 Unsatisfied forward or external declaration: '_strncmp'
E2065 Unsatisfied forward or external declaration: '_memmove'
E2065 Unsatisfied forward or external declaration: '_memset'
E2065 Unsatisfied forward or external declaration: '_memcpy'
E2065 Unsatisfied forward or external declaration: '_memcmp'
E2065 Unsatisfied forward or external declaration: '_strlen'
E2065 Unsatisfied forward or external declaration: '__ltolower'
E2065 Unsatisfied forward or external declaration: '_islower'
E2065 Unsatisfied forward or external declaration: '__ltoupper'
E2065 Unsatisfied forward or external declaration: '_isdigit'
E2065 Unsatisfied forward or external declaration: '_isupper'
E2065 Unsatisfied forward or external declaration: '_isalnum'
E2065 Unsatisfied forward or external declaration: '_isspace'
E2065 Unsatisfied forward or external declaration: '_isxdigit'
E2065 Unsatisfied forward or external declaration: '_isgraph'
E2065 Unsatisfied forward or external declaration: '_isprint'
E2065 Unsatisfied forward or external declaration: '_ispunct'
E2065 Unsatisfied forward or external declaration: '_iscntrl'
E2065 Unsatisfied forward or external declaration: '_isalpha'
E2065 Unsatisfied forward or external declaration: '_strchr'
In order for the compiler to compile this unit, it must be able to resolve these symbols in the modified System.RegularExpressionsAPI.pas unit. Using System.Win.Crtl is what makes that happen in the plain RTL. If you want to avoid linking System.Win.Crtl then you need to provide implementations. For instance, here is _strlen.
function _strlen(P: PAnsiChar): size_t; cdecl;
begin
Result := System.SysUtils.StrLen(P);
end;
Add that to the modified System.RegularExpressionsAPI.pas unit and you've resolved the dependency. You now just need to keep doing that for all the others. This is regulation, link to compiled object fare.
But, as I have tried to make clear, I would not recommend doing this. You are creating work for yourself that will bring no discernible gain. You'll end up with even more code in your program than before. And there's every chance that you'll make mistakes implementing these C runtime functions. You'll invest a whole heap of time, and end up with a program that is worse than what you have now.
