16 ms·

What's completely inexplicable is why it took 23 years to do this. Consider this: (1) It's self-contained piece of UI code. It's not like this change will perm

by alister 11y ago

What's completely inexplicable is why it took 23 years to do this. Consider this: (1) It's self-contained piece of UI code. It's not like this change will permeate effects throughout the OS. (2) It's a few man days of work. Let's say that as a super-exaggerated-extreme estimate, it is still only a few months of work. (3) Nobody was dependent on the current behavior. (4) Everybody hated the current behavior. Programmers jumped through hoops like copying&pasting the strings into an editor, making a change, and pasting it back. (5) They had at least 23 years to fix it (since at least Windows 3.1). There are more plausible explanations about MH370 than there are about Microsoft's thinking here.

eropple 11y ago
> What's completely inexplicable is why it took 23 years to do this. I don't think it's inexplicable at all. "It wasn't considered to be an important enough change to be worth developer time by the people who owned that chunk of the codebase." Maybe it became important enough, or maybe somebody decided to make it their priority to push the change through, but random sharp edges show up in enterprise products, and persist, all the time.
- deleted 11y ago
  [deleted]
sien 11y ago
Perhaps it was because MS didn't want manual PATH alterations to be easy or they suspected too many people would have made their program only work if there was a manual alteration to it. The DOS prompt being terrible for 20 years might have similar justification. In 1995 MS would have many developers who would have just shifted their DOS apps to the command line if they could have gotten away with it. The OSX finder may have been made similar ideas in mind.
DonSchuler 11y ago
>> What's completely inexplicable is why it took 23 years to do this. That is an interesting statement. The reason why this little piece of work (similiar a resizable cmd window) hasn't been done before shows the fundamental differences between Linux and Windows in what the creators think it was made for. 99 % of the Windows users will never use the env var dialog. Microsoft gave the other 1 % (devs) Microsoft obviously a very low priority in the past. That has changed. While I like Windows 10 overall, I still wish it was not so chatty. I don't want to need to think about what kind of personal information my devices steal and how to protect myself. I don't like it from my Android phone and I don't like it from my laptop.
- bboreham 11y ago
  > resizable cmd window A couple of people have referred to this, but I've been resizing CMD windows for over a decade. Maybe you mean you couldn't increase the width by dragging, only via a dialog?
  - shrikant 11y ago
    When I try to maximise the the Cmd window, this[0] is the best that is achievable without custom apps. This is regardless of using either the horizontal resize handles or the Window Size properties. [0] http://i.imgur.com/GAbg5TR.png http://i.imgur.com/GAbg5TR.png Edited to add: This is Windows 7, 64-bit.
    - Natsu 11y ago
      Click the icon in the upper left, then go to Properties | Layout | Window Size. The size is measured in characters. It's rather inconvenient, though.
      - bboreham 11y ago
        Nitpick: first you need to increase the "Screen Buffer Size" width, then you can change the Window Size width too.
        shrikant 11y ago
        Huh, this worked -- wow, TIL, thanks! (You would still have to pry Cmder out of my cold dead Windows 7 hands though...)
- jmnicolas 11y ago
  "Microsoft gave the other 1 % (devs) Microsoft obviously a very low priority in the past." You know there's a lot of bad things to say about Microsoft (I still can't get other the "telemetry updates" and I'm seriously studying moving to Ubuntu 15.10) but saying MS gave developers a very low priority is probably the mots unjust criticism you could ever give them and tells me you probably never developed anything on Windows. I'd go even as far as to say that MS is the most developer friendly corp out there. The amount of effort they put in their tools, languages, frameworks, whatever is impressive. It's easy and it just works. Microsoft is to devs what Apple is to users.
hibikir 11y ago
I have no specific knowledge about how this was done, but it seems likely that the new way Windows development is organized led to a change like this happening. I've seen simple problems like this one that have taken forever to fix in big orgs where task prioritization was done at such a high level that anything that can't be called a bug, or considered very high impact, is ever even evaluated seriously as a candidate for change. When teams have more agency on what they change, then an enterprising developer that realizes how annoying the 'not quite a bug' is, and how easy it is to fix, can just be proactive, put it high in his team backlog, and get it done. At my current employer, we don't quite do old Google style 20% time, but we let developers ignore the sprint goals one day a week, as long as they are doing something that aims to help their team and their high level goals. How many people actually use that opportunity is a good measurement of how much teams believe in the planning that is being done: When a team's highlights for a given quarter all come from those unplanned features, that means that the direction the team was given made no sense, and we have to figure out why.
- meddlepal 11y ago
  Pretty much this. A lot of startup and small business devs here are used to just being able to change software at their discretion which is awesome and great, but it just doesn't work that way often at enterprise shops. Changes and requirements come through the product management pipeline via customer interaction. Anything that isn't delivering business value in the form of appeasing existing customers (bug fixes and niche feature requests) or attracting new business (new features or integrations) is basically put into a backlog and forgotten until someone gets frustrated enough to sacrifice a weekend adding/fixing the backlog item.
- mikekchar 11y ago
  We do a similar thing on my current team with respect to having a day to work on things that we think are important but aren't necessarily on the backlog. It seems to work reasonably well for this team, but there are some downsides. Explaining this well is really difficult, so I hope you don't mind me resorting to a metaphor. Imagine you are the chef of a restaurant and you work alone with your one waiter. You run the kitchen and they deal with the customers. Quite a lot of your work will be directly related to customer orders. You need to set the menu and go shopping and prep all the food. In addition to that, there are also some things that you need to do all the time like sharpen your knife, disinfect your cutting board, etc, etc. You could prep more food if you didn't have to do those things, but if you don't do them, then things will be quite a bit slower, so you have to budget some time for that. Still, these are things that you can do when customers aren't in the restaurant, so it's easy to budget. Once the customers come, you have to react to their orders. However, that's not all you have to do. You also have to clean your pans, wipe your board, keep your knife clean, shuffle food between your fridge, your board, your pans, etc. You also have to do extra prep work for things that you estimated wrong at the beginning of the day, or for special orders that come in. You could just pile up dirty pans as you go, but eventually you will have nothing to cook with. You have to find time to clean them as you go. You could take everything out of the fridge and leave it on your board, but then you won't have room to prepare the food and your food will spoil. Prioritising this work is not something that can be done in a meeting. The chef doesn't stop and chat with the waiter about whose food has the highest priority and negotiate, "Maybe wash that pan later, so that we can serve this dish first. We'll take the hit of unsatisfied customers who have to wait and watch you wash dishes for half an hour later." The judgement call is left up to the chef because it is the chef who knows better than anyone how to keep a constant throughput in order to keep the customers happy. It doesn't mean that the waiter has no say in the matter. If they perceive that something needs fixing now, they must say it, but the chef needs to figure out how to accomplish that while keeping the kitchen moving. In our software shops, we tend to listen to our stakeholders and given them literally what they are asking for. We often don't make the judgement call correctly of how to keep the "kitchen" moving. Our project managers often press the big red panic button and say, "Stop everything and just fry the steak. Don't wash dishes. Don't put the meat back in the firdge. Don't clean the board. Don't clean your knife. Don't prep for the next customer." -- with predictable results. Adding a 20% (or whatever) "budget" for allowing the developer to choose what to do is great, but the reality is that the developer needs to be able to choose what to do next 100% of the time -- and they need to have the ability and experience to choose correctly most of that 100%. This is the tricky part. If you do not have people like that on your staff, then you may be stuck trying to get by with planned work. It's going to be a crappy kitchen: food left out to waste, knives unsharped, dishes piling up in the sink. You might be fortunate enough to have someone on your team who will choose to wash they mountains of dishes in their "20% time", but the odds are fairly slim. What you really need is a chef who can direct traffic in the kitchen and who has the authority to make judgement calls 100% of the time. Note: If you ever get a chance to watch on open kitchen with a single chef who does everything, it is a fascinating experience. Only a small fraction of their time is spent actually cooking your food. Most of it is shuffling things around, cleaning and organizing. Yes, most professional kitchens have specialized positions, but I think this is metaphor is closer to the reality of programmers.
sunnyps 11y ago
Meh. I've been using Rapid Environment Editor[1] which is a free tool that allows editing environment variables on Windows and has a similar interface for editing PATH. I've always programmed primarily on UNIX like platforms but one thing that I've realized is that Windows provides a really powerful and stable API which makes tools like this possible. Microsoft likes to provide APIs and let developers build stuff like this. [1] http://www.rapidee.com/en/about http://www.rapidee.com/en/about
- batrat 11y ago
  People keep forgetting "there is an app' for everything" on widows.
  - tonyedgecombe 11y ago
    One of the things Microsoft has done over the years is filling all those little holes that needed an extra download, setting up a new Windows machine no longer involves downloading a hundred tiny utilities.
