If context menu key that launches some executable exists in Windows registry and the "%1" command line patrameter place holder is mentioned, the path this executable gets over GetCommandLine() is limited to MAX_PATH and in some cases Windows tries to make the short path name out of it.
Example:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\showpath\command]
#="\"C:\\Program Files (x86)\\Utilities\\COMLINE.EXE\" \"%1\""
When the path is:
"\\\\SERVER\MediaFilder25\Philosophic\20220407 Draft thoughts. Questions without answers on the background of the torn Internet\20220407-1 Draft thoughts. Questions without answers on the background of the torn Internet\20220407 Draft thoughts. Questions without answers on the background of the torn Internet.ysssss"
COMLINE.EXE will get following:
"\\\\SERVER\MediaFilder25\39FC~1\202204~3\202204~2\20220407 Draft thoughts. Questions without answers on the background of the torn Internet.ysssss"
Nowadays string length isn't limited. NTFS path depth isn't limited, too.
How to overcome this?
There is a way in registry to allow long paths, explained in this URL.
I comes down to the following registry key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001
In order to know your current value, you might do this:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" | findstr "LongPathsEnabled"
It is limited to Windows 10, Version 1607, and Later, but your question is about Windows 7.
Windows 10, Version 1607 contains api-ms-win-core-path-l1-1-0.dll.
There is a replica version of api-ms-win-core-path-l1-1-0.dll that can manipulate long paths the way the Windows 10, Version 1607 it does.
Source code is available here: https://github.com/nalexandru/api-ms-win-core-path-HACK
I managed to compile it in Visual Studio 2012 after switching platform toolset to v110 and tested it successfully, for example, with Python 3.9 that relies now on this DLL.
I think, Windows 7 shell can't take advantage of using LongPathsEnabled registry parameter out of the box, and applications should use this DLL directly (but in this case - why to use a DLL? we can build the proper function right into the application). My question was whether the shell can take advantage of it, and the answer is - "not yet!". It depends on shell itself.
Related
Simple question : how to detect Windows version in a reliable way using Delphi 2007 ? Is there a way to do it without APIs ie, checking only some folder or files in system directory ?
Thanks in advance !
You cannot check a file or registry value without calling a Windows API function!
The only way to check the version without calling any API is to read from the PEB but most of the fields there are undocumented and could in theory change from version to version. It is also affected by the compatibility shims. I don't recommend that you do this but if you insist then this code might be a good starting point, just read the OSMajorVersion and OSMinorVersion members (Teb from GetTeb and Peb := Teb.Peb from Teb).
Microsoft recommends that you check if the feature you need exists instead of checking the version. The recommended way to check the version is with VerifyVersionInfo but you can still continue to use the deprecated GetVersionEx if you need the version number for display purposes. Both of these functions require a manifest to get the correct version on Windows 8.1 and 10.
In theory you can parse EXPLORER.EXE for its version details and then speculate on the Windows version. But every Delphi version uses for Pascal's blockread() implementation the WinApi again. And wanting tofind the Windows-directory (which can have any name on any drive) also leads to WinApi calls again.
Linux operating system identifies files by looking at its magic number at the starting of the header. How does windows do it ? Does it also have some kind of magic number mechanism or does it only rely on the file extension ?
It relies only on the extension, as provided by the filesystem; the contents of the file are not examined. See e.g. this article - it talks about Windows XP, but AFAIK the general behavior is shared by all released versions of Windows so far: http://support.microsoft.com/kb/307859
I just stumbled on this article on MSDN that says a path can be 259 characters + NUL termination, but if you prefix it with "\\?\" WinAPI allows you to use the
maximum total path length of 32,767 characters.
Eager to see it working I tried using that prefix from Explorer (On XP SP3) but it doesn't work at all (on any path). If you put \\?\C:\Path\to\an\existing.file on explorer's bar, it will give the "file not found" error.
So I'm confused. Can I code something for (non-ancient) Windows that makes full use of the mentioned path size on NTFS? Why Explorer doesn't use it?
There is a SET of API calls that are work with extened-paths and some that do not. The MSDN usually mentions this.
Not that if you just type that path into windows explorerunder xp this does not work, because the extened path syntax is just an escape sequence for the WIn32 API and not for windows explorer. Now, In Win7 this does work because many people expected this to work.
Also for long paths, it does help if you change the working directory or open up explorer with a sub-directory as a root.
Before someone tells me to RTFM...
Note that these examples are intended for use with the Windows API functions and do not all necessarily work with Windows shell applications such as Windows Explorer.
[...]
For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs.
On a secondary note, this makes me wonder about the possibilities of hiding files (or finding such files) from explorer by using illegal file names.
Are you asking why all components in Windows do not support it, or are you asking whether it's legal to use these long paths?
You can definitely safely use them, but you may irritate someone who wants to use tools like Explorer to browse them. We see paths like this all the time in the wild. Sometimes people are pretty surprised when they can't use MY_FAVORITE_TOOL to delete it...
I have a Win7 PC in use as part of an experiment control system. The experiment in question uses 4 windows simultaneously, and I would like to find away to open, position and size these 4 windows with a script.
The script would run at start up, so that the newly booted PC presents the user with the four windows as default.
Obviously I can use a batch file in the startup folder to open windows and run applications, but is there a way to specify the layout of these windows?
Many thanks
Si
Assuming that you have access to a scripting language that supports making calls to Windows API functions it shouldn't be too hard. Otherwise I'd suggest writing a small executable in some language (at least any of C++, C# or VB.Net would all work fine) and have that do it.
You could use FindWindow, as described here, to find the windows and MoveWindow, as described here, to move them around.
I use an AutoHotkey script to set up all my environment (around 7 windows in 3 different virtual screens), works pretty well. You can set the location of windows etc.
I can use a batch file to open the apps, then run WiLMA to relocate them
We have an installation program that runs in Perl 32-bit. This program needs to get information on cluster resources, so it runs cluster.exe (using backticks) and parse its output.
On Windows Server 2003 this went well, as a 32-bit version of cluster.exe existed under syswow64. However, such a 32-bit version does not exist on Windows Server 2008, so the backticks run of cluster.exe says it can't find such an executable, as 32-bit process look for it under syswow64.
Can someone think of a way we can bypass this problem and get the cluster resource information?
One manual way is to copy the 64-bit version of cmd.exe from system32, and then run it with "/c cluster.exe" which will start the 64-bit cluster.exe under system32. (Copying the cluster.exe won't work well, as it can't find the cluster cache.) However, this is only good as a manual workaround, and not as a solution to all users.
Is there another way to cause windows to start the 64-bit cluster.exe?
Thanks,splintor
PS
A similar question was asked on technet a month ago, but didn't get a real answer.
I found two possible solutions:
One is to write a small 64-bit application named cluster.exe that simply calls %SystemRoot%\System32\cluster.exe (using system()), and put it under %SystemRoot%\syswow64. Since it is a 64-bit application, the correct 64-bit cluster.exe application will be called.
Another solution is to use the sysnative redirection (as explained here), so now we check - if %SystemRoot%\System32\cluster.exe exists, we use it, else if %SystemRoot%\Sysnative\cluster.exe exists we use it, else we use plain cluster.exe.
Note: this is very similar to this telnet.exe problem that just got answered.