aehimself

So the layout is somewhat like this: Since I got lost somewhere, I'll start from the beginning. Do you have a FUNCTIONAL issue with the application now (meaning, not the warnings in the source but something not working / not working properly)? If yes, where? A bit off-topic: is there any particular reason why the packet verification resides in a DLL? If no other application is using it I feel like it only adds unnecessary complexity and points of failure (see one of my first replies about allocations).

Let's take one step at a time. String conversions (AnsiString vs. String) will only matter in data transfer / storage but as far as I understand, you can not even connect with your application. Is that right? I'm a bit confused. You said that TCP port 3000 is listening by your Python script...? Shouldn't your application be listening there (that's what TServerSocket does; it listens and accepts client connections)? Can you share some basic layout of your application? What is running where, what should connect where, etc.

Start your program. Click on Start, type cmd, press enter. In the appearing window, type netstat -ano | find /i ":3000" press enter. Anything shows up? We are still talking about the standard VCL application, right?

I personally use DCPCrypt and it indeed works on 64 bit applications. I compile the 64 bit DCUs, the 32 bit DCUs and install with a 32-bit debug flavor. For IDE instalation though, you MUST select 32 bit, as the IDE is 32 bit only and therefore you cannot install a 64 bit component.

You have to install the DCP components to Delphi so they show up on the palette and can be used on forms. If you have the .pas files, you can use them, but only runtime.

This is exactly how I am designing my service applications lately. I was talking about the current situation, where OP already has code on the form itself, not very comfortable with Delphi as a language and does not want to refactor - only to get it to work. Without a huge refactor you can not push the existing code to it's own class - you have to have your own message pump and a worker thread to run that message pump as a minimum (ClientSocket and ServerSocket both needs messages to operate). Yes, it is the elegant solution - write your code once, run it everywhere. This is the quick and dirty solution, which can be done without much proficiency.

Normally, changing the target platform is enough, but be careful to compile your DLL as 64 bit too! A 64 bit application cannot use a 32 bit DLL. That is unfortunately a different type of application. Now you created a "Windows VCL Application" and what you need it a "Windows service": You don't really have a choice than to create a new one and start copying your code. You also can try to "import" this form in the service application, and create an instance of it... it MIGHT work. But be aware, debugging a service application is usually a lot harder. You might want to implement proper logging for that.

P.s.: you also can remove the line 294: ServerSocket1.Open; .Open has no effect after ServerSocket1.Active := True; in line 232.

Remove ServerSocket1 from ALL sections before dropping one on your form.

Make sure your form is visible in the IDE (you are not viewing the source). Press Ctrl-Alt-P, start typing "ServerSocket" and then press Enter.

Ehm... In a good version, nothing will happen. In a bad version an AV upon closing the application. Either create it with (nil), or don't free it.

Yep, socket is not on the form therefore not created automatically. Delete the public declaration and drop one on your form. Edit: on newer Delphi editions TServerSocket and TClientSocket are not available on the palette by default. Do make them appear, go to Component -> Install Package, click on "Add..." and browse for $(BDS)\bin\dclsocketsXXX.bpl. Depending on your Delphi version, the XXX changes. On 10.4.1, my full path is C:\Program Files (x86)\Embarcadero\Studio\21.0\bin\dclsockets270.bpl After this, you can drop one on your form in Design time. Edit-Edit: If you are wondering, I think this is what happened. As I mentioned, designtime components are not available by default on newer Delphi editions. You started the source in Delphi, it warned you about a component which can not be found and you clicked on Remove. Now, the program would not compile as all ServerSocket1 references are invalid. Then, you manually declared it. The issue is, if it's not on the DFM it's not being created automatically for you.

Is the TServerSocket component placed on the form design time? Because it is in the declaration 3 times, 2 times commented out, finally placed in the "public" section: TfrmMain = class(TForm) ADOConnection1: TADOConnection; ADOQuery1: TADOQuery; //ServerSocket1: TServerSocket; // one occurrence private { Private declarations } //ServerSocket1: TServerSocket; // one occurrence public { Public declarations } ServerSocket1: TServerSocket; // final occurrence DCP_sha11: TDCP_sha1; DCP_3des1: TDCP_3des; end; I suspect it's not created automatically. Delete the component from the form, doublecheck that the public declaration is removed (if no, remove it manually) and put an other component on the form.

