DelphiUdIT

I cannot help more than this, it's a lot of times that I don't work with Windows Server.

In Server version WOW64 is disable lot of times. You must use "dism" tools to enable it. I have no refer to Microsoft doc, but you can try these if you know what you are doing: dism /online /get-features /format:table You should see a long textual table with the features active in your server, the WOW64 features should be like this if disabled: ServerCore-WOW64 : Disabled If you want enable it, do this: dism /online /enable-feature /featurename:ServerCore-WOW64 Hope to help you

TRectF is declared in "System.Types"

Look at the bottom, the end of the list of files in the folder .... DXEInstall is the last ...

May be you can use the Mutex (refer to https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexw ) : Uses WinApi.Windows; var hMutex: THandle //Create a global mutex (valid for all system) hMutex:=CreateMutex(Nil,False,'Global\DBiAdminSemaphore'); //If the Mutex is already owned then exit (this means that another application take it) if (WaitForSingleObject(hMutex,0) = wait_TimeOut) then exitprocess(255); //The Mutex will close automatically when the program close Bye

I don't have any source that I can report, only chats and some information from unofficial sources. But the optional WOW64 in Windows Server configuration is surely a start. Of course, like @Brian Evans said this path is not clear.

You are right. Windows 7, as was the case with Windows 98 SE, have made their way into the industrial world (and also services) and precisely for this situation they have not been completely abandoned. The new Delphi 12 environment, as already mentioned, can still compile executables that run under Windows 7, but that doesn't mean we have to stop there. The IDE policy on all current and past systems is typical of Lazarus/FPC. But it still has its limitations, which may be fine for one group of users, but certainly not for others (and I am among the latter). As the latest rumor, more or less accredited, it seems that (* NOTE) Microsoft will abandon WOW64 technology (emulation for 32-bit applications). The transition will be gradual but inexorable. It has already started with Servers, where WOW64 is optional. (*NOTE): This is a personal evaluation and has nothing to do with Microsoft's statements.

"anything i like " ... for those who work it is not enough, it should be "anything I must do" and I would like to challenge you to develop a 64 bit application with Delphi 7 or perhaps an app for Linux or Android. And let's forget about all the concepts of security or anything else. It's true that frills are often not needed, but you just need to set up your environment to make you work at ease. However, everyone is free to work as they wish, and fortunately developments continue regardless of certain opinions. I don't think the fact that the new IDE doesn't run under Windows 7 or Windows 95 where Delphi 7 runs is such a serious problem. Any professional working with tools to bring home pay needs the right tools, and many times these tools need to be updated (and after 22 years of Delphi 7 and 15 years of Windows 7 ..... may be it's the right time).

I think what you said is simply a meaningless criticism of Delphi. The fact that there are themes in the IDE (or in the final product) is only a good thing. Then the IDE must make the most of existing technology and therefore it is normal for the features of the latest operating systems to be exploited. Then if someone wants to work with clubs and stone tablets... well he is free to do so. Furthermore, the fact that the IDE only runs on Windows 10 or Windows 11 does not limit the development of applications that run on Windows 7 or Windows Server (or on Mac, Linux, Android) And although you say that the IDE is too far ahead, some would like it to be even further ahead and therefore with more stringent features. It's really funny to see how there are exactly opposite positions: someone would already like to think about 128 bits and someone would like to go back to 8 bits....

This is a little screenshot for Parnassus (not the last):

I have some getit packages in private Repo (like Styles and FastReport) and others in common Repo (like Parnassus, FmxLinux).

In the offline Rad Studio installer you can set those path before start the install process.

Sorry for the inaccuracy but I wrote quickly:

Why don't you set your new path for CatalogRepo ? In TOOL menu you can set you own path for that. And if that path need to be the same for all user every user can do the same. I have mine own path to a more accessible folder. It's simple and better also when you migrate the IDE.

In Delphi 11, when I changed some $IFDEF a lot of time the source code not changed. But the compile (full compile, not RUN hoping that IDE compile the right code) always does the correct work. In Delphi12, by now, changing $IFDEF always change the source code too. I use some $DEFINE and I never notice malfunctions.

May be, now is working, like the example in the Embarcadero unit .... but there are some facets to evaluate. program Project2; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; type IFoo = interface ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] function GetEmptyName: string; function GetFooName: string; end; IBar = interface(IFoo) ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] function GetBarName: string; end; //TFooBar = class(TInterfacedObject, IBar) //This is working too TFooBar = class(TInterfacedObject, IFoo, IBar) function GetEmptyName: string; function GetFooName: string; function GetBarName: string; end; function TFooBar.GetEmptyName: string; begin Result := 'Empty'; end; function TFooBar.GetFooName: string; begin Result := 'Foo'; end; function TFooBar.GetBarName: string; begin Result := 'Bar'; end; var i: IInterface; begin try { TODO -oUser -cConsole Main : Insert code here } i := TFooBar.Create; Writeln((i as IFoo).GetEmptyName); Writeln((i as IFoo).GetFooName); Writeln((i as IBar).GetBarName); except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; readln; end.

Uhmmm for me it's not working, but maybe I'm missing something... I'm almost certain that the "as" and "is" don't work if the GUIs are identical...

I agree with you, I just wanted to point out some sources on where to possibly look for further useful information on the topic. I've already seen double GUIDs in interfaces in COM environments, and they worked correctly (or at least I never detected problems), but I never looked into them further.

You must use GUIDs when there is a need to use RTTI "as" and "is". Like you told, each interface should have a unique GUID, but I have already see that. Start from here: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Object_Interfaces_(Delphi) (may be the link is wrong ... wiki is down at the time of writing) P.S.: You can read also these books (with examples) - Hodges Nick - Coding in Delphi (year 2013) - Hodges Nick - More Coding in Delphi (year 2015) I don't know if there are something that can help you ...

Yes since Friday evening.

If the system is overloaded all activities and processes including threads, events, etc ... will inevitably be delayed. To mitigate this you can just "play" with the thread priority. Using sleep in a thread at a higher priority than normal is usually a satisfactory solution. However, if the timer needs to be triggered (i.e. it is not always active), then you should use sleep in combination with a WaitFor. As @Dalija Prasnikar says, it is not possible to provide you with further solutions if you do not present code or delve deeper into the topic.

Uhmm ... you used a wrong words .... for me is "many times", not "few times" , 4 times I went in the lock screen. Like you wrote, something about Windows 11 is wrong. I cannot help 'cause I have not experience in this case. I never used CreateDesktop or similar api. Good luck and let us knows if you'll resolve the question.

To be more exact as possible you can use MMSystem: timeBeginPeriod(1); timeEndPeriod(1); These affect the timer resolution in Windows ... in this example the resolution is set to milliseconds between timeBeginPeriod and timeEndPeriod. You can find more information on: https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod. You can set (timebegin) at the start of application and reset (timeend) at the end. P.S.: normally this is the accuracy ... thanks to Mark: https://learn.microsoft.com/it-it/sysinternals/downloads/clockres

I use PlaySound in async way (and with more then 10 seconds) in all my applications without any issue. I use it with RESOURCE identifier, but with old app I used also with media file. PlaySound('Alarm_Sound', HINSTANCE, SND_RESOURCE OR SND_ASYNC);

Terrible 😱 ... in Windows 11 23H2 that produce a black screen with application, but when you close the application there is no way (or better, I don't know how) to come back to previous Desktop ... close some process, launch new explorer ... all shortcuts ... only shutdown and restart Windows (from Task Manager -> "New operation") ... also everything I launch is not visible, may be is attached to old Desktop ... This is a good and simple hacking app ...