DelphiUdIT

From the IDE: Bye

Is not a normal DLL is a COM object. This is a type library definition (you can make your own with IDE). Bye WINSATLib_TLB.pas

Win32_WinSAT class Article 12/12/2020 2 minutes to read [Win32_WinSAT may be altered or unavailable for releases after Windows 8.1.] <-------------------------------------------

I never use a DOCKER, I always used normally operating surface and the only things that you need are the two .so libraries x Linux. In one of my original projects, I used the standard Indy release with the Delphi, the libraries that I had are 1.0.2u (Linux 64 bit) but the names exposed are: libcrypto.so.1.0.0 libssl.so.1.0.0 I don't remember why (it happened 2 years ago) but i had also in the same directory the binary copy of the libraries with these names (and that i think was for Indy link); libcrypto.so libssl.so If you have your Linux app, these libraries and optionally the .pem certificates you server must works. You don't need other things. Bye

May be you mean: var tempointer: Pointer; tempointer := Combobox1.Items.Objects[Combobox1.ItemIndex]; Combobox1.ItemIndex := Integer(tempointer^); But even if this is correct, the starting point is incorrect: PAY ATTENTION: SqlQuery1 I think dynamically allocates Fields[1] and therefore your POINTER will be invalid after a new QUERY is executed. The pointer used with the AddObjects function should be permanent and "last" for the entire existence of the program (until you know what you are doing ) Bye

This might be "OT", but just one piece of advice I want to give to @shineworld In general, expressly if commands are given to automations, the software (see for example SCADA) requires an authorization level. These levels are normally kept inside a server-side db and have nothing to do with PC users, Windows users, Linux users, etc ... So in the end, in your client communication you could simply enter a name / password that the server program will validate among those in the archive to validate the request. You wouldn't need anything on the client side other than this data pair. If a command is executed, the operator enters this pair by hand and the client sends it to the server together with the command, if instead a status request is executed it could also be that the client sends a hardcoded name / password by default. Of course the server must validate the couple of auth to actuate the request. The communication between client and server (and vice versa) remember that it is always encrypted if you use TLS. Bye

These not resolve other question about i wrote: where and how you maintain the couple of accounts right (Username / Password) to impersonate the user of the "cert store" ? ..... like I told another level of crypto .... This is a non sense for a simple TCP / IP communications: client with a "hidden" user that should have a "certificate" in personal windows store (with private key and a password for that) and a crypto for username / password of hidden user ... I don't think a sysadmin of any company would agree to such a choice: i asked to 3 company one little, two big, of course in private and unofficial conversation and they negate these approach. All three would impose the use of the supplied USB stick on all their staff, or in second hand the registration of the software (this last would be my preferred solution). This choice depends on whether the application is autonomous (for example the customer launches it and then it must "run" as long as the customer is logged in) or if it is launched in autorun when the customer logs in and runs without particular interactions with the 'user. But we are in a free world and everyone is free to make their own choices. The important thing is to continue to offer solutions. @shineworld talks about TCP / IP communications with is "proprietary protocol" and not about HTTP. Using Http is another question. Bye

It would be a good idea but there are two problems: 1) Create a different user (different from an administrator user and from the user where the application runs) on all the machines where the application runs ... I see it as a real complication for management and maintenance. And in any case the credentials to impersonate the user must be "hard coded" in the program or in an external file, therefore local encryption ... at this point it is better to locally encrypt the direct access credentials to the server or directly the certificate files. .. but it doesn't make much sense, you just lengthen the chain and don't solve the underlying problem; 2) Indy does not support access to the Windows Cert Store ... at least as far as I know, until the keys are exportable .... Bye

A reflection on the discussion and on the concepts of "trusted". If by trusted it is meant that the connection between the client and the server is practically secure and that the client knows who the server is, then the concept of trusted is verified with the use of a server-side certificate (possibly issued by a recognized certifier and not by a self-signed certificate) and an encrypted connection via TLS, and that's what the example I posted does. But if we expand the concept of trusted, as I think @shineworld intends, then it is more complex to apply it. The "expanded" concept is that the connecting client is known and certified as if it were a server. A standard certificate (similar to that of the server) on the client side is not applicable because the files are exposed, especially the private key even if protected by a password, and anyone who can access the station could "copy" it. A solution would be a "hardware" certificate (as in a USB token), but it is not an economic solution and there is a fairly important management for the tokens: it must be said that many private companies and all public companies have by now equipped employees with a USB token or similar (token like credit card, etc ....). Other easily applicable solutions are then: apply the concept of "registration": at the very first connection (client installation) the client sends runtime data to the server (date and time of installation, processor UUID, etc ....) which the server registers (with its own coding ) and will use to test future connections. The client will send this data at each new connection and the server will refuse the connection if they are not included in the list of already registered clients. OBVIOUSLY THESE DATA MUST NOT BE DISCLOSED, IE MUST NOT PUBLICLY KNOW IF AND WHAT THE CLIENT SENDS TO THE SERVER (otherwise it is enough for a fake client to replicate the data of a real client to replace itself). apply the classic concept of username / password, but it makes sense if the entry is done by operator, if it has to be automated it means that username and password must be stored locally .... so other local encryption, .... etc ... . Bye

