Anders Melander

How is it disingenuous? I'm stating pretty clearly that I believe it's an amateurish approach. A professional would look at the problem and then think about how best to solve it within the given constraints. The problem with ChatGPT is not the quality of the code. The problem is that you're delegating the most important element of software development, namely design and architecture, to a construct that has no grasp of these concepts. But okay, what do I know.

AVX-512... Risky (performance-wise) - unless you know exactly what hardware you're running on.

Once again, it's just a party trick; A complete waste of time. What's demonstrated here is not how a professional solves a problem. If you're lucky the generated code is one possible solution, but regardless of how correct the code is there's almost no chance of it being the best solution to a given problem.

Yes

I have not been able to reproduce the problem using the supplied DLL and host source. Compiled with Delphi 11.2 targeting both 32- and 64-bit. Virtual memory, private bytes, working set, and handles were stable. No leaks were identified. I suggest you test it on a clean system (or do a secure boot) to ensure that stuff isn't being injected into your process (e.g. via HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs).

Keep a reference to the thread when you create it. Use TThread.Terminate to terminate it and use TThread.WaitFor to wait for it to actually terminate.

I agree that this is the better approach. Just remember to signal the thread to terminate (and wait for it to do so) when the service is stopping. Also, note that in the case of a COM-server-in-a-service there might not be a need for a separate thread since each COM connection will get its own thread anyway, depending on the apartment model used.

Just so you know, while all the code in this thread might be fine for "I'm a hobbyist and I don't know what the hell I'm doing"-level programming, it's nowhere near the best or correct way to solve your problem. With that said, the reason you're losing transparency is that you are operating on the rendered visual representation of the image. Therefore the transparency has been replaced with a background color. In order to resize a PNG without losing transparency you will need to use a method that supports alpha transparency. This means: Convert the PNG to a 32-bit RGBA bitmap. Resample (resize) this bitmap to the desired size. Convert the bitmap to PNG. There are various libraries that can do these steps for you. For example Graphics32 and probably also Image32. I'm guessing Image32 will probably be the easiest for you to understand.

It's not clear where the code you posted is located but regardless, exceptions inside TServiceThread.ProcessRequests are caught and handled (logged) there so they won't propagate to your handler. If you need to catch unhandled exceptions on the service level you should create a custom TServiceApplication and override the DoHandleException method. By default, it logs exceptions to the event log but you can change it to do whatever you need. This is what it would look like in Delphi: program ServiceProject; uses Vcl.SvcMgr, MyUnit in 'MyUnit.pas' {MyService: TService}; {$R *.RES} type TMyServiceApplication = class(TMyServiceApplication) protected procedure DoHandleException(E: Exception); override; end; procedure TMyServiceApplication.DoHandleException(E: Exception); begin ...whatever... end; begin // Get rid of TServiceApplication... Vcl.SvcMgr.Application.Free; // ...and use our custom service application class instead Vcl.SvcMgr.Application := TMyServiceApplication.Create(nil); // Usual service code follows... if not Application.DelayInitialize or Application.Installing then Application.Initialize; Application.CreateForm(TMyService, MyService); Application.Run; end.

That method only applies to MS Office (Word, Excel, etc). AFAIK this is the only keyboard method that works universally: In the registry, under the HKEY_Current_User/Control Panel/Input Method, set the EnableHexNumpad value to "1" (it's a REG_SZ value in case you need to add it). Press and hold the Alt key. Press the + key on the numeric keypad (I hope you got one 🙂 ). Type the hexadecimal unicode value. Release the Alt key.

Okay so I've looked into this some more and I've got good news and bad news: The bad news is that this is probably "as designed". The good news, well I lied; There isn't any good news. If we look at other thread pool implementations "properly designed by skilled practitioners", the old Win32 thread pools also had a hard upper limit on the number of threads in a pool and suffered from the exact same problem. The newer Vista thread pools are a bit more clever but it still has an upper limit (I believe the default max is 500 threads) and suffered from the exact same problem. Same with .NET thread pools (which are a rewrite of Win32 thread pools); For CLR 2.0 the max is 25 threads per core and for 2.0SP1 the max is 250 per core. The reason for this tenfold increase in default max is actually to avoid experiencing deadlocks caused by running out of threads quite so often. Thus .NET too suffers from the exact same problem. See Concurrent Programming on Windows, chapter 7 for a discussion on all this. So the problem is that the RTL thread pool imposes a hard upper limit on the number of threads in it and that the limit is way too small. Ideally what we'd like, in this case, is for the growth algorithm to be a bit more intelligent and flexible but I doubt that will happen. The easy solution is probably to just increase the max and hope for the best 😕 . I still believe that the library should detect (and fail on) the simple case when all threads are blocked waiting for a thread to become available. It's relatively unlikely that this will occur in real code (there are many other things, not controlled by the PPL, that a thread can wait on) but it's so simple to implement that I believe it's worth the effort.

That was really helpful. Thanks. If you view the PPL as an opaque general-purpose library then documentation will not help. Even if the problem/limitation is known by the user of the library, its existence means that the PPL can only be used when running on known configurations (# of CPUs) and cannot safely be used with other libraries that might also use the PPL. In other words: It's a bug; The situation should either be handled or it should fail with an exception. As far as I can see the concrete problem is in TParallel.ForWorker64 on the statement RootTask.Start.Wait. All the inner loop tasks are hanging there, waiting for their code to execute, but since all threads are occupied (by the outer loop tasks), none will ever become available. Deadlock. This situation should be detectable and I think a simple solution would be to temporarily increase the size of the threadpool when it occurs. For example in TThreadPool.TThreadPoolMonitor.GrowThreadPoolIfStarved.

Yes; That's what I wrote. procedure InjectMyForm(HandleOfControlOnPropertyPage: HWND; MyForm: TForm); begin SetParent(MyForm.Handle, HandleOfControlOnPropertyPage); ...lots of stuff to do with positioning and window style... end;

I can't see any way to create a property sheet without using a dialog template. Maybe you can just use an empty dialog template and then inject your Delphi form when the page is displayed?

...and now I can again. Race conditions. Pfft! 🙂

...and now I can't. I tried debugging it and the IDE froze. After a restart of the IDE I can't reproduce it anymore.

Reproduced. Delphi 11.2, 32- and 64-bit 4-core CPU.

Everything you need is available through the COM+ Tracking API. If you just need the statistics you will probably need to use the IGetAppTrackerData interface.

I can confirm that there are no errors in the res file. This is because Delphi will generate the "default" res file thus overwriting your custom one. The default res file is the one referenced by the directive "{$R *.res}". I suggest you name your res file so it doesn't conflict with the default project res file. I also suggest you either remove the MAINICON icon from your res file or delete the "{$R *.res}" directive. Otherwise, you will get a duplicate resource warning (because the project res file also contains a MAINICON icon) and the linker will have to discard one of them. With regard to "RLINK32: Unsupported 16bit resource in file" it could be many different things that cause this and without knowing exactly what your rc file looks like it's impossible to guess which one it is. You could try making sure that the rc file is in UTF-8 format.

Post your RES file. The fact that PEResourceExplorer can read it is no guarantee that it is correct. You might also try using the SDK resource compiler instead of brcc32 (which has known limitations). You can select the RC compiler to use in the project options.

One compiles a 32-bit application, the other a 64-bit.

ChatGPT, is that you? Okay, now I've had too much coffee.

WOW, indeed 🙂 Your subconsciousness at work.

https://learn.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector