Environment Variables and Path in Windows 10

Re:Environment Variables and Path in Windows 10 by frik on Monday October 26, 2015 @01:50AM (#10449782)

MAXPATH limit? WinAPI/dotNetFramework only supports 260 chars in the file path. And the UNC path (no limitation) isn't supported even in Explorer and most APIs. NodeJS and cross platform devs would beg to improve it (the guys who wrote the Win32 API and made their life too easy by copying too much of the Win16 API)!

26 drive letters? The NT kernel and NTFS/ReFS are very flexible, just update the WinAPI!

For some reason MS nowadays messes around with the UI (Win8/10 theming isn't that beautiful nor intuitive), the privacy settings, windows update, instead of keeping the Win9x/XP/Vista themes and improving the Win32 subsystem. Even WinRuntime API is a Win32 subsystem citizen. Either improve it or port WinRT to another subsystem. I wonder what Dave Cutler is working on at the moment (after VMS, WinNT kernel, XBox and Azure platform), or has he retired?

[ Parent | on HN ]

Re:Environment Variables and Path in Windows 10 by lewisl9029 on Monday October 26, 2015 @03:13AM (#10449949)

The 260 chars file path limit is a huge pain point for me personally, since I do most of my development in a Vagrant Ubuntu VM for the portability and superior tooling support.

I wish Microsoft would just put their support behind one of the popular open-source filesystems and release it as an alternative filesystem for Windows. This plus an officially supported NFS server and a POSIX compatible API would dramatically increase the viability of using Windows natively for development.

[ Parent | on HN ]

Re:Environment Variables and Path in Windows 10 by kevingadd on Monday October 26, 2015 @03:43AM (#10450002)

NTFS is honestly a great filesystem. Most of the stuff people dislike is due to the Win32 layer on top. For example:

NTFS is case sensitive.

NTFS does not have a 260ch path limit.

The slowness of stat() (or at least part of it) is due to the inefficient way Win32 does filesystem enumeration/status queries.

[ Parent | on HN ]

Re:Environment Variables and Path in Windows 10 by cm2187 on Monday October 26, 2015 @04:08AM (#10450056)

I am not sure case sensitivity is a good thing. Do you really want users to wonder what is the difference between toolxyz.exe and Toolxyz.exe? How do they even google that?

[ Parent | on HN ]

Re:Environment Variables and Path in Windows 10 by kuschku on Monday October 26, 2015 @05:27AM (#10450259)

It is good to have case sensitivity in the file system, and insensitivity in the UI.

[ Parent | on HN ]

Re:Environment Variables and Path in Windows 10 by Someone1234 on Monday October 26, 2015 @10:20AM (#10451596)

Why? The person above at least gave an example of why not, you're just simply stating the contrary without any explanation.

[ Parent | on HN ]

Re:Environment Variables and Path in Windows 10 by kuschku on Monday October 26, 2015 @01:11PM (#10452756)

The user wants to have the ability to use both cases, but to support legacy software, it might be necessary to support cases.

Also, upper/lowercasing is not defined the same in all languages. In turkish, i becomes uppercase Í.

[ Parent | on HN ]

Re:Environment Variables and Path in Windows 10 by frik on Monday October 26, 2015 @06:07AM (#10450404)

NT kernel and NTFS supports that, it can be activated.

[ Parent | on HN ]

Re:Environment Variables and Path in Windows 10 by be5invis on Monday October 26, 2015 @05:55AM (#10450364)

CoreFX has supported long paths as well as UNC paths recently. I'm just wondering when this improvement will be shipped.

[ Parent | on HN ]