- majkinetor 11y ago
  Meh... you don't really need tool for that.
steven2012 11y ago
>(2) It's a few man days of work. Let's say that as a super-exaggerated-extreme estimate, it is still only a few months of work. This indicates to me that you've never worked in a software company like Microsoft. EVERYTHING that Microsoft does is under a huge amount of scrutiny, and any change to anything generally will piss someone off. So they are careful with every change and they have to be thorough. It's not just a few months worth of work. Sure, the development change of the UI could be done in a couple of days. But the design first has to be hammered out and agreed to. It has to agree with how the rest of the system would behave. Not to say that this dialog box was in agreement with the rest of the dialog boxes from XP to Windows 8, but if they're going to change it now, then whoever makes the change would need to make sure their version does. This would take man-weeks of meetings just to get right from the PM and designers, etc. But then there are QA changes that need to be done, just to test it, so add on a couple of weeks for that. It would presumably break all of their automated testing, and then new tests would have to be created. Ballpark figure just for that is 4 man-weeks of QA work. Then, are there any dependencies on the older version of the UI to other products? Not sure, probably not but it would have to be researched. What about documentation changes? Not only will the Windows documentation need to change, but then all other software that references adding environment variables need to change. And now, training videos will have to be changed. Don't forget that Microsoft has a bunch of training classes that they offer. Will enterprise customers be impacted by this? Not sure, but they would probably want to reach out to their most important ones to figure out what Now, take all the time estimates and then figure out how this compares to other bugs that have been lingering for years as well. Is the current functionality unusable, or is it just kind of sucky. If it's just kind of sucky but people can live with it, then time is probably better spent on other things. Do this about 6 times on the most widely used piece of software in the world, and you have yourself 20+ years. Should this dialog have been changed years ago? Yes, it sucks, and almost embarrassing. But it's still usable, so it has relatively low priority. This is how software decisions are generally made in enterprise software companies, especially those like Microsoft.
- Joeri 11y ago
  Windows 8 puts up a strong argument that at least some of the time features just get railroaded without all of that stuff. Anyway, i doubt google is as careful with android. If MS wants to reclaim the mobile space, which they had but lost due to being too slow, they need to move a lot faster, even if it sometimes breaks things. At the old rate of change, they'll end up losing the desktop to google as well.
frik 11y ago
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?
- lewisl9029 11y ago
  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.
  - kevingadd 11y ago
    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.
    - cm2187 11y ago
      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?
incepted 11y ago
> What's completely inexplicable is why it took 23 years to do this. At least, it did get revamped. Notepad and the Command window are still pretty much what they were in Windows 95.
- Dylan16807 11y ago
  Notepad's an edit control with a menu. You can't significantly upgrade it and still have it be Notepad.
  - ZainRiz 11y ago
    You ever try out Notepad2? It's basically Notepad but waaaaaay nicer
    - kozukumi 11y ago
      Or even better Notepad2-mod! http://xhmikosr.github.io/notepad2-mod/ http://xhmikosr.github.io/notepad2-mod/
- josteink 11y ago
  Not so. The command window is resizable like a real terminal emulator now. I was almost shocked when I discovered that one. I had honestly given up thinking it would never get fixed.
- deleted 11y ago
  [deleted]