I post a simple TCP sample using SLL (TLSv1_2). It's only a little start point, but may help you. Inside there are the OpenSSL Win64 dll 1.0.2u and one certificate self signed valid for one year (localohst, 127.0.0.1). There is also a DHParam file used for DH "chiper" protocol, not necessary and not used. From there you can improve security, authentication, etc .... Bye TCPS Demo.zip

With this configuration (see libcrypto. so path for example ) you will load your OpenSSL libs.

In the past surely not. I always used "mine" libraries. Of course there are issues with versions (1.0.x, 1.1.x, 3.0.x), so it's best to distribute your own anyway. Bye

Really interesting, knowing if a file is already in use by another application via an api instead of trying to open it and manage the error (without knowing "who" is blocking it anyway) is very useful in some scenarios. Bye

With respect to your request, and speaking of databases, I've honestly never heard the concepts of UNDO / REDO but the concepts of COMMIT / ROLLBACK. All databases support the concepts of TRANSACTION / COMMIT / ROLLBACK. The main difference between theoretical and practical use is defined by both the DB used and the component used to manage the database (e.g. FIREDAC, ZEOS, ADO)..... I've never used Interbase, but I've used FireBird even if not "heavily" and the TRANSACTION support from the DB is complete and it's multi-user with the possibility of setting the LOCK resolution mode. Now I don't remeber if FIREDAC supports transactions at DB level (therefore multiuser, auto lock, ....) or at connection level (1 transaction for each connection, therefore not native multiuser). ZEOS only supports connection-level transactions, therefore 1 ACTIVE TRANSACTION for each connection, no concurrent multi-user. EDIT: my fault, there is no concurrent MULTI TRANSACTION with same client side application. Means that only one sql editing instruction (for example) = one transaction may be in use concurrently in that client side app. MULTIUSER from different client is always possible and even with multiple database connections, multiple concurrent transactions can be made. In any case the solution can be using only the transactions, and this is expressly true if there is multiuser. The resolution of inconsistencies, locks and all other problems is very complex and cannot be solved "manually" at the application code level. This is the page for the FireBird documentation, where the mechanisms of LOCK, TRANSACTION, COMMIT / ROLLBACK are explained very well. Bye P.S.: of course, a careful design of a database is always necessary, regardless of the use of TRANSACTIONs.

I saw, but the main loop should be ... A LOOP .... and in a console app there aren't so many variants .... It simply instantiates all objects at runtime (the graphical application you see instantiates everything at runtime, it's just for convenience and debugging that there is a graphical window). In the main loop you can do: var EndLife: boolean; begin EndLife := false; // Runtime object creation // End {$IFDEF POSIX} //is used to intercept the CTRL-C, in order to terminate the program correctly sigIntHandler._u.sa_sigaction := @my_handler_ctrl_c; sigemptyset(sigIntHandler.sa_mask); sigIntHandler.sa_flags := SA_SIGINFO; sigaction(SIGINT, @sigIntHandler, 0); {$ENDIF} while not EndLife do begin //In here you can put for example a WAITFOR with 100ms timeout, you can update a log file, send an I'M ALIVE, capture a variable to stop / start the web server ......... end; // Runtime object destruction // End end; //Capture CTRL-C, CTRL-BREAK, LOGOFF, SHUTDOWN, CLOSE ... events. I DIDN'T TEST THEM !!! {$IFDEF POSIX} procedure my_handler_ctrl_c(segnale: integer; segnale_info: Psiginfo_t; context: Pucontext_t); begin //writeln('Caught signal ', segnale); EndLife := True; _exit(1); end; {$ENDIF} These are simply an advise, i don't test it but i think may be a start point. Bye

May be yes, there are some significant differences .... first of all the use of pointers directly ...... these means that the errors are no so clear. If you use the normal array definition you get "Range check Error" instead of "Segmentation error"... isn't this enough? And in general, unless there are speed or interfacing problems with particular APIs, why use direct memory management in PASCAL? In all my life as a programmer I have no memory of having directly used GetMem in PASCAL, I have never felt the need (but I have programmed parts of code in assembler). If I have to interface with "something" that can't be handled in Pascal, I create a DLL in "C" and work them with the "C" style. But of course everyone is free to act as they wish, fortunately. Mine was advice. Bye

I don't use cosole application, i use a graphic (FMX) application (based on Indy demo). This is for ease of use only. In fact, the FORM does nothing except handle events and start / stop the server. All LOGs are sent to the console via writeln. Exact same thing in Linux. Now with TLS 1.3 support Bye P.S.: There is one flaw in certificate management, which is that the certificate's private key must be exposed and accessible to the application. This may be a vulnerability if the server is accessed locally by third parties.

