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

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

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

    Join 1,603 other followers

Archive for the ‘The Old New Thing’ Category

« Previous Entries

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 [WayBack] A 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: [WayBack] Remember 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:

[WayBack] 6502.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.

[WayBack] 6502.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 »

Reading files that are locked by other references: c# – Notepad beats them all? – Stack Overflow

Posted by jpluimers on 2018/08/16

Cool feature borrowed from Notepad, which can read files locked by other references (for instance a process having the handle open): [WayBack] c# – Notepad beats them all? – Stack Overflow.

The example from the answer is in .NET, but can be used in a native environment as well (Notepad is a native application).

Notepad reads files by first mapping them into memory, rather than using the “usual” file reading mechanisms presumably used by the other editors you tried. This method allows reading of files even if they have an exclusive range-based locks.

You can achieve the same in C# with something along the lines of:

using (var f = new FileStream(processIdPath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
using (var m = MemoryMappedFile.CreateFromFile(f, null, 0, MemoryMappedFileAccess.Read, null, HandleInheritability.None, true))
using (var s = m.CreateViewStream(0, 0, MemoryMappedFileAccess.Read))
using (var r = new StreamReader(s))
{
    var l = r.ReadToEnd();
    Console.WriteLine(l);
}

Via: [WayBack] Maintaining Notepad is not a full-time job, but it’s not an empty job either – The Old New Thing

–jeroen

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

Some links on how Windows detects if a program “is not responding”

Posted by jpluimers on 2018/05/09

For my research list:

–jeroen

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

« Previous Entries
 
%d bloggers like this: