The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,729 other followers

Archive for the ‘The Old New Thing’ Category

Terminate threads during application or not?

Posted by jpluimers on 2019/10/02

I got an interesting question a while ago: should an application terminate (anonymous) threads or not?

A problem is that a thread might not execute unless you call WaitFor before Terminate is called. The reason is that the internal function ThreadProc does not start Execute if the thread is already terminated.

The ThreadProc in the System.Classes unit is an ideal place to set breakpoints in order to see which threads might start.

Other useful places to set breakpoints:

  • TAnonymousThread.Execute
  • TExternalThread.Execute

Execute not being called by ThreadProc is a bug, but it is not documented because QC is gone (taking the below entry with it), it is not in QP and the docwiki never got updated.

Given QC has so much information, I am still baffled that Embarcadero took it down.

Sergey Kasandrov (a.k.a. serg or sergworks) wrote in [WayBack] Sleep sort and TThread corner case | The Programming Works about this bug and refers to WayBack: QualityCentral 35451 – TThread implementation doesn’t guarantee that thread’s Execute method will be called at all .

The really bad thing are the WayBack: QualityCentral Resolution Entries for Report #35451 Resolution “As Designed” implying the design is wrong.

In his post, sergworks implemented the Sleep sorting in Delphi. Related:

Note that application shutdown is a much debated topic. Best is to do as little cleanup as possible: your process is going to terminate soon anyway. No need to close handles or free memory: Windows will do that for you anyway. See for instance:

 

Related to waiting:

Related to executing:

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Multi-Threading / Concurrency, Software Development, The Old New Thing, Windows Development | Leave a Comment »

When an installer errors out with “Please re-run this installer as a normal user instead of”…

Posted by jpluimers on 2019/08/12

Via [WayBack] Anyone with a hint on how to work around this: … “Please re-run this installer as a normal user instead of”… – Jeroen Wiert Pluimers – Google+

This happened for instance when trying to install Source Tree 2.x on Windows (1.9.x works fine):

[Window Title]
SourceTreeSetup-2.3.1.0.exe

[Main Instruction]
Installation has failed

[Content]
Please re-run this installer as a normal user instead of “Run as Administrator”.

[Close]

The problem was by accident the machine got in a state to run commands without UAC approval, so the run dialog would already look have “This task will be created with administrative privileges”:

It was odd, as the machine didn’t have it enabled in the security policy (secpo.msc):

So I did a bit more digging, bumped into [WayBack] Why does my Run dialog say that tasks will created with administrative privileges? – The Old New Thing and had one of those #facepalm moments: Explorer had crashed, and I had started it from Process Explorer, forgetting Process Explorer had an UAC token.

The solution is easy:

  1. Logoff / Logon
  2. Verify the Windows-R shows a “normal” run:

Then you can just run the installer:

–jeroen

Posted in Batch-Files, Console (command prompt window), Development, Power User, Scripting, Software Development, The Old New Thing, Windows, Windows Development | Leave a Comment »

A 90-byte “whereis” program – The Old New Thing

Posted by jpluimers on 2018/11/23