That line is a declaration, which is not executing under any circumstances. An AV can not occur there. The exception is thrown in SetPort: procedure TAbstractSocket.SetPort(Value: Integer); begin if FPort <> Value then begin if not (csLoading in ComponentState) and FActive then raise ESocketError.CreateRes(@sCantChangeWhileActive); FPort := Value; end; end; I start to wonder... is 0x40 low enough to be a nullpointer exception? Can you post your FormCreate code?

What methods is the DLL exporting - more importantly what type of parameters are being exchanged between the DLL and the EXE? If you are using PChars, doublecheck the allocation: instead of GetMem(pc, Length(inString)) you have to use GetMem(pc, Length(inString) * SizeOf(Char)) because of the Unicode difference @Angus Robertson mentioned. I can confirm that TClientSocket / TServerSocket works fine even in Delphi 10.3, with String or raw (binary) transfer as well - one of my applications were using those before I switched to ICS.

I faced this today and the fix is fairly simple. I recompiled VCL.Buttons.pas and now all font styling is working as expected. DIY: 1, Open up vcl.buttons.pas, after line 1715 insert: LCanvas.Font := Canvas.Font; 2, Go to C:\Program Files (x86)\...\lib\win32\debug, release, win64\debug, release and delete vcl.buttons.dcu 3, Fire up Delphi, create a new VCL application and drop a button on the form. Add Win64 platform, then build the empty application in Win32/Win64 Release/Debug. 4, Go to %USERPROFILE%\Documents\Embarcadero\Studio\Projects and copy the vcl.buttons.dcu from Win32/Win64 Release/Debug to your Delphi installations "lib" folder. Keep in mind that this is a modification of the local installation's VCL so it is machine dependent. You have to do this on every developer machine / build server you have. I have the modified source and the built DCUs but I don't know if I'm allowed to attach those here; so to keep it safe and simple, just follow these steps. Let's hope that this will get patched in the lifetime of 10.4.1. I doubt I can convince my boss to upgrade everything one more time.

@Daniel Did you try the built-in Windows 10 "Print to PDF" printer? Just a guess from the wild, have no idea if it supports FGL and Google was not so much of a help.

@emailx45

Which operating system are we talking about? 2 seconds sounds like the default DNS client timeout. Sometime around Windows 8 (needs clarification, I'm not sure), the following lines appeared in the Windows hosts file: # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost You can try to uncomment these and give an other try. It's possible that your DNS settings needs to be checked / updated.

But Frost is right about global variables. I would change this to... use them ONLY if you can not solve your issue without them. Edit: wtf spelling...?!

Strongly disagree. 10.4.1 is a lot more useable on our large project at work than any previous version was. Sure, it's far away from perfect, but it does not mean it's a "black hole". Tbh I was already shocked that inline variables will be added to the language. Was it community requested? Majority of the coders are staying away from it as far as I heard.

Off: That is some nicely commented code!

Doesn't this equal to a localized ANSI codepage...? In this case a solution would be to 1, Convert the underlying DB to UTF-8-16 and forget about encodings for a while 2, Change the access components to one which allows you to tell the RDBMS in what codepage string literals should be converted to before sending it to you - if Interbase supports this. Zeos has this and so does FireDac (as far as I see from Google). 3, Override the String field's OnGetText event and manually covert the byte array to a Unicode string on-the-fly 4, Feels a bit hacky but you also can go through all tables, read all string fields as a byte array, convert them to Unicode and put them back like that

Seems to be offtopic.

Good for a school project; I don't see any other purpose for applications which - mostly - do things what a built-in Windows command does. If a user doesn't know how to invoke them from the command line they most probably don't need / shouldn't use. Even I already used this in one of my applications I completely forgot about this. Yes, for finding your own software on a network segment UDP broadcasting is the way to go. I might be completely wrong on this one, but afaik broadcasts can not be relayed to an other subnet, though. Never tried it and didn't work with broadcasts since, so take this with a grain of salt.