When you use getmem, in general, you are given a virtual memory address expressed in this form: xxxx:0, whose length depends on how many bytes you allocate. If for example if you allocate 1000 bytes it will be: xxxx:0 - xxxx:999 Where xxxx is called segment. If you try to use xxxx:1000 you exit the memory segment and the segm "segment" error is thrown. This is a HARDWARE protection mechanism and you can do nothing to avoid it. I repeat, avoid using the logic of the "C" language and use the form and rules of "Pascal", they will help you avoid these errors. HI.

As mentioned in a previous post, I use classic (raw) UDP communication because Thethering is not normally supported in the industrial environment. To give an example of UDP performance and reliability (in this context, it may not be appropriate for other applications), I explain an application developed and in operation with 20 plants in operation for 5 years (some for 5 years, some for 1 year). The software runs on a PC with 3 x 1Gbit network cards and a USB / GigaEthernet adapter. There are 6 to 18 devices connected to the local network and they use only UDP communications. The average traffic on the various PC network cards is 150 Mbit to 750 Mbit per card. The PC software to trigger the devices (basically cameras) transmits between 500 thousand and one million UDP packets (for synchronization only) per day (10 / 12 hours of continuous work 7 days a week). If even one packet is lost the trigger chain stops, the plant stops, a log is updated and an email is sent to me to report this. In all installations, in all these years it has never happened that a UDP packet has been lost. Of course, all the hardware has been designed to ensure maximum reliability, starting from the power supply and network components such as switches. Creating a reliable network using UDP is possible in certain scenarios. Bye

1) It depends on how the COM Server is built: from Windows 7 onwards any application that works as a service cannot have ANY REFERENCE to graphic objects of any type or kind nor access to the graphic surface (obviously not even as an indirect reference). The only exception is to show a "message" window, even before logging in with a specific API. A service cannot launch a "normal" COM, ie which refers to graphical parts, but it can dialogue with a COM object already "running". I dont' know if the last implementation something is changed (is a lot of years that i don't develop COM object) As @david-heffernan mentioned, the COMs can be used even without registration using the sXs technology, basically a Windows Manifest describes it (but it can be used only and exclusively if the COM is built as "inprocess" and this is not compatible with a windows service). Now, the references I had for using this technology (which doesn't use .NET components) are no longer available. 2) Preventing multiple instances of the same application is simple to implement. And if you want to prevent multiple unwanted parallel "tasks" from being executed, for example The service might pause (almost) when it detects the GUI executable (after it has done all its operations). However, the interaction mechanism between a Windows service and an EXE application is relatively simple. 3) For multiprocess communication I always use TCP communication (Indy components like TIdTcpClient / Server) and sometimes (actually very often in industrial applications) I use UDP in BROADCAST.

Answering your question is very difficult. It all depends mainly on what the final goal of the application is and how the various processes are imposed on you. What is the infrastructure available (local computation, cloud, distributed computing)? Will the image acquisition be synchronous or asynchronous, will they be serialized? Does the application prioritize speed? Etc .... Bye

As @PeterBelow wrote to you, what you indicated can be written more simply, readably and effectively in Pascal. It looks like you're writing "C" code. Just in case, to explain better you can write this code which allows you to: 1) In case of fixed extensions, to avoid some errors because they are already checked during compilation; 2) However, in case of errors (as in dynamic extensions), much clearer errors will be generated (erange errror: "Range Check Error"); 3) You can use the Low, High methods to automatically limit the cycles to the maximum extent of the arrays, avoiding the risk of "overshooting" the limits. //Static array var ballnumber: array [0..6999] of byte; i: integer; begin for i := Low(ballnumber) to High(ballnumber) do ballnumber[i] := 5; end; //Dynamic array var ballnumber: array of byte; i: integer; begin try SetLength(ballnumber, 7000); //<----Like GetMem for i := Low(ballnumber) to High(ballnumber) do ballnumber[i] := 5; finally SetLength(ballnumber, 0); //<---- Like FreeMem end; end;

I used two standalone Indy web server (https): one in a Linux server and one in a Windows 11 system. The web servers (Linux and Windows are the same, simple compiled for different OS) use a TLSv1_2 secure connection and were tested in one year with direct public connection without any filter. SSLLabs (SSL Labs - Test SSL web server) give a valuation of "A" grade to the web server. Tipically every day the application registered 1 thousand of attack, some are simple scanners like others are trying to violate the server. The web servers never went down. With new processors and systems, the number of the Threads is not a problem. I think that Indy is more than mature to use in a production enviroment. Bye

This is the version of the arm 64 (arm64-V8a). The others should be the same. Fips means that are compiling with some cryptography function ? I thought fips modules could only be compiled with OPENSSL 3.

I have the *.so OpenSSL 1.02 library for all Android SO (x86, x86_64, V7a, V8a) ... they are all date 14/06/2022 and may be the version is 1.02s I really don't know where i found them, and since I also use Indy SSL I researched all libraries for all supported systems. Like i told, I don't know who "create" the library but I used them and no problems were found. Bye openssl-1.02_Android.zip