Jumping to an app starting with a specific letter.
Does that mean you can no longer find an app by typing its name?
Microsoft has released its bestest new build of Windows 10 as part of its Windows Insider preview programme, with general manager Gabe Aul boldly stating: “we don’t have any significant known issues for this build.” Since the company has promised to release Windows 10 on July 29, you would expect it to be pretty much sorted at …
This is almost certainly an extra thing for touch users and NOT the removal of search-by-typing
Well, let's not get ahead of ourselves, shall we? MS still has several weeks with which to find and eliminate useful features for desktop users.
"Microsoft is still tweaking the Start menu and in this build you can tap or click a letter to get an alphabet menu, so you can jump to apps beginning with a specific letter. It does not quite work, though: I tapped P in search of Paint, but it does not come up, since Paint is under Windows Accessories. I should have tapped W."
Rubbish - on Windows 10 build 10158, tap the Windows key, hit P, Paint is first app listed....Tested OK on 3 different installs of 10158...
You need to use an upper-case P. If you don't you'll get this:
Play key sounds as I type
Power and Sleep Settings
Pirate Bay (Yes it really is at the top of the list! No I have never visited the pirate bay, this is simply the top web search for the letter p)
Paint is not there at all. Useless.
Oh, dear me. I read that as "Microsoft Stool". Maybe acceptable on the docks.
And please don't forget that you can always fall back to their 8.3 name for your stupidly long filenames. If you have long paths, don't forget SUBST or whatever that POSIX command was.
I predict that people will stop storing information in those old containers called "files" and just make the full pathname contain everything needed.
elDog proposed: "I predict that people will stop storing information in those old containers called 'files' and just make the full pathname contain everything needed."
The limit is not Explorer's. It is Win32's. It was promised (back in 1991 or thenabouts) that 260 characters would be enough for any file. This was over three lines of typing in a command prompt back then and the designers clearly asked themselves what would be a stupidly long name and then doubled it.
(There is an API work-around and so Microsoft could have written Explorer to be able to handle longer names. This would let you quietly create files that your other programs couldn't handle properly, perhaps causing a buffer overrun or a truncation-related security flaw, depending on quite how they couldn't handle it properly. Microsoft presumably thought that the ability to dig yourself deeper into trouble wasn't a great feature. I'm inclined to agree.)
Of course, some people like to put all the meta-data for a file into the parent's (and n-fold grandparent's) directory name. This is typically a crap idea because you lose it the moment you move the file somewhere else, but people do it anyway. Such people can quite easily blow the 260-character limit. The view of an operating system designer is that these people are twats and they can sod off.
I would note in passing that *any* fixed limit will eventually upset some "test suite" and that having no limit at all will eventually produce an eco-system where twats store file contents in the filename and the files themselves are empty -- just because they can.
Unix has similar hard limits, but they are generally larger and less documented. The consequences are that (firstly) Windows gets the schtick and (more importantly) the equivalent failure in Unix-land depends on what application you are using. That's not actually better.
The limit is not Explorer's. It is Win32's.
Spot on correct. Note that the underlying filesystems aren't a bottleneck, with file/folder names of 255 characters and complete path names of up to 32760. The culprit is the MAX_PATH define in Win32, stuck forever at 260 characters since nearly forever.
It's also important to note that programs not dependent on Win32 calls (like Robocopy or FAR Manager) will happily handle the much longer file paths.
"The limit is not Explorer's. It is Win32's."
No it's not . The limit is 32767 characters IF you use the Unicode version of the API and IF you prefix the path with "\\?\" , part of the UNC scheme. Unicode is Microsoft's version of UTF16 and present since Windows 2000 in Win32 . That was 16 years ago.
The MAX_PATH limit is only for apps stil using ASCII and for Windows Explorer. I guess Microsoft hoped that retards , uhm, programmers , will switch to Unicode in their apps and then the will upgrade Explorer as well, but it still hasn't happened.
The limit in Explorer is kept for COMPATIBILITY.
NTFS as a file system doesn't have such a limit. It's also case discriminant if requested.
Also, anyone programmed on Linux ? Never encountered the PATH_MAX limit ?
I suggest you read the documentation. The limit most certainly *is* Win32's and the "\\?\" prefixing is documented as a way to skip Win32's validation and pass the filename blindly to the lower level. It sounds like you've failed to distinguish between the Win32 personality and the NT OS layer. MAX_PATH continues to apply to the Unicode APIs if you don't use the prefix and I don't think I've ever met and end-user who did.
You are somewhat right.. MAX_PATH is enforced by functions but only if you want them to.
The reason for all this is compatibility with FAT fs I think. Once they give that up it should be easy to just make that the default behaviour
Good point, but I think you should pull the figure down by a fairly large factor to reflect the fact that most of us would find a path like
a bit hard to recognise. I suspect working out which combinations of 256 characters that are significant to humans might be a hard problem though, and langage dependent.
Yeah worked for a company that insisted their code tree had 1 letter names, so when we were trying to find a source file you had to go looking for
I spent more time looking for the file than working on it.
"That path length is substantially more than required to give a seperate folder to every atom in the universe..."
What!? Just one...? Not very far thinking, that.
edit:- What!? Just one universe...? Not very far thinking, that either!.
"...give a seperate folder to every atom in the universe..."
By the time one has organized a large organization and structured the projects and structured the folders and subfolders within the project and start pasting in files with real world filenames, BAM! Too long.
One trick is to have short-cuts back-up the tree structure. Deep down in the tips of the branches, a short-cut back up to near the top of the project folder, e.g. ...Project\Shorty\...
It's a trick that works fairly well.
Oh we get caught with that all the time.. and it gets better.
File server - folder shared out half way down the tree, users pour files into it.
System can't then back the files up, as it's starting at the top. User: "hey, restore my file please!".....
Does Outlook still have the endearing feature that you cannot attach a file to a message if the filename is longer than (ISTR) 110 characters? This was in all versions up to the last one before Office 2003 - I have not had much exposure to Outlook/Exchange since then.
It took me quite a while to work out why users were unable to attach certain documents. Experimentation and numerous tries eventually revealed the limit (the company I worked at then had a file structure of the order Mapped Drive:\LongClientName\LongEventName\Year\Some\More\Long\Identifiers\LongFileName.xxx, some of which had to be truncated to fit within the 256 character limit.
My workaround was to ask them to copy the file to their local My Documents folder, attach and send and then to delete the file afterwards (this obviously led to a number of other problems, chief of which was people that moved rather than copied files and then deleting same, or a plethora of other combinations of exciting things that one can do to files (like moving entire directories and dropping it in some unsuspecting directory halfway through the procedure, when they realised that they were doing something wrong and then let go of the left mouse button)).
I've been working with Windows 10 since the start of the preview program, and it's come a long way. One thing that really does bother me is the rapid shifts in user interface from one build to the next. Every single build, it seems they try to introduce more and more phone-like qualities. We desktop users really want the ability to control user themes, for example. Phone users are stuck with whatever Android skin their carrier chooses to implement, or iOS, and it's a take it or leave it prospect. Desktop and laptop PC users are a little different -- most still expect some level of control over the UI, and a lot of that was taken away in the later builds of Windows 10.
The good thing is that the OS under the hood really seems to be shaping up. I just don't understand why Microsoft doesn't seem to want to support themes, especially since they are expecting a bunch of Windows 7 users to come over to Windows 10. Why not make the transition easy? What if someone actually likes the flat Windows 8 UI? Oh yes, I forgot -- marketing and brand identity.
I think it translates as "your microphone does not have the required NSA invisible intercept facility/hardware lock override".
While likely true, that doesn't directly answer whether Cortana should be designed for microphones instead of the other way around.
Press Windows key, type "p", and Paint is the first entry in the list. The way it's been since Windows 7.
If you've got to go to town on Windows 10 (and I don't blame you), why not mention the half-baked Continuum feature; the fact that nothing actually works quite right; that settings are STILL spread across about six different apps / programs; the lack of Intel display drivers; Cortana being cranky; the half-finished theming etc etc etc.
Biting the hand that feeds IT © 1998–2019