jfoster 11y ago
Everyone was coping and Microsoft wasn't losing money.
anon4 11y ago
What's even more inexplicable is that you can't do the same on Linux. For all the developer-friendliness of the platform, nothing infuriates me more than having to edit my PATH/LD_LIBRARY_PATH/etc. by editing my .bashrc and then having to log out and back in again. Not to mention that programs you start from the GUI launcher don't source that file so if you need a program to start with one of them set, you actually need to edit .profile... wait no that doesn't work, I mean /etc/profile.d/99-my-path.conf... no actually it's /etc/environment... or is it /etc/profile... oh fuck this I'll just write a small shell script that sets PATH and launches what I want. Like... in Windows motherfucking NINETY-FIVE you could edit your PATH variable without having to restart, why do I have to log out and back in in 2015 for Linux to accept those changes. Why do I have to mess around with random scripts that may or may not be executed by one of the many steps launching my session. What is this madness.
- shiro 11y ago
  Isn't just starting a new shell suffice? (Usually I'm lazier and just say ". ~/.bashrc", knowing that it might not be idempotent but I don't care.)
  - anon4 11y ago
    But it doesn't take effect globally. The entire env-var system is stuck in the 60s when people would just re-launch their shell after making changes.
    - andor 11y ago
      It never changes globally. Your shell process sets the variables for itself, and all subprocesses started afterwards inherit them.
  - yokohummer7 11y ago
    If you place environment variables in ~/.bashrc, it would work. However, generally they are placed in ~/.profile which is read only when a login shell is launched. (And ~/.bashrc is not even read when you start a GUI session, anyways.) This is especially problematic in the GUI environment because in that case the login shell is the desktop environment itself. So you need to restart the whole environment (close all the windows, logout, and login) to load the new environment variables. Windows gets over this problem by letting the login shell (explorer.exe) reload the environment variables in place. So, if we are to do the same thing in Linux, we might have to patch bash, zsh, and GNOME etc. to understand the environment variable change events and reload itself appropriately. I'm not sure where to start, but I believe this is the one thing that Windows did right, so I want to see it happen.
cm2187 11y ago
Talking about a massively used piece of UI that Microsoft never updated in 20 years: the FX button near the formula bar in Excel. This is the only way to find a function with a description of what it does or to find what are the arguments of a function. It still shows a tiny non resizable window, with a list of thousands native functions and udf crammed in a tiny listbox, a search box that doesn't search anything, etc...
- ZenoArrow 11y ago
  F1 is your friend. Imagine you'll be able access this through the online help: https://support.office.com/en-us/article/Excel-functions-by-category-5f91f4e9-7b42-46d2-9bd1-63f26a86c0eb https://support.office.com/en-us/article/Excel-functions-by-...
  - cm2187 11y ago
    F1 is actually my worse enemy, too close to F2 for my fat fingers. The offline help is fine for Excel functions. But where I work, 90% of the functions used are coming from addins, and even though they also have a documentation somewhere, it can't be reached with F1. Documentation is necessary but hints should be inline/contextual, like intellisense in visual studio. I don't want to have to leave what I am doing just to figure out which is the next argument in a function. Excel could use a powerful autocomplete like intellisense that gives you basic documentation inside the auto-complete. But Office is the "sleeping beauty" of Microsoft. A bit of an old and hairy beauty though.
  - mistermann 11y ago
    Rarely does F1 work (like it used to) in most any MS app I've used in the last 5 years. I think they decided to just say fuck it and outsource that functionality to Google.
    - ZenoArrow 11y ago
      F1 works incredibly well in Visual Studio, especially if you're working with one of the flagship .NET languages. For example, highlight a core language element in your code, press F1 and you'll get specific help on it.
bane 11y ago
Putting on my conspiracy theory hat for a second, I bet this had to do with killing Java on the desktop or something. Nothing made it harder to get people to use Java apps then telling them to download and install a runtime and then add some path things to some mercurial and hard to use part of the OS. Just about the only time I've ever had to interact with the path dialog on a windows system its been for the purpose of setting up java. And sun/oracle hasn't done any favors for themselves either in making the setup process better.
- mistermann 11y ago
  > And sun/oracle hasn't done any favors for themselves either in making the setup process better. Massive understatement! :) As well, in my limited experience, vendors who write something java-based absolutely can't be bothered to write a help document on how to configure java to run their app despite hundreds of people posting in forums asking for help...."not our problem, you should know how to do that" seems to be the sentiment.
devit 11y ago
It's rarely used, and only by experienced users. Also, 3rd party software can provide that functionality
anonymfus 11y ago
Probably because PATH variable was considered deprecated. You are supposed to put paths to your executables in the registry: https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121#app_exe https://msdn.microsoft.com/en-us/library/windows/desktop/ee8... > We recommend registering your application in the App Paths registry subkey. Doing so avoids the need for applications to modify the system PATH environment variable. http://blogs.msdn.com/b/oldnewthing/archive/2011/07/25/10189298.aspx http://blogs.msdn.com/b/oldnewthing/archive/2011/07/25/10189... > On top of the difficulty of adding more directories to the PATH, there was the recognition that this was another case of using a global setting to solve a local problem. It seemed wasteful to add a directory to the path just so you could find one file. Each additional directory on the path slowed down path sarching operations, even the ones unrelated to locating that one program. > Enter App Paths. The idea here is that instead of adding your application directory to the path, you just create an entry under the App Paths key saying, "If somebody is looking to execute contoso.exe, I put it over here." Instead of adding an entire directory to the path, you just add a single file, and it's used only for application execution purposes, so it doesn't slow down other path search operations like loading DLLs.
- shthed 11y ago
  Would be nice if cmd and powershell also looked in App Paths allowing to be an actual replacement for %PATH% (without having to do "start app.exe")

