DelphiUdIT

Why ? https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setprocessinformation https://learn.microsoft.com/en-us/answers/questions/4052040/efficiency-mode-causing-performance-issue This come from FireFox, and it's the UNIQUE in my 260 processes and 5000 Thread that go in a efficiency mode alone .... No other process known go in that mode, except if you force it with Task Manager. It is at "firefox-release\hal\windows\WindowsProcessPriority.cpp", you can translate in Delphi.

You can try this, derivated from Learn Microsoft - EcoQS and updated for Delphi (sorry for errors): //I use _my to discriminate from bundle definitions uses WinApi.Windows; //Add this to uses unit type ///<summary>Documentation: https://docs.microsoft.com/windows/win32/api/processthreadsapi/ne-processthreadsapi-process_information_class</summary> PROCESS_INFORMATION_CLASS_my = ( ProcessMemoryPriority, ProcessMemoryExhaustionInfo, ProcessAppMemoryInfo, ProcessInPrivateInfo, ProcessPowerThrottling, ProcessReservedValue1, ProcessTelemetryCoverageInfo, ProcessProtectionLevelInfo, ProcessLeapSecondInfo, ProcessMachineTypeInfo, ProcessInformationClassMax ); type _PROCESS_POWER_THROTTLING_STATE = record Version: ULONG; ControlMask: ULONG; StateMask: ULONG; end; PROCESS_POWER_THROTTLING_STATE = _PROCESS_POWER_THROTTLING_STATE; PPROCESS_POWER_THROTTLING_STATE = ^PROCESS_POWER_THROTTLING_STATE; const PROCESS_POWER_THROTTLING_CURRENT_VERSION = 1; PROCESS_POWER_THROTTLING_EXECUTION_SPEED = $1; //Redefine API function SetProcessInformation_my(hProcess: THandle; ProcessInformationClass: PROCESS_INFORMATION_CLASS_my; ProcessInformation: Pointer; ProcessInformationSize: DWORD): ByteBool; stdcall; function SetProcessInformation_my; external kernel32 name 'SetProcessInformation' delayed; implementation {$R *.fmx} function SetEfficiencyMode(PID: DWORD): Boolean; var hProcess: THandle; PowerState: PROCESS_POWER_THROTTLING_STATE; begin Result := false; hProcess := OpenProcess(PROCESS_SET_INFORMATION, False, PID); if hProcess <> 0 then begin ZeroMemory(@PowerState, SizeOf(PowerState)); PowerState.Version := PROCESS_POWER_THROTTLING_CURRENT_VERSION; PowerState.ControlMask := PROCESS_POWER_THROTTLING_EXECUTION_SPEED; PowerState.StateMask := PROCESS_POWER_THROTTLING_EXECUTION_SPEED; Result := SetProcessInformation_my(hProcess, Process_Information_Class_my(ProcessPowerThrottling), @PowerState, SizeOf(PowerState)); CloseHandle(hProcess); end; end; procedure TForm1.Button1Click(Sender: TObject); var Success: boolean; begin Success := SetEfficiencyMode(GetCurrentProcessId); if Success then ShowMessage('Efficiency mode activated successfully!') else ShowMessage('Error activating efficiency mode.'); end;

You can use WINMD or better this https://www.winsoft.sk/win32api.htm to get the update informations that you need. (EDIT: the link is taken from some topic of this forum) By now, I know little bit, seems that Microsoft is still working on this and the things will change (like an extensions of API function). For example the new definition of PROCESS_INFORMATION_CLASS is: PROCESS_INFORMATION_CLASS = ( ProcessMemoryPriority, ProcessMemoryExhaustionInfo, ProcessAppMemoryInfo, ProcessInPrivateInfo, ProcessPowerThrottling, ProcessReservedValue1, ProcessTelemetryCoverageInfo, ProcessProtectionLevelInfo, ProcessLeapSecondInfo, ProcessMachineTypeInfo, ProcessInformationClassMax ); A little bit different from old one.

Try this. The DLL is present, but you can build the project, and then simply run directly from terminal line this (you must be in the path where the DLL is present): RUNDLL32 d.dll,Start Pay attention that you MUST CHANGE THE PATH AND THE FILENAME LINKED IN THE SOURCE, if you want that the link open the right file. NOTE: In the other console windows that should open, is going to be printed the path of the LNK file. Fucking DLL RUNDLL32.zip

Hello, first of all is better that you tell us what do you expectt from the runing DLL (e.g. found a LNK file in .....). I think there is some issues about your knowledge (I talk about Windows 11). If you run from a cmd prompt a RUNDLL32, the HOMEPATH you refer is "C:\Users\YOUR ACCOUNT NAME\AppData\Roaming" So, here is where the LNK file is created. And it is always created. About the pointed link file (JPG): this file, without none path should be under UNKNOWN PATH. So the file will never be linked. If you comile and run like an EXE instead, the path where the JPG file is "linked" is in the same directory as exe is. The DLL works perfect as expected. Notes: 1) Like I wrote before, you should PUT the "Timer1.Enabled := False;" at the begining of the event procedure. 2) Is missing the "CoInitializeEx(nil, COINIT_MULTITHREADED);": without that the CreateComObject will fail.

Unless the application is critical to runtimes, the best approach is to focus on timing, code readability, and flexibility. Specifically, break long code into shorter chunks, passing few parameters so as to use only the CPU registers. Use the INLINE directive so that the code can be compiled by "including" it directly in the caller (in this case, the resulting executable will be larger but faster). You can also write parts in assembler to further optimize speed. Be aware, however, that this requires a thorough understanding of the topic and, above all, always provide a Pascal alternative in case the assembler isn't suitable for the processor used at runtime (e.g., Intel vs. ARM) or the platform.

The "if" is neutral, since it is alwys execute (may be a very little jmp that are assorbed by cache) ... you can try to invert the two calls and you will (should) see how is the timing. The different times are justified by the overhead (like @PeaShooter_OMO sayd) of the call (load the registers / stack, jmp, load the result / stack, return). It's right to define them INLINE, in this case you have a better timing (you can declare inline one, the other or all two to see the various timing).

This are the project. Fucking DLL RUNDLL32.zip

I wrote that, HINSTANCE is a global var. HINST is the type.

HInstance is the instance (var) of the module, derived from System.pas (type HINST). Should be always defined and available 'cause it is used at loading time (look SysInit.pas) FYI, MainInstance in the HInstance of the MAIN APPLICATION (not the module like dll, library, ...).

Ah ah ah, are you sure that are really "private" ? One of the last Ollama model ("gemma3:12b" or "qwen3:30b-a3b" if I'm not wrong) can access Internet, of course you must excplicity ask for this, but it can.

There were other discussion about WINMD, that seems to be buggy, look there: https://en.delphipraxis.net/topic/13720-bugs-on-winmd-who-can-clarify/?do=findComment&comment=105350 In one post, @pcoder suggest the see others metadata provider (like this https://www.winsoft.sk/win32api.htm ). If you look insede of those sources, you will look that more types were derivered form SYSTEM unit, like IUNKNOWN for example. Try this instead WINMD. There are in QP some open issues about WINMD.

I think all is linked to the time of SO post, 15 years ago. Talking about CPU here is about CORE, when there are multiple CPU other things come in play and the sleep is the last of the issues. Take care now ( @Kas Ob. told this) that the real life is different: no one use affinity with one thread (yes, I do it but for really unique needs), the threads work are balanced by ITD (Intel Thread Director) that acts between OS and hardware, and also Windows may have changed some logics. If you look at your thread (not the one in the example that's "blocked" by Affinity), you'll see that it's "moved" by core during its lifetime. That is, a thread doesn't necessarily always run in the same core. So, if Microsoft were to say that SwitchToThread works in a certain way with modern hardware... well, I wouldn't be so sure, or rather, not in the context we're imagining, given that the load distribution is dynamic.

What you indicated is not the last one: (of course you could have installed it manually too...). But, if you don't find the source files, obviously something went wrong during the installation. Did you check the installation for all platforms during the installation of Rad Studio? (I did)

My sources about Posix are in "C:\Program Files (x86)\Embarcadero\Studio\23.0\source\rtl\posix" If you have trouble compiling, look at: https://docwiki.embarcadero.com/RADStudio/Athens/en/Installation_Notes There are some notes about Linux at the end of the page (missing lib paths). P.S.: in my installations of course there are the compiled units in ALL needed paths.

But you and Remy are still there with a greater, precious and fundamental tireless contribution. Thank you for all, for what you have done and for what you will do (to others of TeamB too, that I don't know).

SKU: Enterprise, Professional, Personal (this may be Community Edition). Source: BDS.EXE and LicenseManager.exe I cannot find the Architect SKU, it is possible that is derived from something else. They (Embarcadero) spoke about this way to find a kind of product in Alexandria news note. So, I think from that release we had the opportunity to use it.

Why don't you use this:

Wrong answer ...

Embarcadero generally maintains good compatibility on its products, but obviously when talking about a product that is at least 16 years old, it may be that some manual changes are made. Then there is the third-party libraries to think about.... Further info: for the COMMUNITY license, C++ and DELPHI cannot coexist.

Actually thare is something wrong with this (test on Intel platform, Win11 physical machine, Win 7.1 on VirtualBox VM): 1) Same DLL x64 (SSL 1.0.2u), Indy bundle (Rad 12.3), Win 11 works with the host indicated by @Del Murray with or without Chiperlist. 2) Same DLL x64 (SSL 1.0.2u) and exe, Indy bundle (Rad 12.3), Win 7.1 (VM) works with the host indicated by @Del Murray ONLY with explicity set of Chiperlist. This can only be explained if by default the host (server) requested one or more "ciphers" not available in Windows 7 other than those in the ChiperList (because otherwise it could use one of those even if they are not explicit). But running the test via SSLLabs you see that the server's preferential request (for TLSv1_2) corresponds to the indicated CipherList. So there is something in the operating system that introduces an unmanaged variant (for example in Windows 7 Indy or SSL they use the CLIENT's Chiper preference by default while in Windows 11 the Server's preference is used). And if the client does not have a preference list, what does it propose? When I have a moment I will do some tests on this. For me is not a problem because since I used TLS, I always insert ChiprList (in fact I have several applications that run with TLSv1_2 in Windows 7 in an industrial environment).

Uhmm, this is a topic about your error and they solve using the update version of Indy and Delphi (from Seattle to Berlin) : https://en.delphipraxis.net/topic/2950-indy-http-error1408f10bssl3_get_recordwrong-version-number/ I don't know if is the same trouble ... EDIT, try this old thing: set the PassThrough of SSLIOHandler to false. After setting the ChiperList inserto this line: IdSSLIOHandlerSocketOpenSSL1.PassThrough := false;

It doesn't work with Windows 7 in a VM. OpenSSL 1.0.2u X64. Rad Studio 12.3. Indy Bundle. UPDATE: It works if the chiperlist is in use ...

I think the SSL3 is only an symbol to identify the security protocol SSL in general way, not really about SSL3 protocol. But really I don't know way the client doesn't respond to TLS ... I try with a VM ,,, stay tuned ...