The MASM Forum

Works fine:
  wLet edi="\\?\C:\Masm32\"+wRec$(String$(9, "Abcdefghijklmnopqrstuvwxyz"))+wRec$(".txt")
  invoke CreateFileW, edi,
  GENERIC_WRITE, FILE_SHARE_WRITE, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0

Chokes with ERROR_INVALID_NAME:
  wLet edi="\\?\C:\Masm32\"+wRec$(String$(10, "Abcdefghijklmnopqrstuvwxyz"))+wRec$(".txt")
  invoke CreateFileW, edi,
  GENERIC_WRITE, FILE_SHARE_WRITE, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0

The only difference is that the first string has 252 characters, the second one 278...

\\?\C:\Masm32\AbcdefghijklmnopqrstuvwxyzAbcdefghijklmnopqrstuvwxyz.txt

The ancient Win32.hlp file says this:

QuoteWindows NT: You can use paths longer than MAX_PATH characters by calling the wide (W) version of CreateFile and prepending "\\?\" to the path. The "\\?\" tells the function to turn off path parsing. This lets you use paths that are nearly 32,000 Unicode characters long.

The current doc (https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew) says this:

QuoteIn the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, use this Unicode version of the function and prepend "\\?\" to the path.

See e.g. this CodeProject discussion (https://www.codeproject.com/Lounge.aspx?fid=1159&df=90&mpp=25&sort=Position&spc=Relaxed&select=5370170&tid=5370002) for inspiration.

This is on Windows 7-64 with an XP manifest. Testbed attached.


    SendMessage hEdit,%EM_EXLIMITTEXT,0,-1


Nobody wants to solve the mystery?

I think nobody like files with long names  :biggrin:

Hi
There are more constrains than just the path limit https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd#:~:text=This%20type%20of,very%20long%20path%22. (https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd#:~:text=This%20type%20of,very%20long%20path%22.)

But good point JJ  :thumbsup:

Biterider

Thanks, Biterider - you deserve the cigar. Indeed, the doc you found says:

QuoteThis type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters).

However, you need an awful lot of clicking to find this particular document, and you need to read it very carefully to understand that each component has a 255 chars limit. An excellent example of s*tty Micros*t documentation.

Quote from: jj2007 on April 24, 2022, 04:49:42 AM
An excellent example of s*tty Micros*t documentation.

It's a comercial enterprise. They follow a simple axioma: you must write documentation for users, because you want more users. It's not a cruzade to redeem strange people.  :biggrin:

Hi
Reading the document a few lines further, you will find:
"Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior."

To do so, you have to:
1. The registry key computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled (Type: REG_DWORD) must exist and be set to 1

2. The application manifest must also include the longPathAware element.
<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

It would be a good idea to include this manifest element in new binaries by default :icon_idea:

Biterider

Quote from: HSE on April 24, 2022, 12:40:14 PM

Quote from: jj2007 on April 24, 2022, 04:49:42 AM
An excellent example of s*tty Micros*t documentation.

It's a comercial enterprise. They follow a simple axioma: you must write documentation for users, because you want more users. It's not a cruzade to redeem strange people.  :biggrin:

They follow the orders of the European Commission :biggrin:

QuoteOn 10 December 1998, Sun made an application to the Commission pursuant to
Article 3 of Regulation No 17 for the initiation of proceedings against Microsoft
("Sun's Complaint"). Sun alleged that Microsoft enjoyed a dominant position as a
supplier of a certain type of software product called operating systems for personal
computers ("PC operating systems"). Sun further contended that Microsoft infringed
Article 82 of the Treaty by reserving to itself information that certain software
products for network computing, called work group server operating systems, need to
interoperate fully with Microsoft's PC operating systems. According to Sun, the
withheld interoperability information is necessary to viably compete as a work group
server operating system supplier.

Google microsoft documentation "european Commission" "Sherman Act" "sun" to find it...

I searched "crazy people using long file names".
Funny thing, only M$ use that  :biggrin: :biggrin: :biggrin:

Attached a new version that creates a file with a 292 chars long path:
\\?\C:\Masm32\Abcdefghijklmnopqrstuvwxyz\Abcdefghijklmnopqrstuvwxyz\Abcdefghijklmnopqrstuvwxyz\Abcdefghijklmnopqrstuvwxyz\Abcdefghijklmnopqrstuvwxyz\Abcdefghijklmnopqrstuvwxyz\Abcdefghijklmnopqrstuvwxyz\Abcdefghijklmnopqrstuvwxyz\Abcdefghijklmnopqrstuvwxyz\Abcdefghijklmnopqrstuvwxyz

It does exist. The only problem is, at least on my Win7-64, Windows Explorer can't see the file :badgrin:

To find or edit the file or to delete it, rename the folders starting with C:\Masm32\Abcdefghijklmnopqrstuvwxyz to e.g. "a"

 :thumbsup: No problem to see files or to erase directory in Win10-64

Quote from: HSE on April 25, 2022, 07:33:44 AM
:thumbsup: No problem to see files or to erase directory in Win10-64

Great, so they fixed it. On Win7-64, ShellExecuteW can't find the file, too. But WriteFile works fine.

Quote from: HSE on April 25, 2022, 12:46:13 AM
I searched "crazy people using long file names".

I've reflected a moment whether to adapt my Open (https://www.jj2007.eu/MasmBasicQuickReference.htm#Mb1034), Kill, Print (https://www.jj2007.eu/MasmBasicQuickReference.htm#Mb1110) macros to the \\?\ system, but is it worth it? From 8.3 to 260 chars was a giant step (a factor 21), and I appreciate giving more descriptive names, but those who need more than MAX_PATH chars are indeed crazy people.

There are people that use deeply nested folders/subfolders and the lenght of the combined names sometimes exceed MAX_PATH.

Quote from: José Roca on April 26, 2022, 01:37:15 AM
There are people that use deeply nested folders/subfolders and the lenght of the combined names sometimes exceed MAX_PATH.

Such people should be locked in a psychiatric clinic, or be forced to work in Redmond :badgrin:

Just joking, José. I wonder if there is any risk in using the \\?\ scheme by default :rolleyes:

There is at least one limitation: you can't use it with relative paths.

https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd

What I do is to use always the W function and let the onus to the user. If he needs more than MAX_PATH, he must add the \\?\ prefix.

Quote from: José Roca on April 26, 2022, 02:42:25 AM
There is at least one limitation: you can't use it with relative paths.

Good point. Same for \Masm32\some.txt paths. So it's quite limited, not worth to change all file I/O macros.