Kas Ob.

Have you tried my snippet above ? Here more little more complete one Main form type TMainForm = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var MainForm: TMainForm; implementation {$R *.dfm} uses uMyContest; procedure TMainForm.Button1Click(Sender: TObject); begin //MyContestForm.Show; // or with MyContestForm.Create({Self} nil) do Show; end; end. And your ContestForm unit uMyContest; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls; type TMyContestForm = class(TForm) procedure FormCreate(Sender: TObject); private procedure WMSysCommand(var Msg: TWMSysCommand); message WM_SYSCOMMAND; public { Public declarations } end; var MyContestForm: TMyContestForm; implementation {$R *.dfm} procedure TMyContestForm.FormCreate(Sender: TObject); begin SetWindowLong(Handle, GWL_HWNDPARENT, 0); end; procedure TMyContestForm.WMSysCommand(var Msg: TWMSysCommand); begin case Msg.CmdType of SC_MINIMIZE: begin Exit; // Do nothing end; SC_MAXIMIZE: begin Exit; // Do nothing end; end; inherited; end; end. Contest form now will not hide or minimize when main form is minimized, also it have an icon on taskbar. Other than naming i didn't touch anything in the designer properties like border icons .

Why deleted ?!! I am interested as i have similar approach to list the compiled units in the application for some extreme logging. So would you please share again ? Here is mine, which i believe can be adjusted to get the initializing order from running application itself. var ThisPackageInfo:PackageInfo; function GetInitContext(NotUsed:Pointer = nil):Pointer; const SIZE_OF_POINTER = SizeOf(Pointer); PLATFORM_OFFEST_CORRECTION = {$IFDEF WIN32}4{$ELSE}1{$ENDIF}; asm mov NotUsed , [ ESP - PLATFORM_OFFEST_CORRECTION * SIZE_OF_POINTER ] mov Result , NotUsed end; begin // project begin ThisPackageInfo := GetInitContext; // retriving the PackageInfo pointer from dirty stack, must be the first after begin. Application.Initialize; Application.MainFormOnTaskbar := True; procedure TForm10.EnumUnits; var i, Count, NameLength: Integer; PUnitName: PAnsiChar; UnitName: AnsiString; UnitsArr: array of string; begin if (not Assigned(ThisPackageInfo)) or (ThisPackageInfo^.UnitCount = 0) then exit; PUnitName := PAnsiChar(ThisPackageInfo.TypeInfo.UnitNames); Count := ThisPackageInfo.TypeInfo.UnitCount; SetLength(UnitsArr, Count); i := 0; while i < Count do begin NameLength := Ord(PUnitName^); if NameLength = 0 then Break; SetLength(UnitName, NameLength); Inc(PUnitName); Move(PUnitName^, UnitName[1], NameLength); Inc(PUnitName, NameLength); UnitsArr[i] := string(UnitName); Inc(i); end; end; Will work Win32 and Win64, the order of the list has nothing to do with initialization procs but in that table there is Init and FInit and may be there is a way to compare these addresses to the position of the units, this will allow to sort the units according to initialize proc. ps: this is a hack way to get PackageInfo pointer and only tested on older compilers.

This might help https://stackoverflow.com/questions/52470476/how-to-restore-a-minimized-modal-form And because i am not sure if i understand the problem exactly, i mean do you need a dedicated icon on the taskbar for these forms or not, but anyway. If you try this private procedure WMSysCommand(var Msg: TWMSysCommand); message WM_SYSCOMMAND; .. procedure TMyContest.FormCreate(Sender: TObject); begin SetWindowLong(Handle, GWL_HWNDPARENT, 0); end; procedure TMyContest.WMSysCommand(var Msg: TWMSysCommand); begin case Msg.CmdType of SC_MINIMIZE: begin Exit; end; SC_MAXIMIZE: begin Exit; end; end; inherited; end; This will prevent MyContest form form minimizing and maximizing even if the border buttons are there, and even if your main is changing state.

I wrote many of these small and target specific tools, but they are not a library, they were functions and parts to do small jobs, so my suggestion is to do it like that, once you started you will see it is easy to achieve. On side note : there is https://mitec.cz/pe.html which is only reader, but it is comprehensive and detailed and will give you the push to skip searching the net all day long looking for small pieces of information here and there. May be a request to the author of MiTeC Portable Executable Reader to build a writer/editor part should be nice, he can do it efficiently in short time.

Remembered or thought about more clear example. What about page faults, by not only Intel documentation but every CPU, page fault should trigger specific hardware reaction, hence invoke the what so called kernel aka protected mode which in this case override the real mode, to handle this. Now have you ever witness any correlation between the page faults triggered in guest software/OS and the host ? the answer is no . How does this happen ?, by the virtualized mode where CPU change override its initially installed protected mode after its real mode and use the virtualized mode, this is not explained in the Intel CPU instructions but explained in different manuals and resources. This why i feel my Delphi IDE somehow faster and smoother running on older Windows hosted by Windows 10 Hyper-V, the real cause is memory management the way page faults handled.

