Cant be sure since we're at the max depth/. allows, but I'll assume you're responding to me.
The conversation as it was being had was purely about the MS world. The whole 'what do I do with BeOS' was off-topic from the start. I probably shouldnt have responded to it, as it was a fairly silly troll.
The conversation was about whether there was or was not any such thing as 'forced upgrades' or an 'upgrade treadmill'.
Due to the topic, this necessarily applies only to the 'ms world'.
So yes, we all understand there's a world outside of MS. But within the context of what we were talking about (ie, force upgrades) its scoped to just the MS world, as they're the only ones who buy MS products.
Your quote was from the GrokLaw summary, which used some creative editing of the original blog posting to create drama and brouhaha. It's important to go to the actual article that GrokLaw was quoting and get the information from the source.
Based on the actual root article, the results from the transitional version was nearly perfect, with 84 instances of the same (very minor) class of error.
From TFA:
The TRANSITIONAL conformance model is quite a bit closer to the original Ecma 376. Countries at the BRM (rather more than Ecma, as it happened) were very keen to keep compatibilty with Ecma 376 and to preserve XML structures at which legacy Office features could be targetted. The expectation is therefore that an MS Office 2007 document should be pretty close to valid according to the TRANSITIONAL schema.
Sure enough (again) the result is as expected: relatively few messages (84) are emitted and they are all of the same type complaining e.g. of the element:
<m:degHide m:val="on"/>
since the allowed attribute values for val are now "true", "false", etc. this was one of the many tidying-up exercices performed at the BRM. This is a simple (and very common in this sort of thing) error, and not too surprising or worrisome. It's basically a very minor errata.
This is actually quite impressive, given that the transitional version is not the same as what MS originally proposed, and so there was also little expectation that a document format created in the past would be conformant. It looks like the groups went to some effort to make sure that the transitional version was nearly 100% compatible with what MS Office 2007 actually emits.
And it shouldnt be surprising to anyone that Office 2007 doesnt conform to the strict version. The strict version was semi-major surgery on what MS proposed. And it was developed long after Office 2007 was released.
More from TFA:
Validating against the STRICT model
The STRICT conformance model is quite a bit different from Ecma 376, essentially because most of that format's most notorious features (non ISO dates, compatibility settings like autospacewotnot, VML, etc.) have been removed. Thus the expectation is that existing Office 2007 documents might be some distance away from being valid according to the strict schemas.
Sure enough, jing emitted 17MB (around 122,000) of invalidity messages when validating in this scenario. Most of them seem to involve unrecognised attributes or attribute values: I would expect a document which exercised a wider range of features to generate a more diverse set of error message. Again, to restate. The strict version of ISO OOXML (what causes all the errors in validation) is NOT based on the current version of MS Office 2007. Therefore there is no reason to expect that Office 2007 docs would be fully compliant. The strict version did not exist when Office 2007 was created, therefore it was not possible for them to be conformant to it.
To do so would have required them to predict into the future the path that ISO would take.
Now the interesting question will be whether MS aligns with the strict ISO OOXML in a future Office 2007 Service Pack, or even if they clean up that one minor issue found here (on/off vs. true/false in attributes).
The strict version breaks alot of backwards compatibility with legacy documents that were created in much older versions of office and forward converted. Given that, I'll be interested to see what MS does with this over the next year or two as their releases catch up to the ISO standards.
You either conform to a standard or you don't. Thats a nice theory but not really practical. ISO OOXML (strict version) was created between MS product releases.
How long should it have taken for MS to release a version that matched ISO OOXML strict? One hour? One day? One year? More?
Companies dont have the magical ability to instantly create a released product the day that the standards group settles on something. Thats just absurd.
A standard that allows non conforming versions is no standard. Standards dont allow or disallow implementations. Thats now how it works. Standards exist. Implementations try to be compliant to them.
According to TFA, Office 2007 OOXML is very conformant to ISO OOXML Transitional. But its not very comformant to ISO OOXML Strict.
This should not be a surprise. For examle, the Strict version removes VML as a vector graphics markup. But MS has a decade or more of investment in VML, and their currently released products use VML. It will take a while for MS to change Office to not use VML (assuming they do choose to).
If it would take 2 to 4 years for M$ to properly implement and document their crappy little standard, it should take 2 to 4 years for people to believe they had a standard worthy of ISO approval. I agree that it shouldnt have been fast tracked. That was a bit of an abomination. But lets be clear that MS didnt create a new standard, and then implement it. They just continued to develop their existing implementation, and documented what they already had. The OOXML is not a fresh creation... its a documentation of something that has existed and been evolving for 10-15 years.
Standards that come from mature, crufty old de-facto standards (ie, OOXML) are always going to be uglier than standards that were created to be a standard from day one (ie, ODF). Thats just reality. Expecting it to be clean and pretty is not reasonable.
But the world where OOXML and the previous binary.doc.xls, etc formats are documented (ie, the world we're in now) is better than the one we were in before, where none of it was documented.
PS, thank you Twitter for being reasonably coherent and making a post that, littered with the M$ nonsense that it is, at least was a reasonable discussion.
I certainly hope that MS will choose to keep the office products inline with the ISO standard, at least as a subset (ie, they may add additional things to it, but still be backwards compatible with the ISO OOXML).
But only time will tell. Right now, the ISO strict version of OOXML has moved too fast for MS' relatively slow product release cycle to keep up. Give it a service pack or two, or maybe the next Office version before we'll know for sure.
2. Install the free, simple, easy to install compat pack from MS.
Nothing you've said here translates into MS forcing you to upgrade. In fact they've given you tools that make it easy and simple to NOT upgrade, and made them free to download.
This is not to suggest that MS doesnt WANT you to upgrade, of course they do. But many, many businesses and orgs are still running quite successfully on older versions of MS Office.
Note that the 122k errors are for the STRICT version, which does not, and is not intended to, match any current version of MS Office ooxml output.
The transitive version does match Office 2007, and has only a few errors, and nearly all of them a simple on/off where it should be true/false.
It will probably take MS until the next version of Office, or at best a service-pack or two, to get it conformant with the evolution to the original proposal.
So... MS submitted the original proposal, which was a dump of what the product was producing at the time. ISO then created a new strict version, which removed things like VML that Office currently uses. MS has not released a new version of office since the evolution to the strict version.
Given all that, it should not be a surprise that Office doesnt produce strict conformant output... it was never designed to, and the strict version didnt even exist at the time.
Actually no. They queue up and rarely install themselves. I have 10 different machines on 3 networks that do this. What do the logs say, why are they not installing?
The point of the article is that MS Office isnt conformant to the STRICT version. This shouldnt come as a surprise, as the change from the original OOXML to the strict version happened, but no new versions of MS Office have been released. The best thing anyone could reasonably expect of a company is that they would update it in the next Office 2007 service pack.
Office comes in a 2-4 year release cycle, and the change in ISO from the transitional version to the strict version happened after Office 2007 SP1 was already done.
How could MS have known in advance the changes that would happen to the standard? They cant see into the future.
Dont forget here that the STRICT version is NOT representative of what any version of office produces. We already knew that.
It was an ISO evolution of the submitted version (the transitional one). The vendor would need some time and a release cycle to adapt their products to it.
What _will_ be interesting is how/when/if MS does conform to the strict format.
On the other hand, the MS Word conformance to the transitional format seems reasonable. TFA only noted one problem, where an attribute value was using on/off rather than true/false. This is minor and easily fixed and/or recorded as a known issue.
I know its been a few days since this thread went by... but this is just ridiculous.
Automatic Updates requires no user interaction. Come 3am it will install any downloaded patches. No user interaction required.
On most corporate configurations, end-users wont even see the yellow shield in the system tray.
On several hundred machines that I have responsibility for, we get 3-4 bad patches per year. And by that I mean 3-4 machines have problems with patches. Out of a few hundred x 12 months per year x number of patches per super tuesday.
These are very reasonable failure ratios, and not indicative of 'profoundly broken'.
And what the heck would be the point of your massive super-patch distro you describe a couple levels above? Sounds like a lot of wasted bandwidth and cycles for no purpose whatsoever. MS went to major lengths to do proper binary delta compressed patches years ago because of complaints of the patch size.
At the risk of dragging this conversation out to a ridiculous point....
I dont think the Windows architecture is simple and easy. I just think, if this is what you do for a living, then its very doable. It takes some reading, and some experience. But if you're going to publish/sell software for that platform, then you need to take the time to figure out what you're doing.
And also note that you're one who came up with the words 'lazy scum'.:) My business is one of those ISVs, but I've taken the time to make sure that my software works well on windows (since our software will run on windows). The installer works, I dont store information in the registry (other than one dependent library that needs to be registered with COM), and the app is self repairing. And it works as a non-admin user. Without UAC popups.
And I didnt have to make ANY changes for it to do so on Vista. It was designed correctly, and so it 'just worked'.
This kind of thing is not beyond the reach of your average developer. I'm no super-guru or anything, far from it.
The UAC is living proof that the windows security model is way too complex for its audience This I dont understand. At this point, all of the mainstream desktop operating systems have some variation of this. gksudo, uac, whatever the heck kde calls it, the password popup in OSX, etc.
There are some implementation differences, but its basically the same thing. If thats proof that the windows security model, then every security model in mainstream OSs are also broken. What triggers UAC most is violation of file system acls. All operating systems have them, in one flavor or another. Things like UAC and sudo are one of the ways to get around them.
And of course the problem with dried peas is that babies will stick them up their noses. So you don't give dried peas to babies. Babies and professional software developers are different things, and its reasonable to have different expectations from them.
users are stupid lusers That was not something you quoted from me, either from my words or intent.
3d party developers are lazy, irresponsible scum That, on the other hand, is true a surprisingly large percentage of the time.
Assuming that all developers would acquire intimate knowledge with an overengineered and horribly complex security architecture such as windows' was *NOT* realistic (we all do religiously read every system manual back to cover, right?). You make it sound like its some sort of zen mysticism. It's not really that complicated. Dont assume your users will be admins. Dont write app or user settings to Program Files. Thats a big chunk of it right there.
When you're going to work on a car, you get the shop manual. When you're going to build a bridge, you get an engineering education. When you're going to write software on a platform, you learn enough about the platform to make sure that the software works properly. This is not terribly complicated stuff.
That does not even begin to address the fact that the security architecture itself (and the associated guidelines) kept shifting from release to release (for example bit renaming quite a few system accounts during win2k->XP), making it even more a headache The security 'architecture' didnt change. Some small details about the security systems changed. The basics have been the same since the NT4 days. With every new release of Windows, MS creates significant resources for whats changed for developers, and guidance around what you need to change, if anything. This is all well published information.
Even with the switch to Vista. If you followed all the guidance in the logo program for XP, then your apps would work perfectly in Vista, with no changes, and no UAC popups (except for the installer, of course)....
Overall, its just not as hard or complicated as you make it sound. Sure it requires that you do some reading, and get up to speed at least minimally on the underlying platform. But thats true of all systems.
You seem to be suggesting that someone should be able to write software that works on a platform without having any knowledge of the platform. Thats just silly.
From the SP1 Release Notes, under the 'General Improvements and Enhancements' section:
SP1 reduces the number of UAC (User Account Control) prompts from 4 to 1 when creating or renaming a folder at a protected location. One of the product managers had mentioned it on the Vista blog as well, which is where I heard about it first.
I think its not too surprising that MS didnt build a 64-bit version of office. What would be the point?
Office wouldnt ever need more than 2-3GB of memory space per process, so why go to the trouble?
It's not like there's a noticeable performance hit to running x86 apps on x64 vista.
There are obvious reasons why you'd build 64-bit versions of SQL Server, IIS,.NET, etc. And MS has. But for typical desktop apps (web browsers, etc), it doesnt really buy you anything to have a 64-bit build.
And for something like office, where there's probably 15+ year old legacy code in there, that does lots of 'tricky' stuff, I can understand not being in a rush to change it all (from a business perspective).
And ultimately, the customer would benefit not at all from a 64-bit version of Office. Just flat would not see a difference.
I dont really feel too bad about losing 16-bit plugin functionality. Thats just such an extreme case.
But I do feel quite a bit for the Mac folks, with the loss of VBA for Mac Office.
I read a great blog article by one of the product managers in the MacBU part of MS, about why they chose to not continue including VBA.
I'm paraphrasing, but apparently VBA is just a monstrous hack. It was developed in a time when systems were slow, and onboard macro languages were hard to do in a performant way. So they used some quite intelligent C programmers do really tricky stuff, including partial optimization to assembly.
Lots of 'trickiness' for speed, in other words. If you've done this kind of work... you can imagine the side effects of that. It becomes nearly unmaintainble in the future if you dont have those same folks around, or similarly talented people.
So basically they did something that got them big wins in the past, but it came at a cost of maintainability. They're now paying that cost, and its hurting them competitively in the current market, which is very different from the one in which VBA was originally developed.
I can understand from a business perspective not wanting to support that forever, but it sure is hard on the customers who would use it.
To be clear here, I'm not really for or against the VBA on Mac Office decision. I just completely understand what a horrible position MS put themselves into, and can understand how they might come to the decision they came to, even if its not necessarily what I would have done.
OT: And, excuse me, what's bad on being non-native English speaker? Nothing. What's wrong is trying to write a technically oriented article meant to be persuasive in a language you dont speak very well.
That person posting it in English would be the equivalent of me posting this in Spanish. It would utterly destroy my credibility, because hardly anyone would understand me (I dont speak spanish very well).
This person should have just posted in their native language, IMO.
You've got alot of this stuff close, but wrong on the details.
On Windows 2000, if I recall correctly, scheduler (cron) jobs had to be granted "Logon as a network service" to work (Huh?). Not quite. The user that the at jobs ran as had to be granted 'logon as a service' user rights. Which was reasonable at the time, as that was being invoked from the AT service.
Programs using COM need(ed) (elevated) DCOM -related privileges to invoke out-of-process servers. Under very special cases, but not generally.
Accessing network shares from a web program (may) require *a domain account with administrative DOMAIN privileges* (that crazy or what?) Only crazy if you actually had the details right, which you dont.
Accessing network shares from a web program may require a 'domain' account. Thats it. There are other ways to do it too (ie, same user/pass on both boxes used to access the network resources).
What this really meant was that if a process running on one machine needed to access network shares on another machine, it would need credentials to do so. The rest was just implementation details of HOW you would do that. In most cases the file server shares were a domain box, so the easiest way to do it for most folks was to run the anonymous user in IIS as a domain account, so that it could cross machines.
There WAS some funkiness about cross-machine network access if you were logging into your website with a user/pass, rather than using anonymous. Then you had to user kerberos to make it work right, and it was funky.
That ultimately is a side-effect of a windows truth. You cannot spawn a process as a user unless you know the user's password. In many unices you can. There's plenty of reading if you really want to get into it, but thats the root cause.
In short the entire privilege architecture under windows is a big hairy mess nobody really understands, with thousands of privileges that you need to assign to perform tasks which are ostensibly unrelated to the names the privileges themselves are given. Huh. Guess the last 10 years of my professional life was just imaginary then, and same for all the people I've trained in the meantime.
Or maybe its just DIFFERENT from what you are used to, and you dont like to learn new things, so you choose to not learn about it.
The other biggie that brings us full circle is that user settings go in HKCU not HKLM Just out of curiosity, what is the concern with that? I'm just not sure what you mean by that sentence... but seems to imply that having user hives separate from the system hive is a bad thing. If thats what you mean, can you explain why?
How would you have built a Internet-capable server in 1994 on the x86 platform? You wouldnt. You'd do like everyone else did and put a Sun box up and be done with it.
Nor was Windows designed to be multi-user in the first place, either. It's roots were in DOS - one computer, one user. And by 'windows' you mean the long extinct 9x line of windows operating systems, which were based originally in DOS.
The NT line, which is what became win2000 and xp and vista and 2003server and 2008server, was, and is, multi-user.
I tried for months to get Windows NT4 to operate as a webserver and a DNS server with an uptime > 2-3 days. Couldn't do it with a (then pretty decent) Pentium-100 with 32 MB of RAM. It goes both ways though.
In a prior life, I managed a domain that had NT4 server boxes running Exchange 5.5, PDC, and file servers. Before the regular patching that we all know and love now, those boxes regularly had year+ uptimes.
So were you just making up random words in the hope of sounding informed? Or did you just get a little confused.
The teardrop attack has absolutely nothing to do with what you're talking about.
I think what you were probably trying to reference was a Shatter Attack.
Even this wasnt quite as simple or prevalant as you describe. And the whole class of attacks of which the Shatter Attack was one is eliminated in Vista by core changes to the windowing system.
Please make sure you're fully educated and knowledgeable about a subject before coming in here and spouting off as if you know what you were talking about.
That was one of the most horrendous blogs I've ever seen. Combine a completely lack of understanding of... just about anything on windows, combined with a non-native english speaker (or maybe he was drunk).
That article was filled with wildly inaccurate and ignorant nonsense. He clearly doesnt have a clue what the Excel/Sharepoint server product is, he seems to think its just Excel on the server.
He's all caught up about Office apps only being limited to 4gb of memory per process (which isnt even accurate) and how badly that will affect your ability to work with large spreadsheets. *boggle*
Oh and my favorite: The OOXML 'format' isnt 64-bit compatible. This one just had me about falling out of my chair. How exactly is a text-descriptor format NOT 64-bit compatible. And what would 64-bit compatible look like?
He/she also goes on about how Word document pagination will be slow because Word cant use the full set of registers on a 64-bit processor.
It just boggles the mind. This person obviously has no clue whatsoever about just about anything on Windows.
I'm not sure where you dredged that article up from, but thats one of the most laughable things I've seen in a long time.
Slashdot Mirror
Cant be sure since we're at the max depth /. allows, but I'll assume you're responding to me.
The conversation as it was being had was purely about the MS world. The whole 'what do I do with BeOS' was off-topic from the start. I probably shouldnt have responded to it, as it was a fairly silly troll.
The conversation was about whether there was or was not any such thing as 'forced upgrades' or an 'upgrade treadmill'.
Due to the topic, this necessarily applies only to the 'ms world'.
So yes, we all understand there's a world outside of MS. But within the context of what we were talking about (ie, force upgrades) its scoped to just the MS world, as they're the only ones who buy MS products.
You'll get no argument from me on the Fast Track issue. It shouldnt have been done that way.
The person who posted the article just couldnt be bothered to read it.
OEM/MSDN is going out in the next couple of days. General availability via Windows Update and download center on April 29th.
How are you using something that was just mastered today? Were you using a beta?
Based on the actual root article, the results from the transitional version was nearly perfect, with 84 instances of the same (very minor) class of error.
From TFA: The TRANSITIONAL conformance model is quite a bit closer to the original Ecma 376. Countries at the BRM (rather more than Ecma, as it happened) were very keen to keep compatibilty with Ecma 376 and to preserve XML structures at which legacy Office features could be targetted. The expectation is therefore that an MS Office 2007 document should be pretty close to valid according to the TRANSITIONAL schema.
Sure enough (again) the result is as expected: relatively few messages (84) are emitted and they are all of the same type complaining e.g. of the element: since the allowed attribute values for val are now "true", "false", etc. this was one of the many tidying-up exercices performed at the BRM. This is a simple (and very common in this sort of thing) error, and not too surprising or worrisome. It's basically a very minor errata.
This is actually quite impressive, given that the transitional version is not the same as what MS originally proposed, and so there was also little expectation that a document format created in the past would be conformant. It looks like the groups went to some effort to make sure that the transitional version was nearly 100% compatible with what MS Office 2007 actually emits.
And it shouldnt be surprising to anyone that Office 2007 doesnt conform to the strict version. The strict version was semi-major surgery on what MS proposed. And it was developed long after Office 2007 was released.
More from TFA: Validating against the STRICT model
The STRICT conformance model is quite a bit different from Ecma 376, essentially because most of that format's most notorious features (non ISO dates, compatibility settings like autospacewotnot, VML, etc.) have been removed. Thus the expectation is that existing Office 2007 documents might be some distance away from being valid according to the strict schemas.
Sure enough, jing emitted 17MB (around 122,000) of invalidity messages when validating in this scenario. Most of them seem to involve unrecognised attributes or attribute values: I would expect a document which exercised a wider range of features to generate a more diverse set of error message. Again, to restate. The strict version of ISO OOXML (what causes all the errors in validation) is NOT based on the current version of MS Office 2007. Therefore there is no reason to expect that Office 2007 docs would be fully compliant. The strict version did not exist when Office 2007 was created, therefore it was not possible for them to be conformant to it.
To do so would have required them to predict into the future the path that ISO would take.
Now the interesting question will be whether MS aligns with the strict ISO OOXML in a future Office 2007 Service Pack, or even if they clean up that one minor issue found here (on/off vs. true/false in attributes).
The strict version breaks alot of backwards compatibility with legacy documents that were created in much older versions of office and forward converted. Given that, I'll be interested to see what MS does with this over the next year or two as their releases catch up to the ISO standards.
How long should it have taken for MS to release a version that matched ISO OOXML strict? One hour? One day? One year? More?
Companies dont have the magical ability to instantly create a released product the day that the standards group settles on something. Thats just absurd. A standard that allows non conforming versions is no standard. Standards dont allow or disallow implementations. Thats now how it works. Standards exist. Implementations try to be compliant to them.
According to TFA, Office 2007 OOXML is very conformant to ISO OOXML Transitional. But its not very comformant to ISO OOXML Strict.
This should not be a surprise. For examle, the Strict version removes VML as a vector graphics markup. But MS has a decade or more of investment in VML, and their currently released products use VML. It will take a while for MS to change Office to not use VML (assuming they do choose to). If it would take 2 to 4 years for M$ to properly implement and document their crappy little standard, it should take 2 to 4 years for people to believe they had a standard worthy of ISO approval. I agree that it shouldnt have been fast tracked. That was a bit of an abomination. But lets be clear that MS didnt create a new standard, and then implement it. They just continued to develop their existing implementation, and documented what they already had. The OOXML is not a fresh creation
Standards that come from mature, crufty old de-facto standards (ie, OOXML) are always going to be uglier than standards that were created to be a standard from day one (ie, ODF). Thats just reality. Expecting it to be clean and pretty is not reasonable.
But the world where OOXML and the previous binary
PS, thank you Twitter for being reasonably coherent and making a post that, littered with the M$ nonsense that it is, at least was a reasonable discussion.
Maybe.
I certainly hope that MS will choose to keep the office products inline with the ISO standard, at least as a subset (ie, they may add additional things to it, but still be backwards compatible with the ISO OOXML).
But only time will tell. Right now, the ISO strict version of OOXML has moved too fast for MS' relatively slow product release cycle to keep up. Give it a service pack or two, or maybe the next Office version before we'll know for sure.
Easy solution.
.doc or .pdf.
1. Tell them to send you
or
2. Install the free, simple, easy to install compat pack from MS.
Nothing you've said here translates into MS forcing you to upgrade. In fact they've given you tools that make it easy and simple to NOT upgrade, and made them free to download.
This is not to suggest that MS doesnt WANT you to upgrade, of course they do. But many, many businesses and orgs are still running quite successfully on older versions of MS Office.
Note that the 122k errors are for the STRICT version, which does not, and is not intended to, match any current version of MS Office ooxml output.
... MS submitted the original proposal, which was a dump of what the product was producing at the time. ISO then created a new strict version, which removed things like VML that Office currently uses. MS has not released a new version of office since the evolution to the strict version.
... it was never designed to, and the strict version didnt even exist at the time.
The transitive version does match Office 2007, and has only a few errors, and nearly all of them a simple on/off where it should be true/false.
It will probably take MS until the next version of Office, or at best a service-pack or two, to get it conformant with the evolution to the original proposal.
So
Given all that, it should not be a surprise that Office doesnt produce strict conformant output
What have you done to troubleshoot this?
What is this 'upgrade treadmill' you're referring to?
.gov orgs at least here in the US that I've seen are using everything from Office 97 to Office 2003, but none are using Office 2007.
Most
That suggests to me that there is no 'forced upgrade' or 'upgrade treadmill'.
What is it that you're seeing that indicates otherwise to you?
I wouldnt agree with your statement.
The point of the article is that MS Office isnt conformant to the STRICT version. This shouldnt come as a surprise, as the change from the original OOXML to the strict version happened, but no new versions of MS Office have been released. The best thing anyone could reasonably expect of a company is that they would update it in the next Office 2007 service pack.
Office comes in a 2-4 year release cycle, and the change in ISO from the transitional version to the strict version happened after Office 2007 SP1 was already done.
How could MS have known in advance the changes that would happen to the standard? They cant see into the future.
Dont forget here that the STRICT version is NOT representative of what any version of office produces. We already knew that.
It was an ISO evolution of the submitted version (the transitional one). The vendor would need some time and a release cycle to adapt their products to it.
What _will_ be interesting is how/when/if MS does conform to the strict format.
On the other hand, the MS Word conformance to the transitional format seems reasonable. TFA only noted one problem, where an attribute value was using on/off rather than true/false. This is minor and easily fixed and/or recorded as a known issue.
I know its been a few days since this thread went by ... but this is just ridiculous.
Automatic Updates requires no user interaction. Come 3am it will install any downloaded patches. No user interaction required.
On most corporate configurations, end-users wont even see the yellow shield in the system tray.
On several hundred machines that I have responsibility for, we get 3-4 bad patches per year. And by that I mean 3-4 machines have problems with patches. Out of a few hundred x 12 months per year x number of patches per super tuesday.
These are very reasonable failure ratios, and not indicative of 'profoundly broken'.
And what the heck would be the point of your massive super-patch distro you describe a couple levels above? Sounds like a lot of wasted bandwidth and cycles for no purpose whatsoever. MS went to major lengths to do proper binary delta compressed patches years ago because of complaints of the patch size.
I dont think the Windows architecture is simple and easy. I just think, if this is what you do for a living, then its very doable. It takes some reading, and some experience. But if you're going to publish/sell software for that platform, then you need to take the time to figure out what you're doing.
And also note that you're one who came up with the words 'lazy scum'.
And I didnt have to make ANY changes for it to do so on Vista. It was designed correctly, and so it 'just worked'.
This kind of thing is not beyond the reach of your average developer. I'm no super-guru or anything, far from it. The UAC is living proof that the windows security model is way too complex for its audience This I dont understand. At this point, all of the mainstream desktop operating systems have some variation of this. gksudo, uac, whatever the heck kde calls it, the password popup in OSX, etc.
There are some implementation differences, but its basically the same thing. If thats proof that the windows security model, then every security model in mainstream OSs are also broken. What triggers UAC most is violation of file system acls. All operating systems have them, in one flavor or another. Things like UAC and sudo are one of the ways to get around them.
When you're going to work on a car, you get the shop manual. When you're going to build a bridge, you get an engineering education. When you're going to write software on a platform, you learn enough about the platform to make sure that the software works properly. This is not terribly complicated stuff. That does not even begin to address the fact that the security architecture itself (and the associated guidelines) kept shifting from release to release (for example bit renaming quite a few system accounts during win2k->XP), making it even more a headache The security 'architecture' didnt change. Some small details about the security systems changed. The basics have been the same since the NT4 days. With every new release of Windows, MS creates significant resources for whats changed for developers, and guidance around what you need to change, if anything. This is all well published information.
Even with the switch to Vista. If you followed all the guidance in the logo program for XP, then your apps would work perfectly in Vista, with no changes, and no UAC popups (except for the installer, of course).
Overall, its just not as hard or complicated as you make it sound. Sure it requires that you do some reading, and get up to speed at least minimally on the underlying platform. But thats true of all systems.
You seem to be suggesting that someone should be able to write software that works on a platform without having any knowledge of the platform. Thats just silly.
Office wouldnt ever need more than 2-3GB of memory space per process, so why go to the trouble?
It's not like there's a noticeable performance hit to running x86 apps on x64 vista.
There are obvious reasons why you'd build 64-bit versions of SQL Server, IIS,
And for something like office, where there's probably 15+ year old legacy code in there, that does lots of 'tricky' stuff, I can understand not being in a rush to change it all (from a business perspective).
And ultimately, the customer would benefit not at all from a 64-bit version of Office. Just flat would not see a difference.
I dont really feel too bad about losing 16-bit plugin functionality. Thats just such an extreme case.
But I do feel quite a bit for the Mac folks, with the loss of VBA for Mac Office.
I read a great blog article by one of the product managers in the MacBU part of MS, about why they chose to not continue including VBA.
I'm paraphrasing, but apparently VBA is just a monstrous hack. It was developed in a time when systems were slow, and onboard macro languages were hard to do in a performant way. So they used some quite intelligent C programmers do really tricky stuff, including partial optimization to assembly.
Lots of 'trickiness' for speed, in other words. If you've done this kind of work
So basically they did something that got them big wins in the past, but it came at a cost of maintainability. They're now paying that cost, and its hurting them competitively in the current market, which is very different from the one in which VBA was originally developed.
I can understand from a business perspective not wanting to support that forever, but it sure is hard on the customers who would use it.
To be clear here, I'm not really for or against the VBA on Mac Office decision. I just completely understand what a horrible position MS put themselves into, and can understand how they might come to the decision they came to, even if its not necessarily what I would have done. OT: And, excuse me, what's bad on being non-native English speaker? Nothing. What's wrong is trying to write a technically oriented article meant to be persuasive in a language you dont speak very well.
That person posting it in English would be the equivalent of me posting this in Spanish. It would utterly destroy my credibility, because hardly anyone would understand me (I dont speak spanish very well).
This person should have just posted in their native language, IMO.
This was changed in Vista SP1. Prior to SP1, in most cases it would require 3 UAC prompts.
The 3-UAC prompt business is also fixed in Vista SP1. It only requires one UAC now, as it should.
Accessing network shares from a web program may require a 'domain' account. Thats it. There are other ways to do it too (ie, same user/pass on both boxes used to access the network resources).
What this really meant was that if a process running on one machine needed to access network shares on another machine, it would need credentials to do so. The rest was just implementation details of HOW you would do that. In most cases the file server shares were a domain box, so the easiest way to do it for most folks was to run the anonymous user in IIS as a domain account, so that it could cross machines.
There WAS some funkiness about cross-machine network access if you were logging into your website with a user/pass, rather than using anonymous. Then you had to user kerberos to make it work right, and it was funky.
That ultimately is a side-effect of a windows truth. You cannot spawn a process as a user unless you know the user's password. In many unices you can. There's plenty of reading if you really want to get into it, but thats the root cause. In short the entire privilege architecture under windows is a big hairy mess nobody really understands, with thousands of privileges that you need to assign to perform tasks which are ostensibly unrelated to the names the privileges themselves are given. Huh. Guess the last 10 years of my professional life was just imaginary then, and same for all the people I've trained in the meantime.
Or maybe its just DIFFERENT from what you are used to, and you dont like to learn new things, so you choose to not learn about it.
The NT line, which is what became win2000 and xp and vista and 2003server and 2008server, was, and is, multi-user.
In a prior life, I managed a domain that had NT4 server boxes running Exchange 5.5, PDC, and file servers. Before the regular patching that we all know and love now, those boxes regularly had year+ uptimes.
So were you just making up random words in the hope of sounding informed? Or did you just get a little confused.
The teardrop attack has absolutely nothing to do with what you're talking about.
I think what you were probably trying to reference was a Shatter Attack.
Even this wasnt quite as simple or prevalant as you describe. And the whole class of attacks of which the Shatter Attack was one is eliminated in Vista by core changes to the windowing system.
Please make sure you're fully educated and knowledgeable about a subject before coming in here and spouting off as if you know what you were talking about.
Wow.
... just about anything on windows, combined with a non-native english speaker (or maybe he was drunk).
And I mean wow.
That was one of the most horrendous blogs I've ever seen. Combine a completely lack of understanding of
That article was filled with wildly inaccurate and ignorant nonsense. He clearly doesnt have a clue what the Excel/Sharepoint server product is, he seems to think its just Excel on the server.
He's all caught up about Office apps only being limited to 4gb of memory per process (which isnt even accurate) and how badly that will affect your ability to work with large spreadsheets. *boggle*
Oh and my favorite: The OOXML 'format' isnt 64-bit compatible. This one just had me about falling out of my chair. How exactly is a text-descriptor format NOT 64-bit compatible. And what would 64-bit compatible look like?
He/she also goes on about how Word document pagination will be slow because Word cant use the full set of registers on a 64-bit processor.
It just boggles the mind. This person obviously has no clue whatsoever about just about anything on Windows.
I'm not sure where you dredged that article up from, but thats one of the most laughable things I've seen in a long time.