dummzeuch

Sorry, my fault for not asking properly: I am not looking for a tool to replace Putty + the menu or the Linux shell, I am looking for a tool that allows a Delphi program to initiate starting those scripts, e.g. via a REST service.

Wow, that's quite a list of fixes.

1.8% rating is far from being popular. It's just marginally better than the 1.64% of SQL on place 11. Compare that to the ratings of the top 3! That's one of the problems with this "index". The differences between the rankings even some in the top 10 are lower than the error margins of the data source.

The languages at the top of that list have changed quite a bit since the last time I looked. Probably means that was a long time ago. I'm sure python was not yet in the top ten back then.

I usually prefix functions like this with "Try", so instead of function GetTheValue(parameters ...): SomeType; it's function TryGetTheValue(parameters ...; out Value: SomeType): Boolean;

A github repository containing 3 zip files was not quite what I was expecting. For those who don't read Russian, here is the Google translate link. https://kuzduk-ru.translate.goog/kuss/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp

They probably thought that 2047 was "enough for everybody" and didn't think of it as a limit, so they didn't impose a limit on WriteString either. But we can only guess. OTOH nobody(*1) uses TIniFile any more but TMemIniFile because it overcomes all the limitations of Get/SetPrivateProfileString so that's a moot point. (*1 for suitable definitions of nobody )

Just in case anybody else is wondering: This works since Delphi 2010 which was the version that first included the unit rtti. Older Delphi versions did not support RTTI for records.

"Abort" is a popular name for procedures and methods, that's why it came to mind. I had to qualify it several times in my code because there was an ambiguity. I'm too lazy to use that qualifier without a good reason. Uwe's answer looks like a good solution for these cases. I hope I remember it the next time this comes up.

You can have a lot of fun when starting to use namespaces. This compiles fine ... unit bla; uses SysUtils; interface implementation procedure Test; begin SysUtils.Abort; end; ... until you add the namespace to the unit name ... unit bla; uses System.SysUtils; interface implementation procedure Test; begin SysUtils.Abort; end; ... but do you really want to write System.SysUtils.Abort ? This is just an example. You don't of course need to qualify Abort, but if there are name clashes in different units you have to, or you can rely on the order of the units in the uses clause, which I think is a bad idea.

Actually, the concept of namespaces was introduced with Delphi 2005, but the RTL and VCL started using them much later. A quick search in my installations found vcl.controls.pas appearing in Delphi XE2, before that it was just controls.pas

YMMD: I just imagined the developers singing while running the signing process.

You could have different desktops for these "modes", but they won't switch automatically either. Hm, maybe you could assign keyboard shortcuts to these menu entries using GExperts, but I'm not sure this is possible. Edit: It isn't. The menu entries for the configured desktops are added dynamically and don't show up in the GExperts IDE Menu Shortcuts expert. So you can't assign a keyboard shortcut to them. (At least not this way).

I have just built an installer for GExperts 1.3.24 Beta1 for Delphi 12. Note the word “Beta” in the release name! We are one step up from Alpha, there are still many bugs, but overall it seems to be stable. Most of the bugs manifest themselves as display glitches on high DPI monitors. Continue reading in the blog post

The current source code compiles fine in Delphi 12.2 and I haven't noticed any new bugs. The Installer for Delphi 12.1 works for Delphi 12.2. I haven't heard of any problems there either.

The Win32 Delphi 2007 program below sets the PEFlag for IMAGE_FILE_LARGE_ADDRESS_AWARE, so I would expect it to have 3 GB of memory available. But it writes: TotalVirtual 2147352576 Bytes 2,000 GiB AvailVirtual 2093465600 Bytes 1,950 GiB So why does it say there are only 2 GB? The OS is Windows 10 pro 64 Bit with 16 GB of physical memory (from which a lot is available). I could have sworn that this has worked before. Edit: Duh! I forgot an 'or' between 'IMAGE_FILE_NET_RUN_FROM_SWAP' and 'IMAGE_FILE_LARGE_ADDRESS_AWARE' program Project1; {$APPTYPE CONSOLE} uses Windows, SysUtils; {$SETPEFLAGS IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP IMAGE_FILE_LARGE_ADDRESS_AWARE} procedure GetProcedureAddress(var P: Pointer; const ModuleName, ProcName: string); var ModuleHandle: HMODULE; begin if not Assigned(P) then begin ModuleHandle := GetModuleHandle(PChar(ModuleName)); if ModuleHandle = 0 then begin ModuleHandle := SafeLoadLibrary(PChar(ModuleName)); if ModuleHandle = 0 then raise Exception.CreateFmt('Library %s not found', [ModuleName]); end; P := GetProcAddress(ModuleHandle, PChar(ProcName)); if not Assigned(P) then raise Exception.CreateFmt('Function %s not found in library %s', [ProcName, ModuleName]); end; end; type _MEMORYSTATUSEX = packed record dwLength: DWORD; dwMemoryLoad: DWORD; ullTotalPhys: Int64; ullAvailPhys: Int64; ullTotalPageFile: Int64; ullAvailPageFile: Int64; ullTotalVirtual: Int64; ullAvailVirtual: Int64; ullAvailExtendedVirtual: Int64; end; {$EXTERNALSYM _MEMORYSTATUSEX} MEMORYSTATUSEX = _MEMORYSTATUSEX; {$EXTERNALSYM MEMORYSTATUSEX} LPMEMORYSTATUSEX = ^_MEMORYSTATUSEX; {$EXTERNALSYM LPMEMORYSTATUSEX} TMemoryStatusEx = _MEMORYSTATUSEX; type TGlobalMemoryStatusEx = function(out lpBuffer: TMemoryStatusEx): BOOL; stdcall; var _GlobalMemoryStatusEx: TGlobalMemoryStatusEx = nil; function GlobalMemoryStatusEx(out lpBuffer: TMemoryStatusEx): BOOL; stdcall; begin GetProcedureAddress(Pointer(@_GlobalMemoryStatusEx), kernel32, 'GlobalMemoryStatusEx'); Result := _GlobalMemoryStatusEx(lpBuffer); end; function GetTotalMemInfo: string; var MemStatusEx: TMemoryStatusEx; begin MemStatusEx.dwLength := SizeOf(MemStatusEx); if GlobalMemoryStatusEx(MemStatusEx) then begin Result := Format('TotalVirtual %d Bytes %.3f GiB', [MemStatusEx.ullTotalVirtual, MemStatusEx.ullTotalVirtual / 1024 / 1024 / 1024]); Result := Result + #13#10 + Format('AvailVirtual %d Bytes %.3f GiB', [MemStatusEx.ullAvailVirtual, MemStatusEx.ullAvailVirtual / 1024 / 1024 / 1024]); end else begin Result := 'GlobalMemoryStatusEx call failed'; end; end; begin try WriteLn(GetTotalMemInfo); Readln; except on E: Exception do WriteLn(E.ClassName, ': ', E.Message); end; end.

I got it from some random 😉 post on StackOverflow (I could not find it on any Microsoft site)

Just in case anybody is still reading: I found some code in my program that didn't work once the 2 GB limit was reached. "Fortunately" it was where a DLL was loaded into memory near the start of the execution so it never happened until I configured Windows to start allocating memory from top using the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management AllocationPreference= 0x100000 Then all of a sudden it crashed. I fixed this problem now (I hope). It was in dzlib library, unit u_dzResourceDllLoader, btw. so if somebody else is actually using that library, you might want to update.

It doesn't really make much sense to use the old Delphi 12.1 bpls with programs compiled in Delphi 12.2.

It moved to its own expert and I blogged about that change. And I also answered that question in the second post of this thread.

Interesting concept. Thanks for sharing it. I have never heard about this unit before, but I found this page by googling for "TInputRecArray" "Delphi" which looks a lot like your unit. It's a blog post from 2013 on a Chinese site. I think the concept could be improved on by using fluid programming like this: var Value1, Value2, Value3: Variant; // ... Success := MultiInputBox(Self) .AddField('Enter your age.: ' , 3, ftNumber, 0, Value1) .AddField('Enter a hex value.: ', 4, ftHexNumber, 0, Value2) .AddField('Enter a float value.: ', 10, ftFloatNumber, Value3) .ShowModal; That could be done by having MultiInputBox return an interface with an AddField function that returns that interface and a ShowModal function that returns the boolean. That interface then internally declares and manages the TInputRecArray. This saves the boilerplate code of declaring and filling the TInputRecArray and make the code (in my opinion) a lot more readable.

GExperts did not have a Code Formatter in the 90ies. There was only DelForEx by Egbert van Nees (and later a code formatter as part of project JEDI which today is part of the Lazarus IDE). He donated that code to GExperts in the mid 2000ties and I integrated it into GExperts and over the years improved it (performance on large files more than doubled) and extended it to cover new language constructs that were added.

see private message

I just had a look at my import unit. It also uses stdcall, so that's not the problem. I apparently wrote a test tool, but I don't recall the specifics. As I already wrote on Mastodon: I ended up just using the keyboard emulation. It might have been because I didn't get the API to work. Or maybe the emulation was easier and good enough. I'll try to look into it tomorrow, if I find some time.

Just a thought: Are you sure that the calling convention is stdcall? Maybe it is cdecl.