by alister 11y ago

eropple 11y ago

> What's completely inexplicable is why it took 23 years to do this. I don't think it's inexplicable at all. "It wasn't considered to be an important enough change to be worth developer time by the people who owned that chunk of the codebase." Maybe it became important enough, or maybe somebody decided to make it their priority to push the change through, but random sharp edges show up in enterprise products, and persist, all the time.

deleted 11y ago
[deleted]

sien 11y ago

Perhaps it was because MS didn't want manual PATH alterations to be easy or they suspected too many people would have made their program only work if there was a manual alteration to it. The DOS prompt being terrible for 20 years might have similar justification. In 1995 MS would have many developers who would have just shifted their DOS apps to the command line if they could have gotten away with it. The OSX finder may have been made similar ideas in mind.

DonSchuler 11y ago

>> What's completely inexplicable is why it took 23 years to do this. That is an interesting statement. The reason why this little piece of work (similiar a resizable cmd window) hasn't been done before shows the fundamental differences between Linux and Windows in what the creators think it was made for. 99 % of the Windows users will never use the env var dialog. Microsoft gave the other 1 % (devs) Microsoft obviously a very low priority in the past. That has changed. While I like Windows 10 overall, I still wish it was not so chatty. I don't want to need to think about what kind of personal information my devices steal and how to protect myself. I don't like it from my Android phone and I don't like it from my laptop.

bboreham 11y ago
> resizable cmd window A couple of people have referred to this, but I've been resizing CMD windows for over a decade. Maybe you mean you couldn't increase the width by dragging, only via a dialog?
- shrikant 11y ago
  When I try to maximise the the Cmd window, this[0] is the best that is achievable without custom apps. This is regardless of using either the horizontal resize handles or the Window Size properties. [0] http://i.imgur.com/GAbg5TR.png http://i.imgur.com/GAbg5TR.png Edited to add: This is Windows 7, 64-bit.
  - Natsu 11y ago
    Click the icon in the upper left, then go to Properties | Layout | Window Size. The size is measured in characters. It's rather inconvenient, though.
    - bboreham 11y ago
      Nitpick: first you need to increase the "Screen Buffer Size" width, then you can change the Window Size width too.
      - shrikant 11y ago
        Huh, this worked -- wow, TIL, thanks! (You would still have to pry Cmder out of my cold dead Windows 7 hands though...)
jmnicolas 11y ago
"Microsoft gave the other 1 % (devs) Microsoft obviously a very low priority in the past." You know there's a lot of bad things to say about Microsoft (I still can't get other the "telemetry updates" and I'm seriously studying moving to Ubuntu 15.10) but saying MS gave developers a very low priority is probably the mots unjust criticism you could ever give them and tells me you probably never developed anything on Windows. I'd go even as far as to say that MS is the most developer friendly corp out there. The amount of effort they put in their tools, languages, frameworks, whatever is impressive. It's easy and it just works. Microsoft is to devs what Apple is to users.

hibikir 11y ago

I have no specific knowledge about how this was done, but it seems likely that the new way Windows development is organized led to a change like this happening. I've seen simple problems like this one that have taken forever to fix in big orgs where task prioritization was done at such a high level that anything that can't be called a bug, or considered very high impact, is ever even evaluated seriously as a candidate for change. When teams have more agency on what they change, then an enterprising developer that realizes how annoying the 'not quite a bug' is, and how easy it is to fix, can just be proactive, put it high in his team backlog, and get it done. At my current employer, we don't quite do old Google style 20% time, but we let developers ignore the sprint goals one day a week, as long as they are doing something that aims to help their team and their high level goals. How many people actually use that opportunity is a good measurement of how much teams believe in the planning that is being done: When a team's highlights for a given quarter all come from those unplanned features, that means that the direction the team was given made no sense, and we have to figure out why.