I think we misunderstand each other here, i am sorry and will try to explain this point, sorry for my English again, Due to many confusing terms, because they are really confusing and spread left and right, i will try with examples and questions (don't need an answers, just food for thought), because i can't keep up with these terms everywhere with big words. first lets dissect the above text >VMX ROOT and the virtual machine, This is talking about the hypervisor it self, it moves further and talk ring 1 and ring 3, this make sense, but lets ask the real question how it did override the host kernel for ring 1, and what will happen with ring 0 ?!! The guest lets say Windows server 2008 and the host is Windows 10, CPUID in 2008 must not be handled by Win10, then how the hardware generated fault override the host kernel for such very critical fault ? another scenario, two guests one of them running critical web servers, the other will try to hack into it by calling RDSEED and RDRAND all the time to get a back log may be, this is critical security hole if any consequential 2 calls gave the same output, hence the failure ensured by the CPU, but and it is serious one, how to virtualize this thing assuming we need older compatibility to remove these instructions, does the host have to be triggered, and more serious question if these instruction executed by the guest, should the host ever know about them ? or they output values ? the answer is no. If ring 0 which is such crucial to Windows kernel including our guest Win2008 did ring0, who is going to handle this, also there is one of the most critical instruction in the whole PC, the LGDT, the guest must be able to have its version while the host most not have any idea about this, any knowledge will render the whole hardware virtualization insecure and the guest will be compromised, and no one must trust any virtualized machine to run any server. Also let differentiate between emulation and hardware virtualization, emulation will check each instruction and adjust it, making the performance slower, virtualization using modern CPU is almost transparent allowing all these instruction to run at base CPU speed, but when it comes to specific instructions, just like the host in protected mode, they will be handled in hardware designed manner, CPUID is not privileged https://www.felixcloutier.com/x86/cpuid and does have any exception with it (these 2 mentioned are irrelevant), yet another documentation (the one you provided) explicitly says it will raise fault-like VM exit, is that a contradiction ?, no Due the complexity of modern CPU's, they can't include these VM related faults everywhere talking about documentation, because they will happen in different environment, Now to the core question who must handle these fault in virtualized mode, not the guest, and not the host, it is one called hypervisor or VMX ROOT mode or non root mode , or whatever.... the point is, these will will be captured by specific kernel-like and protected mode like running on top of the host protected mode but to very extended length in dependably. one point though, if the host get triggered to handle an instructions like INT the interrupt call https://www.felixcloutier.com/x86/intn:into:int3:int1 then literally the speed should be 10x-100x slower on the guest, we don't witness any thing like that, so the CPU after switching to a thread inside the hardware virtualized mode, it will use the same operation in that link but not for the same IDT of the host, this is way longer explanation, Intel documentation separate the virtualized mode completely from the default virtual and protected and real mode .... sure, but like the above, this is true in all mode except the virtualized mode, CPUID on a host should not know the exact CPUID of the host !, and the host software should not know if a guest software called it !, only the what so called hypervisor will know and have the ability to change its return value. Sorry for salad like phrases above, just hope they give you a start point to decipher these documentation, and put us on closer page.

If CPUID faulted then may be more than 90% of all software will not work in VM , right ?! That part is cut from different context completely, i will assume its about either it is about VM mode not the virtual mode we are using browser in. These are the default mode mentioned in the Intel doc. above While that paragraph 27.2.5 from different one and most likely talking about Intel VT-x instructions https://docs.hyperdbg.org/tips-and-tricks/considerations/basic-concepts-in-intel-vt-x not form Intel but way more clearer than Intel. Now back to this RDRAND will not fault in a host code nor in guest code, BUT (big one) will fault in the virtualizing code layer between these two, this to protect the host and the guest, the virtual machine should be in oblivious realm like a black hole to guarantee security and integrity of the process, the VM will act like a kernel at its own, closed and isolated from the host kernel as much as it should, hence it should be limited with instructions, this limitation will be left when execution handed to wither the host or the guest. About this These columns will show what will fail in which mode, but not discussing any virtualization.

If you commented the "inc RDX" in the above code, it will compile for win32 and run, and here the view This behavior expected and understandable for such instructions, but i have doubts when combining this with with special instructions like RDRAND, can't be sure though, see RDRAND can't be found on CPU doesn't support x64, but what is the behavior can be with emulators like QEmu ?!! I have seen many codes that detect virtualization with such instructions specific combination, by depending either on wrong behavior or triggered faults.

On side note: Here a sample of the $48 prefixes on x64 mode procedure Test; asm inc EDX inc RDX db $48, $FF, $C2 db $48, $48, $FF, $C2 db $48, $48, $48, $FF, $C2 db $48, $48, $48, $48, $FF, $C2 db $48, $48, $48, $48, $48, $FF, $C2 db $48, $48, $48, $48, $48, $48, $FF, $C2 db $48, $48, $48, $48, $48, $48, $48, $FF, $C2 db $48, $48, $48, $48, $48, $48, $48, $48, $FF, $C2 end; begin Writeln('Start'); Test; Readln; end. Here how Delphi CPU handle wrongly disassemble them The right disassembly Why the same instruction executed without a fault in x86 build, most likely the CPU handled $48 as its own instruction which will touch eax the one being overwritten by following RDxxx. just off-topic notes.

And for this exactly, i always refer to https://www.felixcloutier.com/x86/ and see the operation section, warning, faults(exception)..etc, it way better and clearer documentation.

Also this

Also want to point to OP, about this retries recommendation 5.2.1 Retry Recommendations It is recommended that applications attempt 10 retries in a tight loop in the unlikely event that the RDRAND instruction does not return a random number. This number is based on a binomial probability argument: given the design margins of the DRNG, the odds of ten failures in a row are astronomically small and would in fact be an indication of a larger CPU issue. So 10 should be enough.

Being called bad doesn't mean it is not 0, also it will return no data in this case is 0, but the documentation doesn't point this by words. For deep explain of the opcode steps for both instruction please refer to https://www.felixcloutier.com/x86/rdrand https://www.felixcloutier.com/x86/rdseed For both the operation goes like this IF HW_NRND_GEN.ready = 1 THEN CASE of osize is 64: DEST[63:0] := HW_NRND_GEN.data; osize is 32: DEST[31:0] := HW_NRND_GEN.data; osize is 16: DEST[15:0] := HW_NRND_GEN.data; ESAC; CF := 1; ELSE CASE of osize is 64: DEST[63:0] := 0; osize is 32: DEST[31:0] := 0; osize is 16: DEST[15:0] := 0; ESAC; CF := 0; FI; OF, SF, ZF, AF, PF := 0; meaning not only CF is flagged but the the destination also zeroed.

Hi, and you are right, only the fail value is 0 as result in this case following Intel own code.

This is really long story ! But to short it a lot, like a lot .. Please see https://www.felixcloutier.com/x86/rdseed Now to more short explain, the only difference between the x64 and x86 assembly instruction is the prefix NFx, look at my code above, and NFx is somehow similar to REX, further explanation need more manual when NFx should fail aka ( trigger hardware illegal instructions)

You know that the locked mechanism has nothing to do with the application you building, it is only for the designer at design time, and that is it, also closed forms and frames don't tend to move their dropped components around nor change the design. The only way components move and resize is by your actions, unless there is a bug in the IDE, so locking components is rarely used, i use it once or twice per year may be for few minutes and i can do without it though.

And the x86 is even shorter function RDSEED32(aRetryCount: UInt32 = 0): UInt32; asm inc edx @LOOP: dec edx js @Exit DB $0F, $C7, $F8 // RDSEED EAX jnc @LOOP @EXIT: end; function RDRAND32(aRetryCount: UInt32 = 0): UInt32; asm inc edx @LOOP: dec edx js @Exit DB $48, $0F, $C7, $F0 // RDRAND EAX jnc @LOOP @EXIT: end; My CPU doesn't support these instructions, so i wrote them on XDBG64 then pasted them on the IDE, any way this code should be checked for support on CPU side.

Small correction here, when RDSEED or RDRAND fail they will flag the carry flag CF, but Intel documentation itself check for 0 value in loop for failure, strange. https://www.intel.com/content/dam/develop/external/us/en/documents/drng-software-implementation-guide-2-1-185467.pdf This SO answer explains the difference between RDSEED and RDRAND You already did, and it should work for x64 and only for X64, unless you are talking about the value checking and looping, in that case here a fix: function RDSEED64(aRetryCount: UInt64 = 0): UInt64; asm .noframe mov RDX, aRetryCount inc RDX @LOOP: dec RDX js @Exit DB $48, $0F, $C7, $F8 // RDSEED RAX jnc @LOOP @EXIT: end; function RDRAND64(aRetryCount: UInt64 = 0): UInt64; asm .noframe mov RDX, aRetryCount inc RDX @LOOP: dec RDX js @Exit DB $48, $0F, $C7, $F0 // RDRAND RAX jnc @LOOP @EXIT: end; I see DelphiUdIT already added valuable information but am posting anyway.

@TomEd And the coma, in other words, the body should be fully validated JSON format.

SslHttpCli1.ContentTypePost:= 'multipart/form-data; boundary=' + strBdry; SslHttpCli1.Connection := 'Keep-Alive'; MimeHeader:=strBdry + sLineBreak + ............ strBdry + sLineBreak + 'Content-Disposition: form-data; name="image" filename="capture.jpg"' + sLineBreak; MimeFooter:=strBdry + '--' + sLineBreak; SslHttpCli1.SendStream:=TMultiPartFileReader.Create (s, MimeHeader, MimeFooter); The "boundary=" value should be less two dashes from the boundary in header and footer. The first answer on this SO question is just perfect https://stackoverflow.com/questions/4526273/what-does-enctype-multipart-form-data-mean

Sorry to interfere, but i think the OP question wasn't clear enough. He is asking if ICS hoes support MIME with multipart/form-data , that protocol allow to send multiple data with different encoding/(content type) with a name for each, like you can send "1.gif", "text.txt" and "conf.xml" in same POST or same response, also the content encoding for each doesn't need to be Base64 encoded, it can be binary. The protocol for web is here https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 and some extra resource https://www.sobyte.net/post/2021-12/learn-about-http-multipart-form-data/ It is defined in https://www.ietf.org/rfc/rfc2045.txt Very similar if not identical is used with emails and SOAP, it is gaining popularity each day, as many sites allows you to upload multiple image from one form post. Hope that cleared the OP question as i have no idea if ICS support this.

If i understand your request, then you need to restore the position of first visible line In that case you can use this type TForm11 = class(TForm) Button1: TButton; Memo1: TMemo; procedure Button1Click(Sender: TObject); private FMemo1Position: Integer; procedure Memo1SavePosition; procedure Memo1RestorePosition; public procedure LoadContent; end; var Form11: TForm11; implementation {$R *.dfm} procedure TForm11.Button1Click(Sender: TObject); begin LoadContent; end; procedure TForm11.LoadContent; begin Memo1SavePosition; Memo1.Lines.BeginUpdate; try Memo1.Lines.Clear; while Memo1.Lines.Count < 100 do Memo1.Lines.Add(IntToStr(Memo1.Lines.Count)); finally Memo1.Lines.EndUpdate; end; Memo1RestorePosition; end; procedure TForm11.Memo1RestorePosition; var Current: Integer; begin Current := Memo1.perform(EM_GETFIRSTVISIBLELINE, 0, 0); Memo1.perform(EM_LINESCROLL, 0, FMemo1Position - Current); // or //Memo1.perform(EM_LINESCROLL, 0, FMemo1Position - Memo1.perform(EM_GETFIRSTVISIBLELINE, 0, 0)); end; procedure TForm11.Memo1SavePosition; begin FMemo1Position := Memo1.perform(EM_GETFIRSTVISIBLELINE, 0, 0); end;

I see you figured it out , congratulation !

I have no knowledge with smart card ! FPiette answer is right on point. You miss read/write the number (or your source of information wasn't clear) as it is 1000.000.000.000.000 , in hex is 38D7EA4C68000, it is little endian meaning the first byte is zero will not change the value. was going to ask if you can do it on your own then .... but why not program SmallerHex; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Classes; function HexStringToBytes(const HexString: string): TBytes; var i, c: Integer; st: string; LStingList: TStringList; begin LStingList := TStringList.Create; try LStingList.LineBreak := ' '; LStingList.Text := HexString; SetLength(Result, LStingList.Count); c := 0; for i := 0 to LStingList.Count - 1 do begin st := Trim(LStingList.Strings[i]); if (st <> '') and (Length(st) = 2) then begin HexToBin(PChar(@st[1]), PAnsiChar(@Result[c]), 1); Inc(c); end; end; SetLength(Result, c); finally LStingList.Free; end; end; function BinaryToUInt64_BE(Buffer: PByte; Len: Integer): UInt64; begin if Len > SizeOf(Result) then raise Exception.Create('Requested Size for UInt64 can''t be longer than ' + IntToStr(SizeOf (Result))); Result := 0; while Len > 0 do begin Result := Result shl 8; Result := Result or Buffer^; Inc(Buffer); Dec(Len); end; end; procedure DecodeSumOrSomethingInto2UInt64; var HexBytes: TBytes; First, Second: UInt64; begin HexBytes := HexStringToBytes('00 00 08 99 7D FB 1A 03 8D 7E A4 C6 80 00'); First := BinaryToUInt64_BE(@HexBytes[0], 7); Second := BinaryToUInt64_BE(@HexBytes[7], 7); Writeln(First); Writeln(Second); end; begin DecodeSumOrSomethingInto2UInt64; Readln; end. The result 36934908698 1000000000000000

More step 1) in security tab select your user and click edit 2) check all the allow to your user also remove readonly in case it is there also check if the your binary (EXE) has any combability enabled and disable it.