Kas Ob.

You did not mention if there is background thread, also more details will help, like importing from files on local disk, network disk, internet .... When running with debugger how much time does it take ? so many details may be you are missing, and we are gonna just guess. Brain answer is right on point, and i want to add one more situation where i saw more or less similar behavior, you most likely have loops and checks processing these data, and one critical variable is not initialized, like, a situation where inside the debugger the value by default is X (may be 0 or just something) and without the debugger it is not X, so the fast way to check is after running and application and it went white (froze), attach the debugger and try to make sense from the stack, step and run and follow the main thread running. or generate a detailed log for your loops, every loop or just log the import and process in few checkpoints and follow which one is the faulty then expand on that section with more logging, you can use DebugOutputString or any other logging method, all will do.

I faced this problem many time and almost always, converted the view into table, So i would suggest ,to make the file name and line number as they are, move the result to right and up, hence the first line in each section (result) will have the file name and the first result and line number while the result form the same file will only result under the first one, hope that is clear, also make the result switch background color for the same file, between two or more color, something easy on the eyes but yet will show the result grouping. Well Windows Paint is not Photoshop, yet i am happy with my Paint talent 😎

I have this theory, The call stack is clearly shows this sequence calls SysInit -> System -> SysUtils, but based on my observation and my lack to trust the map file, which me be unfounded, anyway, SysUtils called few times before Initialization for class constructor for TLanguages, TEncoding, Exception.Create, TOSVersion.Create then Initialization So the question here, do you overload (define) an Exception and use it in some Initialization section for some unit, or any of the rest mentioned above ? This might confused the compiler and Exception is not initialized yet and its value is just arbitrary, this might explain the first success and a failure on the second.

It would be nice if share with us your final result for best solution, and thank you in advance.

Away from the first two it looks accurate, never looked into it, thank you.

One more thing about this In my Delphi XE8 and as i witnessed many times, the map unit list is not accurate, in this case, SysInit is initialized first before System, Winapi.Windows comes after SysInit, then System..

Because the map file provides that information already. For instance for Win64 binaries you will see at the top of the map file lines like I do put some command line parameter to few of my projects, for tracking when things goes wrong, like one parameter and the exe will dump a file with few things like the build settings, versions of used 3rd party packages, also a list of included units, in these projects as have multiple units handle the same protocol or part of the protocol/structures while separated by version number in the unit name, if they are added then they will register them selves and handle backward compatibility, so i need to check after the fact is they are present, so no debug information or map file, these info from an exe that is protected by WinLicense so unless the exe itself generate these info no one can. I asked because i saw you mention after the begin in project file, and i thought you may have better solution or at least i can learn soemthing.

To my past working on resampling and resizing up and down, i found that Mitchell and Robidoux filter is superior to Lanczos(3) in speed and quality specially in halo reduction and color defects. https://legacy.imagemagick.org/Usage/filter/#mitchell https://legacy.imagemagick.org/Usage/filter/nicolas/ I added them to AlphaSkin few years back and it seems i failed to deliver them to the author, shame on me after all that work. Anyway found my old test project, and here a sample of the a result With Lanczos3 the halo effect is very visible inside the boxes and there a skyblue color above the T also there a yellow on left side of the red. While Mitchell and Robidoux (default, sharp and soft) , doesn't have halo and blue but the yellow exist Downsizing As seen above and as i remember with many images, Robidoux sharp was the best for upsizing, and Robidoux soft was the best in downsizing. And here are the parameters for Robidoux ftRobidoux: if Param < 1.0 then W := Sqr(Param) * (1.1218 * Param - 1.9327) + 0.8739 else W := Sqr(Param) * (-0.3739 * Param + 1.9327) - 3.2436 * Param + 1.7478; ftRobidouxSharp: if Param < 1.0 then W := Sqr(Param) * (1.238 * Param - 2.107) + 0.9126 else W := Sqr(Param) * (-0.4126 * Param + 2.1069) - 3.4759 * Param + 1.8253; ftRobidouxSoft: if Param < 1.0 then W := Sqr(Param) * (0.8204 * Param -1.4806) + 0.7734 else W := Sqr(Param) * (-0.2734 * Param + 1.4806) - 2.6408 * Param + 1.5469; No Mitchell though because it is already in AlphaSkin and i don't want to paste code that is not mine.

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.