meddlepal 11y ago
Pretty much this. A lot of startup and small business devs here are used to just being able to change software at their discretion which is awesome and great, but it just doesn't work that way often at enterprise shops. Changes and requirements come through the product management pipeline via customer interaction. Anything that isn't delivering business value in the form of appeasing existing customers (bug fixes and niche feature requests) or attracting new business (new features or integrations) is basically put into a backlog and forgotten until someone gets frustrated enough to sacrifice a weekend adding/fixing the backlog item.
mikekchar 11y ago
We do a similar thing on my current team with respect to having a day to work on things that we think are important but aren't necessarily on the backlog. It seems to work reasonably well for this team, but there are some downsides. Explaining this well is really difficult, so I hope you don't mind me resorting to a metaphor. Imagine you are the chef of a restaurant and you work alone with your one waiter. You run the kitchen and they deal with the customers. Quite a lot of your work will be directly related to customer orders. You need to set the menu and go shopping and prep all the food. In addition to that, there are also some things that you need to do all the time like sharpen your knife, disinfect your cutting board, etc, etc. You could prep more food if you didn't have to do those things, but if you don't do them, then things will be quite a bit slower, so you have to budget some time for that. Still, these are things that you can do when customers aren't in the restaurant, so it's easy to budget. Once the customers come, you have to react to their orders. However, that's not all you have to do. You also have to clean your pans, wipe your board, keep your knife clean, shuffle food between your fridge, your board, your pans, etc. You also have to do extra prep work for things that you estimated wrong at the beginning of the day, or for special orders that come in. You could just pile up dirty pans as you go, but eventually you will have nothing to cook with. You have to find time to clean them as you go. You could take everything out of the fridge and leave it on your board, but then you won't have room to prepare the food and your food will spoil. Prioritising this work is not something that can be done in a meeting. The chef doesn't stop and chat with the waiter about whose food has the highest priority and negotiate, "Maybe wash that pan later, so that we can serve this dish first. We'll take the hit of unsatisfied customers who have to wait and watch you wash dishes for half an hour later." The judgement call is left up to the chef because it is the chef who knows better than anyone how to keep a constant throughput in order to keep the customers happy. It doesn't mean that the waiter has no say in the matter. If they perceive that something needs fixing now, they must say it, but the chef needs to figure out how to accomplish that while keeping the kitchen moving. In our software shops, we tend to listen to our stakeholders and given them literally what they are asking for. We often don't make the judgement call correctly of how to keep the "kitchen" moving. Our project managers often press the big red panic button and say, "Stop everything and just fry the steak. Don't wash dishes. Don't put the meat back in the firdge. Don't clean the board. Don't clean your knife. Don't prep for the next customer." -- with predictable results. Adding a 20% (or whatever) "budget" for allowing the developer to choose what to do is great, but the reality is that the developer needs to be able to choose what to do next 100% of the time -- and they need to have the ability and experience to choose correctly most of that 100%. This is the tricky part. If you do not have people like that on your staff, then you may be stuck trying to get by with planned work. It's going to be a crappy kitchen: food left out to waste, knives unsharped, dishes piling up in the sink. You might be fortunate enough to have someone on your team who will choose to wash they mountains of dishes in their "20% time", but the odds are fairly slim. What you really need is a chef who can direct traffic in the kitchen and who has the authority to make judgement calls 100% of the time. Note: If you ever get a chance to watch on open kitchen with a single chef who does everything, it is a fascinating experience. Only a small fraction of their time is spent actually cooking your food. Most of it is shuffling things around, cleaning and organizing. Yes, most professional kitchens have specialized positions, but I think this is metaphor is closer to the reality of programmers.

sunnyps 11y ago

Meh. I've been using Rapid Environment Editor[1] which is a free tool that allows editing environment variables on Windows and has a similar interface for editing PATH. I've always programmed primarily on UNIX like platforms but one thing that I've realized is that Windows provides a really powerful and stable API which makes tools like this possible. Microsoft likes to provide APIs and let developers build stuff like this. [1] http://www.rapidee.com/en/about http://www.rapidee.com/en/about

batrat 11y ago
People keep forgetting "there is an app' for everything" on widows.
- tonyedgecombe 11y ago
  One of the things Microsoft has done over the years is filling all those little holes that needed an extra download, setting up a new Windows machine no longer involves downloading a hundred tiny utilities.
majkinetor 11y ago
Meh... you don't really need tool for that.

steven2012 11y ago

>(2) It's a few man days of work. Let's say that as a super-exaggerated-extreme estimate, it is still only a few months of work. This indicates to me that you've never worked in a software company like Microsoft. EVERYTHING that Microsoft does is under a huge amount of scrutiny, and any change to anything generally will piss someone off. So they are careful with every change and they have to be thorough. It's not just a few months worth of work. Sure, the development change of the UI could be done in a couple of days. But the design first has to be hammered out and agreed to. It has to agree with how the rest of the system would behave. Not to say that this dialog box was in agreement with the rest of the dialog boxes from XP to Windows 8, but if they're going to change it now, then whoever makes the change would need to make sure their version does. This would take man-weeks of meetings just to get right from the PM and designers, etc. But then there are QA changes that need to be done, just to test it, so add on a couple of weeks for that. It would presumably break all of their automated testing, and then new tests would have to be created. Ballpark figure just for that is 4 man-weeks of QA work. Then, are there any dependencies on the older version of the UI to other products? Not sure, probably not but it would have to be researched. What about documentation changes? Not only will the Windows documentation need to change, but then all other software that references adding environment variables need to change. And now, training videos will have to be changed. Don't forget that Microsoft has a bunch of training classes that they offer. Will enterprise customers be impacted by this? Not sure, but they would probably want to reach out to their most important ones to figure out what Now, take all the time estimates and then figure out how this compares to other bugs that have been lingering for years as well. Is the current functionality unusable, or is it just kind of sucky. If it's just kind of sucky but people can live with it, then time is probably better spent on other things. Do this about 6 times on the most widely used piece of software in the world, and you have yourself 20+ years. Should this dialog have been changed years ago? Yes, it sucks, and almost embarrassing. But it's still usable, so it has relatively low priority. This is how software decisions are generally made in enterprise software companies, especially those like Microsoft.

Joeri 11y ago
Windows 8 puts up a strong argument that at least some of the time features just get railroaded without all of that stuff. Anyway, i doubt google is as careful with android. If MS wants to reclaim the mobile space, which they had but lost due to being too slow, they need to move a lot faster, even if it sometimes breaks things. At the old rate of change, they'll end up losing the desktop to google as well.

frik 11y ago

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?

lewisl9029 11y ago
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.
- kevingadd 11y ago
  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.
  - cm2187 11y ago
    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?

incepted 11y ago

> What's completely inexplicable is why it took 23 years to do this. At least, it did get revamped. Notepad and the Command window are still pretty much what they were in Windows 95.

Dylan16807 11y ago
Notepad's an edit control with a menu. You can't significantly upgrade it and still have it be Notepad.
- ZainRiz 11y ago
  You ever try out Notepad2? It's basically Notepad but waaaaaay nicer
  - kozukumi 11y ago
    Or even better Notepad2-mod! http://xhmikosr.github.io/notepad2-mod/ http://xhmikosr.github.io/notepad2-mod/
josteink 11y ago
Not so. The command window is resizable like a real terminal emulator now. I was almost shocked when I discovered that one. I had honestly given up thinking it would never get fixed.
deleted 11y ago
[deleted]

jfoster 11y ago

Everyone was coping and Microsoft wasn't losing money.

anon4 11y ago

What's even more inexplicable is that you can't do the same on Linux. For all the developer-friendliness of the platform, nothing infuriates me more than having to edit my PATH/LD_LIBRARY_PATH/etc. by editing my .bashrc and then having to log out and back in again. Not to mention that programs you start from the GUI launcher don't source that file so if you need a program to start with one of them set, you actually need to edit .profile... wait no that doesn't work, I mean /etc/profile.d/99-my-path.conf... no actually it's /etc/environment... or is it /etc/profile... oh fuck this I'll just write a small shell script that sets PATH and launches what I want. Like... in Windows motherfucking NINETY-FIVE you could edit your PATH variable without having to restart, why do I have to log out and back in in 2015 for Linux to accept those changes. Why do I have to mess around with random scripts that may or may not be executed by one of the many steps launching my session. What is this madness.

shiro 11y ago
Isn't just starting a new shell suffice? (Usually I'm lazier and just say ". ~/.bashrc", knowing that it might not be idempotent but I don't care.)
- anon4 11y ago
  But it doesn't take effect globally. The entire env-var system is stuck in the 60s when people would just re-launch their shell after making changes.
  - andor 11y ago
    It never changes globally. Your shell process sets the variables for itself, and all subprocesses started afterwards inherit them.
