Hello!

A bit late to the party, but better late than never, I s'pose.

I was following along and everything was working as intended, if a bit readjusted to work within the context of current-day Windows 10 and VS's bad habit of moving everything around. But I guess it'd be weirder if absolutely nothing changed within 10+ years.

Anyway, I had everything operating as Casey had it, albeit while using Neovim instead of Emacs, but the next day when I tried to compile with 'cl' it failed to recognize it, despite no change to the misc. configuring, the tweaks to the Command Prompt's properties, and the build.bat file.

Anyone have any insight or places I might go poke around to figure out why settings aren't staying set?

EDIT:

Right, so I got it to compile with build.bat, everything's working fine on that end after manually re-substituting W:\ for the right filepath. Which means it was some failure of startup.bat, though why it didn't run is still a mystery.

My guess is Windows 10 doesn't automatically run .bat files at log-in anymore, or if they do the filepath needs to be pointing at some other directory.

Right now it's "C:\Users\username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup" as it was in Casey's case (heh) w/ Win 7

I strongly suggest to not use "subst" drives for this. Sooner or later it will give you various problems. For example, debuggers, profilers and similar tools will be confused about source code locations - because sometimes pdb files will contain real path, sometimes subst path, and these tools will see two different paths for same source file. Other reason is admin privileges - sometimes you'll want to run something with admin rights, like ETW profiling or similar, and then the subst drive won't work.

Just create c:\w or similar folder if you need to write absolute path and want to have it be short string.

That tracks with what I might've assumed to be a good practice, I was merely following along with Casey, mostly verbatim. Thanks for the input, though, much appreciated. Hadn't even considered event tracing.

It'd be interesting to see if anyone else familiar with Windows and its potential for tomfoolery might have any insight as to why batch files (seemingly) no longer get executed at startup from the eponymous folder. I get that that's like searching for a needle in a haystack when accounting for an eleven-year gap in OS changes, but I'll leave this thread open for a while yet.

bat files from startup folder gets executed just fine, even on Windows11. What exactly is inside bat file you are you executing from there? If you're setting env variables then those won't be available for anybody else. As environment is only process local (plus inherited by child processes). This works the same regardless of Windows version.

Btw to quickly open startup folder location you can enter shell:startup in Win+R.