Yeah, Notepad++'s uninstall.exe is PATH-hostile and poor planning. In 
other cases even adjacent DLLs can get in the way since they're eligible 
for resolving dependencies. Notepad++ is a good candidate for a command 
alias.

You don't need to modify alias.c to achieve this, though. You only need to 
provide a path relative to the alias program. For example, if you have a 
"bin" directory in your profile directory (assuming standard location), 
you can install the alias in there with this EXE path:

gcc -DEXE="../../../Program Files/Notepad++/notepad++.exe" ...

Since that's awkward, I just modified alias.c to support absolute paths 
starting with a drive. See w64devkit commit 0b63b1c. That permits:

This was a problem I had intended to solve with the "elfeed-web" part of 
Elfeed. The plan was to visit using a browser on a mobile device and use 
the links to open tabs, if not just read inline. However, it wasn't useful 
enough to me, and I've only kept it around because it has users. If it's a 
long-form article I want to read more comfortably, I manually navigate and 
open it on my tablet. (It's shocking the number of websites that make this 
difficult, as though they don't want visitors.) There's an Android app, 
not written by me, linked in the README, though I don't know the state of 
it, nor is it helpful for iOS.

If you have some sort of browser sync, maybe you could open the article in 
your browser on your computer, then use the browser to sync it with your 
other devices.

With a good-quality hash (especially xorshift finalized) it's unnecessary, 
and "higher" vs. "highest" will have no measurable difference. When using 
a multiplicative hash like FNV-1a without a finalizer, you probably want 
to use the highest bits since they're higher quality, and specifically 
using the highest bits may let you avoid paying for a finalizer. On the 
other hand, Java's String.hashCode() has poor-quality high bits (i.e. 
zeros) for short inputs. To a certain degree it's about knowing your 
inputs.

I picked the highest bits for my example since it's simple, obvious, and 
maximizes the effect. Sometimes I've even used overlapping regions of the 
hash which, as you noticed, can't happen in my example. My example would 
reasonably still work well with a 32-bit hash input, overlapping when exp 
is 17 or greater. (The main detriment may be in the hash function itself

> what other options do you have potentially in mind?

* Tell w64devkit.exe to start a new console window instead of reusing the 
one it was given.

* The "clear the environment" idea I mentioned since it's difficult to 
accomplish in the .profile. Could help normalize the environment across 
different machines by keeping the local junk out of the way.

* CreateProcess options. For example, starting the shell under a new job 
object with a "kill on job close" flag. I've been experimenting with 
running w64devkit, including the home directory, from a thumb drive using 
the new .ini configuration. I've found GnuPG Agent even more irritating 
than usual. It prevents me from ejecting the drive until I manually kill

I have a small surprise for you, Peter. Instead of "w64devkithome.txt" I 
have opted for "w64devkit.ini" which currently lives on the "ini" branch:

https://github.com/skeeto/w64devkit/commit/8db776f

It supports variable expansion and paths relative to the .ini file. You'd 
use "home = ..\homedir" in your case. I went for an .ini file since I 
figured this would grow more options in the future.

I carefully read the .ini file as UTF-8 and pass wide paths to Windows, 
though unfortunately busybox-w32 remains limited by the narrow API.

I'm going to dogfood this for awhile, in case I notice issues and to 
incorporate feedback you or others might have.

> I can't really think of why this would be useful

I occasionally use invocations like "env - PATH=/usr/bin" on Linux, and 
similar on Windows with w64devkit in order to establish a clean(er) 
environment for testing and reproduction. I may even set a temporary HOME 
to keep (most) programs from reading custom configs. In particular, some 
application defaults are poor or newbie-oriented, the default can be 
overridden by an environment variable — directly or indirectly — so I do 
so. Then I eventually forget that I'm not running the default. It's an 
easy way to wipe the slate clean.

For Windows this also means clearing out junk added to the environment by 
various installers, which may interfere with issue reproduction. (A stray 
PYTHONHOME or JAVA_HOME, etc.)

Interesting, Peter, thanks! I'd been considering adding environment 
variable arguments to w64devkit.exe, a la make and configure scripts:

    w64devkit.exe HOME=C:\path\to\home PATH+=c:\git\cmd

You'd include such arguments in a shortcut target, then launch w64devkit 
from that shortcut. There would also be syntax to compute an absolute path 
from a path relative to w64devkit.exe (a la %~dp0), though I haven't 
worked that out. That would be essential for your use case.

If one of the arguments is "-" (or maybe "-i"?) then it would delete all 
environment variables, a la the "env" command, giving you a clean slate. 
Though it might leave a couple special, soft-required variables behind 
like SYSTEMROOT and TEMP, since many programs break badly when these are

If it's not atomic then it's a data race since there's a concurrent store 
and load on the same memory location, which simply isn't allowed. Even if 
the result is provably correct for all possible orderings, it's still 
undefined behavior. There may be unanticipated effects beyond reordering, 
though no particular examples come to mind at the moment.

Quick followup: Simply searching for the title readily produces a 1st 
edition PDF, which is exactly what I wanted. I have since finished reading 
it, and I was very impressed. Your recommendation was sound and on point! 

I don't agree with everything — particularly parts of the candy-machine 
interfaces chapter — but overall it's full of great, practical advice. 
It's provided me with more techniques for automatically findings bugs, and 
I'm sure I'll be putting some of it into practice in the future.

Thanks for the tips, Miguel!