SysWow64 issues with 32 bit Notepad++
Ok, so this issue has been discussed a couple of times:
But i don’t think this have been answered properly…there is a huge problem with NPP. I’m using 6.9.1 (latest as of today).
Recreation of issue is simple. On Windows 2012 R2 (though I suspect any 64-bit OS), install the 32-bit version of the software.
Save a file to c:\windows\system32\myfile.txt.
The file does not get created in this location, but rather in c:\windows\syswow64\system32
As if that’s not bad enough, navigate to the actual file “c:\windows\system32\myfile.txt” and right-click to open in NPP.
Then, edit the file and save it.
NPP doesn’t save to the location of the file you attempted to edit, but rather to the syswow64 location.
All of this is done without any evidence.
This threw me for a loop for a bit until I figured out what was going on.
I don’t know what the best answer is…but not being notified at all on this behavior and not being able AT ALL to edit files in the TRUE directory (not syswow64) is just unreasonable.
Isn’t it time that NPP make a true 64-bit version? Virtually no one has been running 32-bit OS for years now.
I have been using NPP for a while and can’t believe I didn’t notice this until now, very sad as I’m not sure I can rely on this app anymore :/
I agree with the point about not being notified of different folder/file
but I disagree about not being able AT ALL to edit files.
You linked to two posts, the first one already mentions the sysnative alias which
can be used to force the system32 directory being used.
Btw. why isn’t it properly answered?
It’s not properly answered as in a proper solution does not exist.
I’ve been using the product for a few years, but I am not a “power user” there are only a few of the bells and whistles as to why i prefer this over NP, and a rarely use any plugins. I’m not active on the forums, so I’m not sure why a 64-bit solution doesn’t exist at this point. Could you provide a brief answer as to why?
It would be great if we can get some sort of notification as to the redirection. The worst use case is when actually clicking on a file to edit and then saved changes are redirected somewhere else completely. This is what I meant by can’t edit them at all. Technically you can edit them, but you are limited to opening them from within NPP and remembering to use sysnative. The sysnative alias doesn’t work to browse via explorer.
I wonder the possibility of adding in a preference that would somehow intercept calls to c:\windows\system32 and redirect them to c:\windows\sysnative? Agreed that behavior could be confusing as well but it would be an option that could help.
At the very least, when opening a file from system32, maybe a dismissable prompt/warning of what is actually happening and how to remediate it would go a long way.
Could you provide a brief answer as to why?
Just to make clear - I’m a npp user as you are, so my answer on this is just my assumption nothing official.
In general there isn’t much benefit of having a 64bit over an 32bit version of a program. Memory allocation benefits most
of it but for most “normal” users memory allocation beyond 4GB isn’t important. But making a program work for both
environments isn’t trivial all the time especially when using 3rd party libraries like scintilla which of course must then also support
64-bitness. From npp repository we can see that work is in progress but I can’t say when it is done.
From my point of view I would love to see a warning, in whatever way, if someone edits a file which is assumed to be in system32
but current loaded is different.