I needed a “get only the first result” of WHERE (which is present after Windows 2000, so XP, Server 2003 and up), so based on [WayBackA 90-byte “whereis” program – The Old New Thing I came up with this:

@echo off
:: based on https://blogs.msdn.microsoft.com/oldnewthing/20050120-00/?p=36653
::for %%f in (%1) do @echo.%%~$PATH:f
for %%e in (%PATHEXT%) do @for %%i in (%1 %~n1%%e) do (
  @if NOT "%%~$PATH:i"=="" (
    echo %%~$PATH:i
    goto :eof
  )
)
:: note: WHERE lists all occurrences of a file on the PATH in PATH order
goto :eof

Two changes:

  • it takes into account the extension if you specify it (unlike WHERE.EXE)
  • it bails out at the first match (like WHERE.EXE)

References:

–jeroen

Posted in Batch-Files, Development, Power User, Scripting, Software Development, The Old New Thing, Windows, Windows Development | Leave a Comment »

Solution for Delphi – post-build event with multiple if/copy combinations only execute if first file does not exist – Stack Overflow

Posted by jpluimers on 2018/11/15

My solution in [WayBack] delphi – post-build event with multiple if/copy combinations only execute if first file does not exist – Stack Overflow is an addendum to my 2014 post Delphi prebuild/prelink/postbuild events.

Here we go:

Q

Given the bin\ directory inside the Delphi project contains the files Cert.pem and Key.pem, the below Delphi post-build event only copies both files if C:\Binaries\Cert.pem does not exist:

if not exist $(OUTPUTDIR)Cert.pem (copy bin\Cert.pem $(OUTPUTDIR))
if not exist $(OUTPUTDIR)Key.pem (copy bin\Key.pem $(OUTPUTDIR))

As soon as C:\Binaries\Cert.pem exists, the Key.pem file is never copied.

How can I solve this in the post-build event?

Edit: unlike my 2014 post, this is indeed possible using parentheses. See my answer below.

A

The problem with Delphi post-build events is that they are not batch files.

It means that statements that look like lines are being concatenated by the Delphi IDE into one big & ampersand separated statement. This ensures the commands are executed in sequence, as per Command Redirection, Pipes – Windows CMD – SS64.com:

commandA &  commandB      Run commandA and then run commandB

So this is the actual statement that gets executed:

if not exist $(OUTPUTDIR)Cert.pem (copy bin\Cert.pem $(OUTPUTDIR))&if not exist $(OUTPUTDIR)Key.pem (copy bin\Key.pem $(OUTPUTDIR))

The problem here is that now the second if is seen as a continuation of the “then” part of the first if statement: the second if never executes when the $(OUTPUTDIR)Cert.pem exists.

What helps is a little known feature that you can wrap each command inside parentheses. Normally this is to allow one command to span multiple lines (especially for if, and for..do loops), but it also works on one line.

Wrapping each line having an if statement inside parentheses ensures they become standalone statements not affecting the other lines, even if they are being concatenated with & ampersand separators.

In the dialog it looks like this:

(if not exist $(OUTPUTDIR)Cert.pem (copy bin\Cert.pem $(OUTPUTDIR)))
(if not exist $(OUTPUTDIR)Key.pem (copy bin\Key.pem $(OUTPUTDIR)))

That way, the IDE translates it into one statement:

(if not exist $(OUTPUTDIR)Cert.pem (copy bin\Cert.pem $(OUTPUTDIR)))&(if not exist $(OUTPUTDIR)Key.pem (copy bin\Key.pem $(OUTPUTDIR)))

Now it works as intended:

  • When $(OUTPUTDIR)Cert.pem exists but $(OUTPUTDIR)Key.pem does not, only $(OUTPUTDIR)Cert.pem is copied
  • When $(OUTPUTDIR)Cert.pem does exists but $(OUTPUTDIR)Key.pem does, only $(OUTPUTDIR)Key.pem is copied
  • when neither exist, both are copied
  • when both exist, neither are copied

I did not know this “trick” when writing my 2014 post Delphi prebuild/prelink/postbuild events, so I need to write an update for it.

Searching for batch file parentheses site:microsoft.com -site:social.technet.microsoft.com -site:answers.microsoft.com did not reveal it in the official documentation, but I am not surprised as it grew hysterically, instead of being designed. Or like the Old New Thing attributes h2g2:

Much like the universe, if anyone ever does fully come to understand Batch then the language will instantly be replaced by an infinitely weirder and more complex version of itself. This has obviously happened at least once before ;)

The best documentation I could find was at Parenthesis/Brackets – Windows CMD – SS64.com:

Parenthesis can be used to split commands across multiple lines. This can make code more readable. Variables will be evaluated for the code block just as if the command was a single line.

 (command)

 (
  command
  command )

Things that break inside parenthesis The CMD shell does not use any great intelligence when evaluating parenthesis, so for example the command below will fail:

IF EXIST MyFile.txt (ECHO Some(more)Potatoes)

–jeroen

Posted in Delphi, Development, Software Development, The Old New Thing, Windows Development | Leave a Comment »

A refefernce to 6502 by “Remember that in a stack trace, the addresses are return addresses, not call addresses – The Old New Thing”

Posted by jpluimers on 2018/09/11

On x86/x64/ARM/…:

It’s where the function is going to return to, not where it came from.

And:

Bonus chatter: This reminds me of a quirk of the 6502 processor: When it pushed the return address onto the stack, it actually pushed the return address minus one. This is an artifact of the way the 6502 is implemented, but it results in the nice feature that the stack trace gives you the line number of the call instruction.

Of course, this is all hypothetical, because 6502 debuggers didn’t have fancy features like stack traces or line numbers.

Source: [WayBackRemember that in a stack trace, the addresses are return addresses, not call addresses – The Old New Thing

Which resulted in these comments at [WayBack] CC +mos6502 – Jeroen Wiert Pluimers – Google+:

  • mos6502: And don’t forget the crucial difference in PC on 6502 between RTS and RTI!
  • Jeroen Wiert Pluimers: +mos6502 I totally forgot about that one. Thanks for reminding me
    <<Note that unlike RTS, the return address on the stack is the actual address rather than the address-1.>>

References:

[WayBack6502.org: Tutorials and Aids – RTI

RTI retrieves the Processor Status Word (flags) and the Program Counter from the stack in that order (interrupts push the PC first and then the PSW).

Note that unlike RTS, the return address on the stack is the actual address rather than the address-1.

[WayBack6502.org: Tutorials and Aids – RTS

RTS pulls the top two bytes off the stack (low byte first) and transfers program control to that address+1. It is used, as expected, to exit a subroutine invoked via JSR which pushed the address-1.

RTS is frequently used to implement a jump table where addresses-1 are pushed onto the stack and accessed via RTS eg. to access the second of four routines.

–jeroen

Posted in 6502, 6502 Assembly, Assembly Language, Development, History, Software Development, The Old New Thing, Windows Development, x64, x86 | Leave a Comment »

 
%d bloggers like this: