Microsoft's Inconsistencies In Windows
-
Hi all Is it just me or are other people also extremely irritated by Microsoft's inconsistencies in Windows? It’s as if there’s one set of rules that “third party” Windows developers must play by and another set that Microsoft's own developers get to play by. And even with .NET, it’s not getting better but worse. Let me give a couple of examples. Where an application stores its data With every new version of Windows there’s a new place where an app is supposed to store its data. I would prefer my app to store its data in the folder where it’s installed, but this is frowned upon. You’re supposed to use “C:\Documents and Settings\All Users\Application Data” or similar. But if you look at SQL Server, you see that it stores its data in “C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data” or similar. Is SQL Server just special? Why can’t my app be special? Window title bars I can’t even remember all the non-standard title bars I’ve seen from Microsoft apps. A recent example is the kind used in Office 2007 (one Windows utility I read about, which among other things minimizes groups of windows for you, apologized for not being able to do the same for Office 2007 apps due to their custom title bars). But there are also other apps that sport Windows Vista-style title bars on Windows XP. Please. I can’t find the “funky title bar” control anywhere in Visual Studio, the premier environment for developing Windows apps. Yes, I know I could probably hack it using low level Windows APIs, but I’d rather stick needles in my eyes than waste my time on such rubbish. Yet Microsoft's own developers seem to have license and time for such “creativity”. Window main menus As with window title bars, there are many incantations. I checked out Visual Studio 2010 Express the other day and guess what - the menu strip for File, Edit, View, etc. looks completely different again. Have we not solved the “menu” problem before? Common controls The dropdown list with icons and indentation we’ve seen in Windows Explorer for the last decade? I would like one too please. As a common control, like the ListView and TreeView. If it’s not too much trouble. I had a semi-working one in COM (mscomctl.dll); now I would like a proper working one in .NET. Also, the way an OpenFileDialog can these days be used to select folders and not just files? I can’t get mine to do the same, even if I try to use the FileOk event. It just wants to open files. There are many more examples, I’m sure. Maybe you guys ca
-
Hi all Is it just me or are other people also extremely irritated by Microsoft's inconsistencies in Windows? It’s as if there’s one set of rules that “third party” Windows developers must play by and another set that Microsoft's own developers get to play by. And even with .NET, it’s not getting better but worse. Let me give a couple of examples. Where an application stores its data With every new version of Windows there’s a new place where an app is supposed to store its data. I would prefer my app to store its data in the folder where it’s installed, but this is frowned upon. You’re supposed to use “C:\Documents and Settings\All Users\Application Data” or similar. But if you look at SQL Server, you see that it stores its data in “C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data” or similar. Is SQL Server just special? Why can’t my app be special? Window title bars I can’t even remember all the non-standard title bars I’ve seen from Microsoft apps. A recent example is the kind used in Office 2007 (one Windows utility I read about, which among other things minimizes groups of windows for you, apologized for not being able to do the same for Office 2007 apps due to their custom title bars). But there are also other apps that sport Windows Vista-style title bars on Windows XP. Please. I can’t find the “funky title bar” control anywhere in Visual Studio, the premier environment for developing Windows apps. Yes, I know I could probably hack it using low level Windows APIs, but I’d rather stick needles in my eyes than waste my time on such rubbish. Yet Microsoft's own developers seem to have license and time for such “creativity”. Window main menus As with window title bars, there are many incantations. I checked out Visual Studio 2010 Express the other day and guess what - the menu strip for File, Edit, View, etc. looks completely different again. Have we not solved the “menu” problem before? Common controls The dropdown list with icons and indentation we’ve seen in Windows Explorer for the last decade? I would like one too please. As a common control, like the ListView and TreeView. If it’s not too much trouble. I had a semi-working one in COM (mscomctl.dll); now I would like a proper working one in .NET. Also, the way an OpenFileDialog can these days be used to select folders and not just files? I can’t get mine to do the same, even if I try to use the FileOk event. It just wants to open files. There are many more examples, I’m sure. Maybe you guys ca
-
Hi all Is it just me or are other people also extremely irritated by Microsoft's inconsistencies in Windows? It’s as if there’s one set of rules that “third party” Windows developers must play by and another set that Microsoft's own developers get to play by. And even with .NET, it’s not getting better but worse. Let me give a couple of examples. Where an application stores its data With every new version of Windows there’s a new place where an app is supposed to store its data. I would prefer my app to store its data in the folder where it’s installed, but this is frowned upon. You’re supposed to use “C:\Documents and Settings\All Users\Application Data” or similar. But if you look at SQL Server, you see that it stores its data in “C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data” or similar. Is SQL Server just special? Why can’t my app be special? Window title bars I can’t even remember all the non-standard title bars I’ve seen from Microsoft apps. A recent example is the kind used in Office 2007 (one Windows utility I read about, which among other things minimizes groups of windows for you, apologized for not being able to do the same for Office 2007 apps due to their custom title bars). But there are also other apps that sport Windows Vista-style title bars on Windows XP. Please. I can’t find the “funky title bar” control anywhere in Visual Studio, the premier environment for developing Windows apps. Yes, I know I could probably hack it using low level Windows APIs, but I’d rather stick needles in my eyes than waste my time on such rubbish. Yet Microsoft's own developers seem to have license and time for such “creativity”. Window main menus As with window title bars, there are many incantations. I checked out Visual Studio 2010 Express the other day and guess what - the menu strip for File, Edit, View, etc. looks completely different again. Have we not solved the “menu” problem before? Common controls The dropdown list with icons and indentation we’ve seen in Windows Explorer for the last decade? I would like one too please. As a common control, like the ListView and TreeView. If it’s not too much trouble. I had a semi-working one in COM (mscomctl.dll); now I would like a proper working one in .NET. Also, the way an OpenFileDialog can these days be used to select folders and not just files? I can’t get mine to do the same, even if I try to use the FileOk event. It just wants to open files. There are many more examples, I’m sure. Maybe you guys ca
Roelof De Villiers wrote:
You’re supposed to use “C:\Documents and Settings\All Users\Application Data” or similar. But if you look at SQL Server, you see that it stores its data in “C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data”
This is a crazy point to make. The issue is that you're supposed to store user data in All Users\Application Data or [user]\Application Data, SQL Server is a service, and as such has no user, and no user data - just the data used for its databases. This is ignoring the fact that where SQL Server stores this data is completely configurable. Your point also completely ignores the fact that .NET provides a cross-version way of getting the path for this (and many other similar) folders with
GetSpecialFoldermodified on Monday, December 13, 2010 9:26 AM
-
Roelof De Villiers wrote:
You’re supposed to use “C:\Documents and Settings\All Users\Application Data” or similar. But if you look at SQL Server, you see that it stores its data in “C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data”
This is a crazy point to make. The issue is that you're supposed to store user data in All Users\Application Data or [user]\Application Data, SQL Server is a service, and as such has no user, and no user data - just the data used for its databases. This is ignoring the fact that where SQL Server stores this data is completely configurable. Your point also completely ignores the fact that .NET provides a cross-version way of getting the path for this (and many other similar) folders with
GetSpecialFoldermodified on Monday, December 13, 2010 9:26 AM
Thanks for the input, but I don't think it's crazy.
J4amieC wrote:
SQL Server is a service, and as such has no user, and no user data
Of course it has users. The data stored in the databases are not for the sake of SQL Server and it doesn't belong to SQL Server. It's for the sake of users and it belongs to users. You can argue as to who those users are - the individual database users running queries or the administrator running the server for those database users - but there are users.
J4amieC wrote:
This is ignoring the fact that where SQL Server stores this data is completely configurable.
Yes, I am ignoring this fact too, because the location I mentioned is the DEFAULT, so they're not practicing what they're preaching, BY DEFAULT. Even if I concede that SQL Server is special because it's a service, it's not like Microsoft is saying "Well, okay, if you're talking about a service then I guess it's okay for you to put it there". The point is, they don't want you to save your data under Program Files, service or not, but they do it themselves by default in SQL Server. I know I sound anal but I'm trying to rant here. ;P
-
Thanks for the input, but I don't think it's crazy.
J4amieC wrote:
SQL Server is a service, and as such has no user, and no user data
Of course it has users. The data stored in the databases are not for the sake of SQL Server and it doesn't belong to SQL Server. It's for the sake of users and it belongs to users. You can argue as to who those users are - the individual database users running queries or the administrator running the server for those database users - but there are users.
J4amieC wrote:
This is ignoring the fact that where SQL Server stores this data is completely configurable.
Yes, I am ignoring this fact too, because the location I mentioned is the DEFAULT, so they're not practicing what they're preaching, BY DEFAULT. Even if I concede that SQL Server is special because it's a service, it's not like Microsoft is saying "Well, okay, if you're talking about a service then I guess it's okay for you to put it there". The point is, they don't want you to save your data under Program Files, service or not, but they do it themselves by default in SQL Server. I know I sound anal but I'm trying to rant here. ;P
I do think you are on a losing streak with the SQL Server location, it's only b/c you are a developer that you are even installing it (forget express), any other installation is on a server and Jamie is right it has no users. I'm a great one for not accepting the default of anything, for many years I would always change the installation path and or the data location to suit my personal style of disk management. The number of apps that fail when you change the default locations was dismaying, so much so that these days I always accept the default location. Oh EXCEPT for sql server which resides in a \\MSSQL\Data folder.
Never underestimate the power of human stupidity RAH
-
I do think you are on a losing streak with the SQL Server location, it's only b/c you are a developer that you are even installing it (forget express), any other installation is on a server and Jamie is right it has no users. I'm a great one for not accepting the default of anything, for many years I would always change the installation path and or the data location to suit my personal style of disk management. The number of apps that fail when you change the default locations was dismaying, so much so that these days I always accept the default location. Oh EXCEPT for sql server which resides in a \\MSSQL\Data folder.
Never underestimate the power of human stupidity RAH
I disagree with the user-less data idea. All data belongs to someone and with the way security is evolving there is an increasingly strong focus on accounts (users), permissions, access control, etc. Think for example of how these days you select for whom you install an app (your own user account only or all users). It's all moving towards a secure account-based way of working. Take the cloud as another example and think of how the cloud will ultimately interact with local data (if at all). It will be on a user account level. I think (and fear) that the days of data just lying on a hard drive, free for all (or none), is numbered. So I don't think one should argue in that way. It's user data (even if you want to see the corporation as the user) and if you want to keep all user data away from all programs (the way Microsoft seems to want to) then the default location sucks. But aside from the storage point, nobody seems to find the other things irritating, which is interesting. :sigh:
-
I do think you are on a losing streak with the SQL Server location, it's only b/c you are a developer that you are even installing it (forget express), any other installation is on a server and Jamie is right it has no users. I'm a great one for not accepting the default of anything, for many years I would always change the installation path and or the data location to suit my personal style of disk management. The number of apps that fail when you change the default locations was dismaying, so much so that these days I always accept the default location. Oh EXCEPT for sql server which resides in a \\MSSQL\Data folder.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
I'm a great one for not accepting the default of anything
I'm glad I'm not the only one...
I wasn't, now I am, then I won't be anymore.
-
I disagree with the user-less data idea. All data belongs to someone and with the way security is evolving there is an increasingly strong focus on accounts (users), permissions, access control, etc. Think for example of how these days you select for whom you install an app (your own user account only or all users). It's all moving towards a secure account-based way of working. Take the cloud as another example and think of how the cloud will ultimately interact with local data (if at all). It will be on a user account level. I think (and fear) that the days of data just lying on a hard drive, free for all (or none), is numbered. So I don't think one should argue in that way. It's user data (even if you want to see the corporation as the user) and if you want to keep all user data away from all programs (the way Microsoft seems to want to) then the default location sucks. But aside from the storage point, nobody seems to find the other things irritating, which is interesting. :sigh:
I find the changes irritating. I also hate their documentation for several reasons: 1. All the pages that belong together almost always have to be searched for separately. 2. Most descriptions aren't descriptive enough. Some aren't descriptive at all. 3. Snippets may be illustrative, but it's the stuff in the unlit corners that bite you. Give me a whole damn sample! 4. Microsoft's search engines don't rank results very well. I usually have to wade through five or more pages of results before concluding that MS indexes articles based on other keywords. 5. Help includes too much material. If I'm working in .NET 2.0, I don't care about the latest whiz-bang memory-eater in .NET 4.0. Leave it out! More gets worse than better.
-- Ed Eaglehouse Languages broken with standards confused, No wonder I've got me the Programmer's Blues.
-
Thanks for the input, but I don't think it's crazy.
J4amieC wrote:
SQL Server is a service, and as such has no user, and no user data
Of course it has users. The data stored in the databases are not for the sake of SQL Server and it doesn't belong to SQL Server. It's for the sake of users and it belongs to users. You can argue as to who those users are - the individual database users running queries or the administrator running the server for those database users - but there are users.
J4amieC wrote:
This is ignoring the fact that where SQL Server stores this data is completely configurable.
Yes, I am ignoring this fact too, because the location I mentioned is the DEFAULT, so they're not practicing what they're preaching, BY DEFAULT. Even if I concede that SQL Server is special because it's a service, it's not like Microsoft is saying "Well, okay, if you're talking about a service then I guess it's okay for you to put it there". The point is, they don't want you to save your data under Program Files, service or not, but they do it themselves by default in SQL Server. I know I sound anal but I'm trying to rant here. ;P
Roelof De Villiers wrote:
Of course it has users. The data stored in the databases are not for the sake of SQL Server and it doesn't belong to SQL Server. It's for the sake of users and it belongs to users. You can argue as to who those users are - the individual database users running queries or the administrator running the server for those database users - but there are users.
That is not how it works. SQL Server is not meant for user. It is meant for other applications to use it to store data. The fact that SQL Server would scatter its data on user's application directories is complete madness. The application data folders for users are meant for data pertaining to a user. For instance, you may store there user preferences for your application (layout, colors, last opened files, etc.). As such, it is meant for end-user-oriented applications. SQL Server is a server application. The location you specify for SQL server is the default one and any serious installation will configure SQL Server data files to go elsewhere.
Roelof De Villiers wrote:
I know I sound anal but I'm trying to rant here.
Rant about what?
-
Roelof De Villiers wrote:
Of course it has users. The data stored in the databases are not for the sake of SQL Server and it doesn't belong to SQL Server. It's for the sake of users and it belongs to users. You can argue as to who those users are - the individual database users running queries or the administrator running the server for those database users - but there are users.
That is not how it works. SQL Server is not meant for user. It is meant for other applications to use it to store data. The fact that SQL Server would scatter its data on user's application directories is complete madness. The application data folders for users are meant for data pertaining to a user. For instance, you may store there user preferences for your application (layout, colors, last opened files, etc.). As such, it is meant for end-user-oriented applications. SQL Server is a server application. The location you specify for SQL server is the default one and any serious installation will configure SQL Server data files to go elsewhere.
Roelof De Villiers wrote:
I know I sound anal but I'm trying to rant here.
Rant about what?
Le Gauchiste wrote:
The fact that SQL Server would scatter its data on user's application directories is complete madness
Do you mean that SQL Server would never do this (because it will, if you accept its default location which sits under Program Files), or do you mean that accepting its default location would be madness (which is my point: the default location sucks)? I have read LOTS of documentation that say that an application should save its application data (let's talk about APPLICATION data then if you would like to argue that there is no USER data) under the common application data folder which would be "C:\Documents and Settings\All Users\Application Data" or similar. This is NOT the Program Files folder. So defaulting SQL Server's data folder to Program Files is not following their own standard. And this is the ONLY point I ever tried to make. I wasn't trying to debate whether one SHOULD save it there or not; that's another story.
Le Gauchiste wrote:
Rant about what?
Read my original post. I complained about Microsoft not sticking to their own standards, basically. The data storage point was one of four examples.
-
Le Gauchiste wrote:
The fact that SQL Server would scatter its data on user's application directories is complete madness
Do you mean that SQL Server would never do this (because it will, if you accept its default location which sits under Program Files), or do you mean that accepting its default location would be madness (which is my point: the default location sucks)? I have read LOTS of documentation that say that an application should save its application data (let's talk about APPLICATION data then if you would like to argue that there is no USER data) under the common application data folder which would be "C:\Documents and Settings\All Users\Application Data" or similar. This is NOT the Program Files folder. So defaulting SQL Server's data folder to Program Files is not following their own standard. And this is the ONLY point I ever tried to make. I wasn't trying to debate whether one SHOULD save it there or not; that's another story.
Le Gauchiste wrote:
Rant about what?
Read my original post. I complained about Microsoft not sticking to their own standards, basically. The data storage point was one of four examples.
SQL Server is a server application, not an end-user application. It is like you want SQL Server to act like Word or Excel.
-
SQL Server is a server application, not an end-user application. It is like you want SQL Server to act like Word or Excel.
Does it make a difference whether it's a server or end-user application? Funny, the documentation doesn't treat them differently. What is the fundamental difference that comes in as soon as someone mentions the words "end-user" or "front-end" or "UI"? Is it not just a mindset? Is there really some differentiating aspect that I'm missing? Anyway, I was talking about APPLICATION settings to make my last point, not USER settings. Do you believe that APPLICATION settings belong in Program Files?
-
Does it make a difference whether it's a server or end-user application? Funny, the documentation doesn't treat them differently. What is the fundamental difference that comes in as soon as someone mentions the words "end-user" or "front-end" or "UI"? Is it not just a mindset? Is there really some differentiating aspect that I'm missing? Anyway, I was talking about APPLICATION settings to make my last point, not USER settings. Do you believe that APPLICATION settings belong in Program Files?
end-user: Applications allowing users, always logged in, to perform work using business applications. For instance, Word, Excel, etc. server application: Applications usually running as soon as the computer starts up, and do not need any user actually logged in. Those applications rarely sport an end-user interface (except for managing the server, but not always required). Such applications include database servers, web servers, application servers. Those applications do not follow traditional conventions because their needs are specific to them. A database server, for instance, may require to have its data disks on special disk system, shared with other database servers, for redundancy and load balancing. Server applications can also be distributed (running on multiple machines) to handle heavy load, so having user directories as their directories does not make sense. front-end: A mix of end-user and server. In this case, you have back-end systems (one more for you to learn!), consisting of server applications, and a front-end, which allows users to perform various things that will interact with the server applications to extract and store data and other business-related tasks.. A front-end application may use local user directories to maintain user preferences and such, but the back-end (server application(s)), will use its own structure. A good example of a front-end application is Code Project. The front-end consists of a web server, but the user directories are used by your web browser, although the web server itself, even if considered part of the front-end, is using its own structure, because it is a server. The Code Project back-end part probably consists of database servers and other stuff I don't know about. Having this discussion with you somewhat tells me that you are fairly new to the professions. You will learn all this stuff as you go along and progress. It is a lot to learn and take years to become comfortable with all the concepts.
-
end-user: Applications allowing users, always logged in, to perform work using business applications. For instance, Word, Excel, etc. server application: Applications usually running as soon as the computer starts up, and do not need any user actually logged in. Those applications rarely sport an end-user interface (except for managing the server, but not always required). Such applications include database servers, web servers, application servers. Those applications do not follow traditional conventions because their needs are specific to them. A database server, for instance, may require to have its data disks on special disk system, shared with other database servers, for redundancy and load balancing. Server applications can also be distributed (running on multiple machines) to handle heavy load, so having user directories as their directories does not make sense. front-end: A mix of end-user and server. In this case, you have back-end systems (one more for you to learn!), consisting of server applications, and a front-end, which allows users to perform various things that will interact with the server applications to extract and store data and other business-related tasks.. A front-end application may use local user directories to maintain user preferences and such, but the back-end (server application(s)), will use its own structure. A good example of a front-end application is Code Project. The front-end consists of a web server, but the user directories are used by your web browser, although the web server itself, even if considered part of the front-end, is using its own structure, because it is a server. The Code Project back-end part probably consists of database servers and other stuff I don't know about. Having this discussion with you somewhat tells me that you are fairly new to the professions. You will learn all this stuff as you go along and progress. It is a lot to learn and take years to become comfortable with all the concepts.
Le Gauchiste wrote:
one more for you to learn!
Are you kidding me? I've been trying to remain polite despite your not answering ANY of my questions. Instead you just ignored them and tried a different angle each time. What is the point behind the two paragraphs you just wrote? Are you saying "Yes, SQL Server should default its application data folder to Program Files", or are you saying "No, SQL Server should NOT default its application data folder to Program Files"? Because that is the only point at hand. A simple "yes" or "no" would have worked a couple of posts ago but you can't seem to commit to either. I challenge you to reply with "yes" or "no". What we have here is a difference in opinion, sir. Not necessarily you being so senior and me being so junior. I am 34 and have been coding since 17. That's not exactly new to the "professions".
-
Le Gauchiste wrote:
one more for you to learn!
Are you kidding me? I've been trying to remain polite despite your not answering ANY of my questions. Instead you just ignored them and tried a different angle each time. What is the point behind the two paragraphs you just wrote? Are you saying "Yes, SQL Server should default its application data folder to Program Files", or are you saying "No, SQL Server should NOT default its application data folder to Program Files"? Because that is the only point at hand. A simple "yes" or "no" would have worked a couple of posts ago but you can't seem to commit to either. I challenge you to reply with "yes" or "no". What we have here is a difference in opinion, sir. Not necessarily you being so senior and me being so junior. I am 34 and have been coding since 17. That's not exactly new to the "professions".
That is because there is no yes or no. It depends on the configuration you and also company policies as for application directories. That is it. For instance, if you are developer and have a local SQL Server installation, you will probably be happy with the default installation. On other environments, like QA, staging, production, training, installations will differ. Production will certainly be the most strict regarding directory locations.
Roelof De Villiers wrote:
Not necessarily you being so senior and me being so junior. I am 34 and have been coding since 17. That's not exactly new to the "professions".
And you are still not able to understand why SQL Server does not use user's Application Data directories?
-
That is because there is no yes or no. It depends on the configuration you and also company policies as for application directories. That is it. For instance, if you are developer and have a local SQL Server installation, you will probably be happy with the default installation. On other environments, like QA, staging, production, training, installations will differ. Production will certainly be the most strict regarding directory locations.
Roelof De Villiers wrote:
Not necessarily you being so senior and me being so junior. I am 34 and have been coding since 17. That's not exactly new to the "professions".
And you are still not able to understand why SQL Server does not use user's Application Data directories?
It's not that I don't understand. It's that I don't agree.
-
It's not that I don't understand. It's that I don't agree.
Whether you agree or not, it is how it is done.