- yokohummer7 11y ago
  If you place environment variables in ~/.bashrc, it would work. However, generally they are placed in ~/.profile which is read only when a login shell is launched. (And ~/.bashrc is not even read when you start a GUI session, anyways.) This is especially problematic in the GUI environment because in that case the login shell is the desktop environment itself. So you need to restart the whole environment (close all the windows, logout, and login) to load the new environment variables. Windows gets over this problem by letting the login shell (explorer.exe) reload the environment variables in place. So, if we are to do the same thing in Linux, we might have to patch bash, zsh, and GNOME etc. to understand the environment variable change events and reload itself appropriately. I'm not sure where to start, but I believe this is the one thing that Windows did right, so I want to see it happen.

cm2187 11y ago

Talking about a massively used piece of UI that Microsoft never updated in 20 years: the FX button near the formula bar in Excel. This is the only way to find a function with a description of what it does or to find what are the arguments of a function. It still shows a tiny non resizable window, with a list of thousands native functions and udf crammed in a tiny listbox, a search box that doesn't search anything, etc...

ZenoArrow 11y ago
F1 is your friend. Imagine you'll be able access this through the online help: https://support.office.com/en-us/article/Excel-functions-by-category-5f91f4e9-7b42-46d2-9bd1-63f26a86c0eb https://support.office.com/en-us/article/Excel-functions-by-...
- cm2187 11y ago
  F1 is actually my worse enemy, too close to F2 for my fat fingers. The offline help is fine for Excel functions. But where I work, 90% of the functions used are coming from addins, and even though they also have a documentation somewhere, it can't be reached with F1. Documentation is necessary but hints should be inline/contextual, like intellisense in visual studio. I don't want to have to leave what I am doing just to figure out which is the next argument in a function. Excel could use a powerful autocomplete like intellisense that gives you basic documentation inside the auto-complete. But Office is the "sleeping beauty" of Microsoft. A bit of an old and hairy beauty though.
- mistermann 11y ago
  Rarely does F1 work (like it used to) in most any MS app I've used in the last 5 years. I think they decided to just say fuck it and outsource that functionality to Google.
  - ZenoArrow 11y ago
    F1 works incredibly well in Visual Studio, especially if you're working with one of the flagship .NET languages. For example, highlight a core language element in your code, press F1 and you'll get specific help on it.

bane 11y ago

Putting on my conspiracy theory hat for a second, I bet this had to do with killing Java on the desktop or something. Nothing made it harder to get people to use Java apps then telling them to download and install a runtime and then add some path things to some mercurial and hard to use part of the OS. Just about the only time I've ever had to interact with the path dialog on a windows system its been for the purpose of setting up java. And sun/oracle hasn't done any favors for themselves either in making the setup process better.

mistermann 11y ago
> And sun/oracle hasn't done any favors for themselves either in making the setup process better. Massive understatement! :) As well, in my limited experience, vendors who write something java-based absolutely can't be bothered to write a help document on how to configure java to run their app despite hundreds of people posting in forums asking for help...."not our problem, you should know how to do that" seems to be the sentiment.

devit 11y ago

It's rarely used, and only by experienced users. Also, 3rd party software can provide that functionality

anonymfus 11y ago

Probably because PATH variable was considered deprecated. You are supposed to put paths to your executables in the registry: https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121#app_exe https://msdn.microsoft.com/en-us/library/windows/desktop/ee8... > We recommend registering your application in the App Paths registry subkey. Doing so avoids the need for applications to modify the system PATH environment variable. http://blogs.msdn.com/b/oldnewthing/archive/2011/07/25/10189298.aspx http://blogs.msdn.com/b/oldnewthing/archive/2011/07/25/10189... > On top of the difficulty of adding more directories to the PATH, there was the recognition that this was another case of using a global setting to solve a local problem. It seemed wasteful to add a directory to the path just so you could find one file. Each additional directory on the path slowed down path sarching operations, even the ones unrelated to locating that one program. > Enter App Paths. The idea here is that instead of adding your application directory to the path, you just create an entry under the App Paths key saying, "If somebody is looking to execute contoso.exe, I put it over here." Instead of adding an entire directory to the path, you just add a single file, and it's used only for application execution purposes, so it doesn't slow down other path search operations like loading DLLs.

shthed 11y ago
Would be nice if cmd and powershell also looked in App Paths allowing to be an actual replacement for %PATH% (without having to do "start app.exe")