DelphiUdIT

I am curious to know the reason why to develop such a large amount of technology in a mobile application. Development environments (SDK Android, IOS, Google, etc ...) are not stable over time and change very quickly based on the release of the OS. This forces continuous maintenance in the code, especially in cases like these (as @Dalija Prasnikar also mentioned) ... Not to mention the hardware resources and all the cons ... I would not say that developing such an application for mobile devices is a wise choice, but surely I'm wrong ...

Hi, I was doing some tests and I came across a strange "behavior". The code here simply performs a division between a random value taken from an array and a constant via an assembler function, and returns the result of the division in integer and the remainder. Program Project1; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Diagnostics; //WinApi.Windows, {$IFDEF CPUX64} function DivandMod(Dividendo: UInt32; Divisore: UInt32; var Resto: UInt32): UInt32; overload; asm .noframe mov EAX, ECX mov ECX, EDX xor EDX, EDX div ECX mov DWORD PTR [R8], EDX end; {$ENDIF} const counting = 500_000_000; var i, k: UInt32; t: TStopWatch; a: TArray<UInt32>; resto: UInt32; //risultato: UInt32; //prochandle: THandle; begin // procHandle := GetCurrentProcess; // SetProcessAffinityMask(prochandle, $1); SetLength(a, counting + 1); t := TStopWatch.StartNew; for i := 0 to counting do a[i] := Random(High(Int32)); t.Stop; WriteLn('Load random values:':20, t.ElapsedMilliseconds); for k := 1 to 3 do begin t := TStopWatch.StartNew; for i := 0 to counting do DivandMod(a[i], 2039, resto); // risultato := DivandMod(-12, 7, resto); t.Stop; WriteLn('Test:':20, t.ElapsedMilliseconds); end; writeln(''); writeln('Press any key to close the program'); ReadLn; end. Now the code if compiled with the options "Overflow checking" and "Range checking" (typical of debugging) enabled has the times (in ms.) listed here: If they are disabled I would expect the times to improve, instead they get worse: Does anyone have any idea why? I noticed this because when running the program in RELEASE mode the times increased. I wasted some time trying to understand why, then simply activating or deactivating those options changes occur (this is independent of the DEBUG or RELEASE mode). Try with Windows 11, I9 14900HX , Delphi 12.2 last patch, project build for X64 without optimization and without stack frames.

You might be right.

I can change the two options in DEBUG or RELEASE and the final otput is the same, there are not difference between RELEASE and DEBUG: if I uncheck them in RELEASE the time increased like if I uncheck them in DEBUG. And I'm sure about the "inversion". I think the same. That is really strange, 'cause the instructions executed are the same in either (with or without check) but there are more others with check. And the "processor logic" seems to prefer the long path ....

This is a link for software to initialize the sim card: https://support.certum.eu/en/cert-offer-card-manager/ According to this: I will do it now with my new set ... EDIT: I can confirm that the sim card can be initialize with the software (link provided above) and you can SET your free fantasy PIN and PUK.

But this means that you can use the sim without PIN ? Of course, not maximun security, but certainly a minimal annoyance. I'll have the "kit" this evening and tomorrow I'll see the various options for playing with it.

I bought an EV certificate yesterday from Certum ( @Patrick PREMARTIN talked about it in a previous post) obviously on physical media (USB Reader + SIM). And they confirmed to me that the SIM is "virgin", it will be written with the certificates once it arrives in my possession and after confirmation of the header data. Again, with each update (I will do it after three years) both the public and private key will be lost because everything will be overwritten. Now I await delivery and the subsequent activation processes. I don't know if the "writing" and activation process will be online or if they will send me something.

You can simply do from IDE (start it with administror privilege): Double click on "Register":

I start in Delphi using Rad Studio and I missed lots of "voices" of refactoring menu, they are disabled. (CTRl SHITF E) open the search tab (like if you press (CTRL F)). I don't have that exception. My "interop" are inside "bin" folder and there is a TLB file that you can use to register the "type library".

To capture the screen you can simply make a video with your smartphone.

I have a monitor (laptop) 2560 x 1660 with 100% scale and a secondary monitor FULL HD. I don't have this issue in whatever configuration I set (like @dummzeuch). I can resize the panels and it's working. Bye

I have been using it for many years and have never changed it... int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved) {....}

And where exactly? It would be useful to know...

Me too thought that. And it's for this that I start using inline variable, sò no one can use the "index" outside the loop. Bye

The structure was changed and reported to the release notes: The new field "val" is an Hcpar type. It contains the old "HPar" members ("par" pointer) and "&type". So, while before it was possible to access the value of the Tuple directly, now it is accessed via "par": var fDeviceHandle: HTuple; ----- //New way if fDeviceHandle.val.par.l <> 0 then ..... //Old way if fDeviceHandle.val.l <> 0 then Other important thing is that the float field "f" doesn't exist anymore .... (I dont' know any official notes about that). This should not have a major impact on the code, since "f" is a further definition of an identically field type "d", so replacing "f" with "d" in the code will make both the old and new code compile without errors and without any {$IFDEF... This is the first time in many years that they have changed the interface to a basic structure like HTuple making the code totally incompatible with the past. In the past they had changed some definition of some parameters, but by changing only the declaration of the variable everything was back to normal without any change in the "procedural" code (I remember something about the parameters of the "get_mposition" function for example). What I did: 1) Copy all include files (except Halcon.h) in a single directory wherever you want; 2) Run CHET (this is my example): You will see some errors about include files not found ... change the relative path in the source originated the error. Retry the RUN, and go redoing the same until all errors are gone. After that you have the PAS file. Now You have to change (in reality move at the top of file) some declarations, for obviuos reasons that you will see ... is more complicated to explain that to do. Some change to definitions (like NULL), and you should also modifiy some declarations that point to wrong DLL, refer to my original wrapper searching for "LIB_MVTEC_SYSTEM". Without this you will have a runtime error in the application if you use some system functions. A little bit too: you must delete (or divide) some very long commented lines: That's all.

For a long time I have always used the form "\\?\". It has some advantages (like bypass MAX_PATH limits and the name parsing). See here: https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#win32-file-namespaces Bye

For something to be patentable it must have a creative and innovative character. I don't think that a few lines of assembler can be considered as such.

Catch the clipboard is really simply, why don't you do it ? Using the JvClipboardMonitor, you can "ear" all "copy" actions, you can also choose what you are cacthing (look at source of JvClipboardMonitor and Microsoft docs). That example is simple, no control about the "paste". That catch also the administrator level "copy" and all copy / paste password .... like @Brandon Staggs said. unit Unit1; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, JvComponentBase, JvClipboardMonitor, Vcl.StdCtrls; type TForm1 = class(TForm) JvClipboardMonitor1: TJvClipboardMonitor; Memo1: TMemo; procedure JvClipboardMonitor1Change(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.JvClipboardMonitor1Change(Sender: TObject); begin Memo1.PasteFromClipboard; Memo1.Lines.Add(#10#13); end; end.

I update this topic 'cause new versions are released of Halcon (and quote Matthias that were interested about that). I post a Delphi wrapper around this, not a really Delphi wrapper, only a porting from C headers that I have done with CHET. Take care that some adjustments should be done from your previous sources because in Halcon are changed some records (Tuples), and for other reasons too. Read carefully the "Release Notes for HALCON 24.11.1.0 Progress-Steady" (https://www.mvtec.com/products/halcon/work-with-halcon/documentation/release-notes-2411-1) for full details. I tried the new wrapper only partially. Bye HalconC_2411.pas

The indication on the "GOTO" page is not precise, it was always like this.

Something wrong with your update, the build should be "29.0.53982.0329" ...

A digital signature remains valid until it or the issuing certificate (chain trust) is revoked. When it expires in time, it is still considered valid. You cannot use a certificateto for signing purpose that has already expired, obviously. As for OSCP and CRL, in any case the possibility of invalidating a signature (or a certificate) must be guaranteed ... it is the basis of the concept of public signature. I don't know for how long it will still be possible to use "file" certificates like those of LET'S Encrypt for uses other than simple SSL ... the legislation (for example the Italian one) considers the digital signature valid ONLY and EXCLUSIVELY if produced by HARDWARE devices (specific), and it seems to me that the rest of the world follows this. So certificates with a validity of less than 1 year are not feasible if combined with classic USB TOKENS for example. Bye

A public signature is subject to revocation, which I can imagine would happen very quickly if a malware signature is verified. Also, the signature would be easily identifiable and the malware could therefore be blocked in virtually "zero time".

And all the features about 12.2 Release. The CE edition is like the 12.1.

Here will be all features for the various RAD Studio Editions (included CE): https://www.embarcadero.com/docs/rad-studio-feature-matrix.pdf