Slashdot Mirror
Anatomy Of A Bug In Microsoft Office
bender writes "An insightful look at what it is like to track down and fix a bug in Microsoft Office is available from Microsoft's Blog site."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Actually, I have to be honest and admit that Microsoft Office is a good product. Its stable, has alot of nice features and is intuitive to use.
I am not _at all_ a fan of M$, but we should be fair about this. Office is pretty solid.
Why don't they fix that awful formatting in MS Word?
You know, push enter twice and it returns to the default font/size. That really bothers me.
Click here for a free picture of an iPod!
Well congratulations. He stopped existing several years ago. Glad to see that you are up-to-date on your comments, though.
**To their credit though, this is changing fast. Microsoft is a huge company that can turn on a dime, and they've understood that having shite engineers onboard won't do much good to their latest "trustworthy computing" PR stunt. Not to mention, they actually have a nice R&D shop now, not just the pretense of one anymore.**
but wasn't quotes like this seen already in '91, then in '95 and then in 2000 already?
world was created 5 seconds before this post as it is.
Do you want it buggy today or robust tomorrow? One need only look at the overclocking community and throngs of beta-testers to work out the answer. History is littered with technically superior failures in the marketplace (Betamax, Divx, BeOS) and the reason is that the consumer is more fickle about price and features than about technical superiority or stability.
Read any book put out by Microsoft Press and it's plain there are a number of people there that are as or more capable than most open source programmers. But the open source programmer doesn't have to appease any person or schedule other than those he sets himself -- and can therefore program under much better circumstances.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
From the article
But there is a benefit to discussing complexity because it does seem to impact how many bugs arise and the maintainability, upgradeability, and usability of the software.
It's not merely a philosophical issue, either. This is a real, practical issue that impacts millions of people everyday.
The complexity of interacting software components is like the dark side of Metcalfe's Law about the usefulness of networks increasing quadratically with the number of participants in the network.
The maintainability of software decreases as the number of interacting components increase and as the number of ways of interaction increases.
I've developed code for a long time and seen great ideas turn into great code with creeping useful features gradually added on until a day comes when you wonder how you ended up working on such a monstrosity.
A good friend once told me years ago
"Provided by the management for your protection."
Cut the sarcasm. It really is innovative. It makes chunks of the document independent of what file they're in, and paved the way for an efficient implementation of our beloved "multiple undo" feature. And bear in mind that this was over 20 years ago, when the desktop software industry was just getting started and there was little prior experience to draw on.
Karma: Segmentation fault (tried to dereference a null post)
Have you read about all the new bugs that are being found in SP2.
Yes, and most of what is written is junk.
There are compaints about how the SP2 security panel can be spoofed.
Yes, they are uninformed compliants.
This allows a person to trick people into thinking their firewall and virus scan are all on and working normally.
Any person?
Microsoft's response... (paraphrased quote) "We are busy with other more important bugs at the time, don't bother us with these tivialities."
Umm.. no, thats a blantant distortion.
Here is the story you don't want to know:
A program running locally on the XP SP2 machine has the ability to overwrite the data store used to track and display the various updated components in XP SP2.
This isn't a remote vulnerability. It means that, simply put, a program can constantly overwrite the data that would indicate a virus scan hasn't taken place in 15 days, or that the firewall is off or open on certain ports, etc.
To have this "vulernability" be "exploited", first the protection would have to be subverted/turned off by the user. Nothing in this "exploit" allows an application to disable the features, just make them look as though they are in place. So after a program infilitrates the system and is running as an Administrator, it would be able to make the user think that the protection they already disabled was in fact running.
This is not a big deal. For example, let's say I had a program I could find a way to get onto a box with root access. I could just easily, if not more easily, spoof the security center interface and make it say what ever I wanted. I could just as easily spoof it to say "OH NO, GO DOWNLOAD THIS PATCH".
The point being this is a hole in the design or implementation. It's a social engineering attack. To be useful, the user would have to disable the protection on the machine; the user would then have to be convinced to download the trojan; the user would have to be induced to run the trojan; and the user would have to believe that he/she was in fact protected despite knowingly disabling the protection.
The nature of any operating system is that it responds to users actions. If any person/program can convince any user on any operating system to run any malicious binary as root/Administrator/etc than that box is exploitable by means of social engineering. Big deal. That's not new, it's not a security vulnerability per se, it's not anything but human nature.
Well, it's not *that* simple.
Figuring out how to best represent a document in memory can be more complicated than it would seem. Say, the easiest way would be just to malloc a chunk of memory for the whole document, but try to insert text into the middle of a 100 page document if you do it that way.
A more workable approach is to make it be an array with one entry per line, but that can run into exactly the same problem if you write a long enough paragraph.
So perhaps you go with something even more abstract, say, some kind of structure that contains pointers to words, which allows you to insert several invisible blanks every time you need to make space for stuff to reduce the time spent on memory management.
I think the article meant something similar to that last one.
"NT was 100% new code" ... except, I assume, for all that VMS code that DEC sucessfully sued Microsoft over.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Describes a huge chunk of my life in Software QA. It's an example of what is great about MS software and what is awful:
Great: dedicated test resources to chase down corner cases/non-obvious scenarios, accountability for broken scenarios, etc
Awful: Iterations of releases built on legacy code means no one (or two, or three) people can understand the problem or scope the fix.
For all the complaints here about MS code I wonder that no one has noticed the Windows weakness that is not getting exploited..? If MS software is really as bad as everyone here makes out then why doesn't someone do it better? Blah blah Linux blah blah... Build software for Windows that people can use without rebuilding their systems. If you do it well enough tell them it's even better on Platform X.
I'm not enamored with everything MS does, but I spend far more time patching my Linux box and updating apps on my Linux box than I do my Win XP boxes. Of course part of that is "release early, release often" and part of it is adding new features to catch up with much of the usability that XP has. But anyone who post on this thread about MS products having more bugs isn't eally being honest with themselves or the community.
And in closing, OSS will never sucees until supporterd drop the "Anything But Microsoft" rhetoric and point out what Linux and OSS in general do better.
I do understand all the complexities involved in trying to fix a bug the way the article describes. That's exactly why Open Source is superior. Instead of wasting a decade while 3 or 4 guys look at the problem from different angles, we'd have 3 or 4 hundred guys working on it not because it's their job but because they need it fixed. That's why fixes usually take days or hours on Open Source products.
OTOH, lots of people know enough programming to solve that kind of problem to their satisfaction. We don't have to submit that fix, so we don't have to worry too much about the side effects of the fix. That enables us to keep working with the product until some official (and usually better) solution comes along.
Insert predictable rant here about how there are no bugs in Free software because any user could fix the bug themselves...
I agree. No doubt there will be a few who suggest the many-eyes approach will fix all the world's evils... it won't, it will let a developer who can be bothered to sift through the thousands/millions of lines of code necessary to fix the bug - this is a dedicated programmer and deserves credit for that... the world is not full of a large number of dedicated intelligent programmers who have time to do this for all, or even a small fraction of code they encounter - if you use Open SOurce (I use BSD/Windows with open/prop apps, don't bother with the 'jokes') do really look through every line of code looking for a buffer overflow exploit, do you pro-rata what you look through with the assumed userbase, do you assume others will do the QC/QA/peer review? Sure it could be made to be ultra-secure, and for this I am all in favour of Open Source (there is absolutely no security through obscurity, as those that need to know will know), but I really have a gripe with those that blindly use the many-eyes assumption and group-think, auto-mod others who disagree. If you want to criticise MS Office, then do something about it.
MS Office is massive, MS Office may be bloated to those who does not use all those features (and who does?!), but the idea of modulising Office suites, good or bad idea that may be, died miserabley in the last 90s.
MS Office is inferior, functionality and UI wise, to specialist applications made for a certain job - I would never do serious statistical analysis in Excel nor would i distribute a Word doc, nor would I make a webpage in Word(!).
Criticise it for valid reason, not knee-jerk group think, but it does serve as a good lowest-common-denominator suite that integrates OK for an intermediate solution. Open software may also suck at many tasks, but carries the benefit it is open. If I see the 'many eyes' justification for all opensource software refered to again, without proper justification I think I will throw my computer out of the window - please mods - don't just mod something down because you disagree with it, if you disagree contribute and bring effective discussion rather than pushing an opinion out of the room - save downmods for things which are clearly Offtopic, Flamebait or Trollish (and baiting discussion is not Flamebait, it is Discussion-Bait).
I wonder how many programmers have run this scenario in their mind when doing some hypothetical designing of a hypothetical editor. Unfortunately, I bet its still patentable.
what a bunch of morons work at M$.
Let's see...
Introduce some gobbledeegook, heath-robinson-esq software design (ala piece-tables) just so the user can copy/paste ever so fast. <quote>For example, if you copy text from one document to another, you don't have to actually copy the text from one file to another--at least not right away</quote>
yes - therein lies the screw-up!!
They then live with this dog's breakfast of a code base for upwards of 10 (yes ten!!) years until its time to fix it. And the developers cant even work out which "Open file limit" has been reached. Well not very quickly anyway.
I have seen so much of this kind of "engineering" it makes me bleed from my ears. What's more, the author of this article portrays the story with so much nobility.
Things to always bear in mind I find are:
KISS
OCCAM's RAZOR
DONT TRY TO BE TOO SMART
END_OF_RANT
Isn't it great that the Mac unit can show the Windows guys the right way to fix a bug?
Wake up.
more like "Oh, your steamshovel has a broken cupholder? Here, drive this car instead."
:P
If you really need the steamshovel, a car is not a replacement, but the vast majority of people just need to drive around, and a car is perfectly fine.
Analogy explained -- I can see why some people actually need all the shit MS Office has, but for most people, OpenOffice is fine... hardly a Ferrari vs Yugo.. of course, you got modded up by the "I'm cool because I don't follow Slashdot groupthink" people, who, amusingly, have their own groupthink... so there you go... I'll probably be modded down by the same people.
Quidquid latine dictum sit, altum sonatur.
I'm sure Word has a milti-million line codebase. But so does AIX. It's split into different components, and there's quite a few bugs where I know roughly which code must have been running. So stare at the code for a few hours envisioning different inputs/control flows, and eventually a case that's not accounted for properly will show itself.
Bah. Amateurs.
Cheers, Matt
Terrorist, bomb, al Qaeda, nuclear, yellowcake, kill, assassinate. Carnivore is dead... long live Echelon.
have you ever actually released software into the wild?
I came across a bug in one of my active enterprise systems today that I had never seen before, and none of my 1500 users had reported it. It would have never been found had i not been just screwing around with random things.
Give the MS guys some credit here, they have a lot of things to go over with constantly looming deadlines. You can't test EVERYTHING.
?SYNTAX ERROR IN LINE 42
One one hand, I can understand bugs cropping up here-and-there, on the other I struggle.
From the article: Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do...
When I did compsci at Uni we had to logically prove each of our programs. This was not easy, but it made it impossible for a program to crash or have a bug - inputs clearly defined, outputs clearly reached - this was at a mid-high level, but applies bottom up - binary into assembly up the chain. It is totally possible to write bug-free code, but damn hard.
In the end of the day we are talking engineers, not scientists with their head in the clouds. Total bug-free code can be written, but a different version will have to be proved for every iteration of processor, address space, hardware combo, program interaction. This is time-consuming and costly. Mission critical apps can be proved perfect, for diverse massive office suites it's not worth the effort. I'd rather spend $200 on MS Office and have it crash now-and-again rather than spend $10k+ for a dedicated piece of hardware with millions of hours of development into getting it running on that equipment. In the latter bug-free case Open SOurce would find it incredibly hard to exist because of the wide diversification that benefits a smaller user-base.
It is a trade-off... on the one hand I suffer the odd crash and incompatibility with a cheap product with massive functionality, on the other I spend a massive portion of my income preventing problems which wouldn't be major anyway and accepting vastly reduced functionality with it. I do OK with a cheap and acceptable product and my income intact, or OO.o with even more of my income intact, MS do OK with big profits or OO.o developers enjoy more kudos and associated benefits. For apps with a higher degree of secutity necessary, such as a web browser, email client, or file/web server, I get choice of what to use - again with a whole range of trade-offs: Lynx for speed and securtiy through IE for compatibility but little security. MS doing OK with $$$ from what benefit IE has given them is less acceptable.
I'd rather my product able to do core requirements (security for a webborwser which MS fail at IMHO, to functionality for an Office suite which they have excelled at since 97) now with minor bugs (in non core/critical areas) - have you seriously encountered bugs necessary (probability and loss weighted across the population) to justify the massively higher costs of development?
You can blab and whine all you want about complexity. Then you gotta explain why, since Word 95, there's been an issue with Section Breaks spontaneously changing type, and causing page numbering problems.
Still exists in Word 2003.
Countless usenet posts exist describing the anguish of VBA programmers when they encounter this bug, classify the behavior, report it to Microsoft, find out it's been a known issue for over 9 years, with no plan to fix it.
That's not caused by complexity. That's caused by bad management. Folks with no conscience. No pride in their work.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
We all know how to track down bugs in Microsoft programs... you use them! hey hey!
I think they meant in the code... that part's probably harder. Cause you have to not disturb any of the OTHER bugs in there! HEY HEY!
stuff |
Spoken like a true Linux developer/maintainer. "It's true that not being able to reproduce makes finding a bug much harder but it's not impossible." Umm, how do you do adequate quality control if you can't replicate the bug, then test the fix? What? "...add some diagnostic code..." I thought all Linux software already had all the diagnostic code in it, that's what quite a few other posters are saying. "If it happened just once, often we cant fix it but then it's not that important..." OMG, I love it when the IT department makes an independent, unilateral decision that a one-time error isn't important. So if a one-time bug destroys a database, who cares, right? "...then we can usually fix it given enough time to work on it..." Isn't that the idea behind Rick's article, eventually most bugs get fixed, wasn't he just being honest?
He mentions that the Mac version of the bug finally gut quashed due to the superior diagnostic tools on OS X. Let me guess: 'strace' ? LOL
The other hilarious aspect is that it took them a few years to figure out that if they set Word's internal open-file limit to something smaller than the OS open-file limit then Word would be able to flush some files before encountering an OS error! It is pretty obvious that (even back then) nobody really understood how the software works, or how application software should interact with the OS.
I can't remember the guy's name but I do remember what the head of marketing for one of my past employers once said...
All software has bugs. If it doesn't have bugs, then it isn't software.
Once you tie Word down, hold a knife to its throat and say "No. Really. I know what I'm doing -- back off," it's really quite good.
It's not an issue of bugs, it's an issue of features turned on by default. Unfortunately (as I said above), you need to call off the dogs in about 100 different places before Word becomes really good.
Cretin - a powerful and flexible CD reencoder
This should be marked +1, Insightful. You only think you're being funny. But when a bug affects every one of your installed customers -- such as a security bug or a major feature change -- you had better be damned sure that you fix it completely and that the fix does not break behavior that third parties have come to expect.
Take this Active X thing. Do you realize how many essential web components, many of them from companies that are now out of business, would stop working if ActiveX were turned off altogether? Many, many websites would stop working, and you can bet the people running them would blame Microsoft. Poor security doesn't cost you anywhere NEAR as much as losing ISVs would. So you spend a lot of time planning, reviewing and executing the patch, and equal time testing it.
But bugs in trivial features? Shit nobody uses or really cares about? You can fix that really quickly, because if the fix is still broken, it won't make much of a difference. You don't need a tiger team or testers working late hours. You can put a single intern on it and get it "done" in an hour.
It's a matter of caution, not priority. When the potential fix affects the core of your business, you move slower fixing it. You release work arounds while you're planning and testing. And you slowly roll out the repairs.
Hey freaks: now you're ju
For starters, if you're writing long tech papers, you should probably be looking into LaTeX.
Using the correct tool for the job is often a good idea.
So, do you never user bullets, alter tables' sizes, change a region's font, change regions to bold/italic/etc, or paste from other applications?
For me, about 1 time in 20 I use them, the last bullet is in a different style/size than the others, the table suddenly takes up the width of the entire page and even forces the page into landscape, the whole region becomes Times New Roman, the whole region becomes size 2, and the document's margins disappear, respectively (and actually widening a table has caused the document's margins to disappear, also).
I'm sure OOo has these problems too; I've given up on WYSIWYG document editors entirely and now write my papers in ascii and mark them up in TeX.
All's true that is mistrusted
Sorry, I couldn't resist. God knows these kinds of things can be tricky. You just carefully track down the root cause of the problem, and fix it structurally, right? Let's see:
So, um, no structural fix? Just local band aids to stop the bleeding? I suppose... that would work... If your program is so big and fragile that anything but the simplest fix might introduce a whole boatload of unknown problems... Yes, that's a common problem with closed source software. What would also have helped is a more meaningful error message. Why show a "Disk full" message when the file descriptor table is full? It would certainly be nice if Word was a bit more predictable. Maybe the complexity has something to with it.Ah, forget it. Probably just a philosophical quagmire.
Exactly! Making things modular, and limited to single operations with no side effects, allows you think about how they interact far more easily, in no small part because it makes the actual interactions fewer.
Read The Art Of Unix Programming, particularly the chapter on compactness and orthogonality, to fully understand this.
PHEM - party like it's 1997-2003!
"Great, but the percentage you gave is actually seven nines."
I count 5 after the decimal point. I guess I have to be really really really really exact ('Exact' meaning I have to spell out every detail as to avoid confusion caused by lack of common sense)about the phrasing of every single sentence I write ('phrasing' meaning I had better not leave any possibility for mis-interpretation open) every single time I post something on Slashdot (using only numbers, letters, and punctuation because images aren't allowed) or nobody (by nobody I mean there isn't a single person reading Slashdot, there may be others that don't read Slashdot that would be exempt from my generalization) be able to interpret it. ('it' meaning every single time I post using letters, numbers, and punctuation.) Otherwise ('otherwise' meaning 'in every single case that isn't included by the terms defined earlier in this post) nobody ('nobody' meaning of every single person reading this post, exactly 0 of them would be exempt from the following generalization)
There. Now my post should be perfectly clear to those who are common sense impaired.
"Derp de derp."
Okay I'll bite. Here's a fantastic excuse for using ActiveX: every one of your customers will be using Windows with Internet Explorer anyway, and you want to quickly develop a program that will permit them to locally control their machine without having to download and install software.
Java won't cut it (security models vary too greatly). Flash won't cut it (no access to local libraries). Only ActiveX will do. I know entire software suites in the $1000+ range that rely on ActiveX's "security flaws" for proper operation. I would never buy one of these, but I also wouldn't want to be told that software I purchased is no longer usable because of a security patch. I've been told that in the past (an old Bently automotive manual that no longer works due to Java "security enhancements" that make it unable to start) and it sucked. It wasn't my decision to use the technology...I shouldn't be punished because of someone else's technology choice.
I dont' like Active X. I don't even like this kind of website. But for many developers in the intranet services market, it's a godsend. Rapid development and a trustworthy, no-obtrusive, support free platform. Basically, all the same reasons it's used to spread spyware and viruses.
Hey freaks: now you're ju
What about a meaningful error message? Of course they couldn't find the bug with the message "Disk full" if the problem was the number of open files.
Maybe this seems trivial to you, but I think most of us when designing a document format would try to put "The" before "dog", by instinct. It makes sense.
In an output format, perhaps. It's a good idea. However, you're not thinking about it properly, from a programmer's perpective.
Writing a text editor is actually quite hard, mostly because the text is not static. You can't just parse through the loaded text once, you have to keep it in memory and allow edits to it efficiently.
When writing editing software (such as vi, etc.), we programmers all thought the obvious answer was a "line table". A list of pointers to each line of text in the file. Each line is independently allocated. That way, a user can enter new text on the line, add, delete, etc., and we don't have to make a complete copy of all lines that follow it and shift them up/down in memory.
Likewise, scrolling is easy. Does the screen show lines 1250-1280? Just go to offset 1250 in the line table and get the next 30 line pointers, then render each line. You don't need to parse through then entire file to find each line.
When we moved from character-terminal line editing to wysiwyg, there's not much different, except the line table is no longer fixed to lines, but it's kind of random. It could be paragraphs, lines, pages, or a mix of all as the document gets cut-and-pasted about. Cut and paste within the document is just a case of splitting the lines on the selection borders and re-building the line table. You don't need to copy the actual text selection.
Finally, when you save to disk, you have two options:
1) Just make a nasty raw memory-dump or a fixed-up memory-dump, so it's quick to load back in. This is what Word does (or did).
2) Actually go through your document and generate a structured, easily parsable format without any of your internal gubbins. That makes loading and saving harder, but interoperability much easier.
So, because Word just makes a dump of its internal editing structures, they appear in the output format. Both having editing structures and just naively dumping your workspace to disk is very "trivial" and "obvious" to programmers.
No, but you could at least be correct. "Five nines" is an accepted term industry wide meaning "99.999%". It's not a matter of common sense, common sense tells us why you screwed up, you simply misunderstood "five nines" as meaning fives nines after the decimal and not five nines total. Just because "common sense" let us figure out what you really meant doesn't make you less wrong. If I write something like "Your going to install Office?" people know I meant "you're" rather than "your" but it doesn't make me correct. It was not a large or important mistake so launching an involved rant to cover up a minor mistake is really rather childish.
And that folks, is how we have arrived at the mess in the U.S. we have today.
You are being MICROattacked, from various angles, in a SOFT manner.
The only way you can "prove" your program is correct is by mangling the specification one way or another.
Absolutely not... By the tone of your post I'm not sure if you don't understand or are bitter.
There are inputs, there are outputs. Inputs are clearly defined, outputs are clearly defined. The 'program' translates inputs to outputs. Pretty simple, eh?! In the most basic program inputs are verified, parsed/analysed, and a product is created. If it sounds simple that's because it is.
You rightly state Specifications should be kept simple so customers and developers can both understand them and easily talk about them. Absolutely so. As developers we exist to solve a problem or solve someone else's problem (/improve the solution). Something is presented to us and we find a neat way to do it - the technicalities in doing this shouldn't feature to the customer, if they do the customer has become a project manager (manager rather than steerer) and the ball games changes somewhat. Effective communication between customer consists:
--
Customer: I want to do X
Developer: What exactly is X? Do you have a way to do this presently you are happy/unhappy with? Do you need something improving? Do you have a fixed methodological framework/ do you need a new methodolical framework set out? Do you have a strict series of inputs or are you looking to be flexible with this?
Customer: Yes/no/something
Developer: I can do that for $$$ in ttt time.
--
Developer was a stretch, more like a consultant, but consultants and developers work together, consultants getting in implementing specs, developers fed by consultants. Your point... "The only way you can "prove" your program is correct is by mangling the specification one way or another" is absolutely false... inputs are finite and outputs are finite... given inputs outputs can always be proved to be correct (according ti the specification).
"Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do." We work to minimize the bugs in the software we ship, but they'll always be there.[emphasis mine]
And Microsoft thinks they're ready for the Enterprise Market....
I did RTFA. I'm trying hard not to flame, but this guy is a downright pathetic programmer. I've fixed more complicated bugs in the last week than this. And his defense - Word is complicated - just doesn't cut it:
There used to be a time when programmers were more professional.
Quite frankly, I hate to see this attitude in programmers. If you are charging for the code you write, you should at least have the professionalism to fully debug it before release. Your customers deserve better than to have your software ruin their business.
The society for a thought-free internet welcomes you.
Pull any random Slashdot page or anit-microsoft trade rag or Usenet post and you'll see it for any KDE, GNOME, OO and kernel release for the past five or six years.
You know, just because you say it doesn't make it so. I can name at least a dozen companies that make web controls using Active X that do very, very well, because customers LOVE not having to jump through hoops. Whip out a brand new machine, connect to the intranet, and boom! It works. People like that, and good administrators find ways to support what people like. I used to have to use an ActiveX client for Test Director, because the per-seat license was way cheaper on that then on the desktop client. It was obnoxious sometimes, but great when it came to interfacing with OLE...drag and drop formatted text, files, etc.
Stop assuming nobody will stand for idiot friendly software when plenty of people are using it already. Yes it's a bad idea, but that doesn't mean that we can just ignore it. If I ignored all the bad ideas other people had for our program...well, it still wouldn't be working.
Hey freaks: now you're ju
If you can't accomplish the task with DHTML/JavaScript, then you need to find another way.
And inevitably, some web designer who's even more hardcore than you will say that you should hang yourself with CAT5 cable if your website uses any kind of HTML that Lynx can't render...
Eventually you will have to draw a line somewhere and realize that there is basically no way to make a modern website/web application that won't exclude some amount of the web browsing world. There's plenty of "standard" features that aren't cross-platform due simply to the fact that certain browsers haven't implemented the feature. When you consider that roughly 90% of your audience can use ActiveX that certainly makes ActiveX "compatible enough" to be suitable for web purposes.
Well, I have a several thousand line codebase and I often have bugs I can't fix, usually because the bug report is something like "checkbox still checked after closing window."
I go in, look at the usual suspects (checkbox code, window code, population code, database code, event handling code), try and reproduce the problem...but sometimes, the difficulty isn't with the code or the database...it's with some unexpected relationship which will only be set with certain workflows.
This is a problem which I think is unique to heavily object oriented applications relying on dynamic relationships, such as performing arbitrary actions in a word document. With an OS kernel, you have much more procedural code with much more control over state and hopefully fewer cascading relationships. But what do I know.
Hey freaks: now you're ju
And inevitably, some web designer who's even more hardcore than you will say that you should hang yourself with CAT5 cable if your website uses any kind of HTML that Lynx can't render...
Not lynx, it doesn't do tables, which are quite useful, but I've for a long time been of the opinion that the majority of websites have no excuse if they don't show up in links. Stuff like popup menus, tab navigation and hover effects can be done with CSS in a cross-browser way that degrades gracefully on older/simpler browsers and integrates nicely with browsers for the blind. What I could conceivably see people need IE-only code for is in-page rich text editing (afaik there's no W3C mechanism for that yet) or complex real-time data layout controls like grids and charts. But your average, run-of-the-mill website really has no excuse to be running IE-only code.
The future of the web is not in jazzy code that will only work on one browser, one OS and one hardware platform. It is code that will degrade gracefully and is not tied to any specific style of output device so it runs agreeably on any platform. The W3C model is WAY better suited for that than anything coming out of redmond.
But if you look at a Word document's innards, the text is inserted pretty much in the order you typed it, including text for substructures such as textbox contents, bullet lists, or footnotes; then formatting is applied by way of a remote pointer. That's why formatting tends to be hard to get to "stick" in these substructures.
OTOH, WordPerfect actually does handle such substructures as if they are independent documents within the same file, each with its own independent formatting, rather than the formatting being tied to a location like with substructures in Word documents.
~REZ~ #43301. Who'd fake being me anyway?
Presumably, in the case where Mac OS ran out of file descriptors, it returned the error tmfoErr instead of dskFulErr. I guess we've all been in the situation where we don't enumerate all the possible things that could go wrong with a file operation.
I'm guessing, whoever wrote the file handling code used something along the lines of:
OSErr err = FSOpen(...
if(err != noErr) ThrowError("Disk Full...")
All of us could have done that sort of thing. However, it is incredible to me that it would take months/years to track down a bug like this. I've often needed to debug things without a debugger, and while it is annoying it can be done.
The author seems to be really attached to his debugger. He should learn to use the printf() the most powerful debugging tool ever devised.
The key problem is expressed in very few words
The statement you quote is generically correct. I conclude based on my read of the entry that the developer is "over his head". He, and many like him, have a dependence on elaborate debugging tools and often claim that without these tools they are unable to fix problems. He already has sufficient diagnostic tools available to him and he either doesn't know about them or they've been obscured by bad code.
By design, Word will open an infinite number of files (this implements so called unlimited undo.) This is crap design. Damn near every OS in existence imposes some limit on open files. Even if there is no "built in" arbitrary limit provided by the OS, RAM will eventually be exhausted just keeping track of open files. Whoever failed to consider this is the origin of the problem; everything that has happened since is his/her fault.
Now, discovering that there are limits to open files is what the blog entry was about. The first clue eventually appeared only after someone managed to reproduce the problem in a debugger. This took a long time. Also, the altered state of running the app inside the debugger further obfuscated the problem (read the blog entry.) Perhaps it would have taken less time if simpler tools had been used...
One can easily observe OS resource usage of a running application without elaborate debugging environments. Some OSes make this easier than others. The blog entry author recalls a moment when a discovery was made by someone else using "some tools" in OS-X. He doesn't specify what these tools are. He probably doesn't know (due to abject dependence on his debugger.) In Linux I can observe file handle usage with tools that include ls and cat. In Windows I could use Sysinternals Process Explorer (a non-microsoft tool, btw) to do the same thing.
Simple observation of open files using non-debugging environment tools might have led someone to ask; "Why is Word attempting to hold <<insert large number>> files open...?"
Further, the error message displayed by Word; "Disk full." indicates another sad failure. The disk wasn't full at all. It is my guess that Word uses some generic catch-all whenever a file system operation fails. Can't write to a file? Disk Full. Can't open a file? Disk Full. etc, etc. The catch-all manages to isolate a subset of possible causes and dumps the rest into "Disk full".
Type "man open" into the shell of any POSIX like system that provides manual pages. Look for ENFILE. This is the error code you will see if you write a program, like Word, that opens too many files. If you then have your program display an accurate error message, whoever ends up maintaining your little miracle will spend fewer months fixing it. I've no doubt Windows API provides similar.
Bad design, bad coding and low-skill maintainers. Thus mickysoft.
Maw! Fire up the karma burner!
Nice article but author never mentioned another very important bug that would have save a lot of time: Correct error message. Why was Word saying 'Disk Full' when the error was 'Too many open files'..
I'm with you man.
The incompetent's vs. the professionals.
I've given up on Microsoft.
I've finally come to the conclusion that the problem is me.
I will NEVER be happy with this level of incompetence.
I've had to move to OS X.
Now, I can enjoy life and my computer again.
( And I'm not joking. )
After a certain point you have to realize that you have to move your personal data off Microsoft: Mac OS X.
And your business off Windows: A high quality Unix:
Sun or IBM.
- How many YEARS was it before a Microsoft Tester actually attempted to Stress Test the application? Sheesh.
- Architectural problems don't get fixed?
Did Microsoft forget about NEW RELEASES?
- Don't they already have a set of AUTOMATED test scripts?!?!
Question: Is Redmond the PotHead capitol of the USA?
- Why do they have this attitude that they can avoid REALLY HARD WORK?
OK, I may have misspoken. The principle beef I have with OO in this area is that, as I recall (it's been about a year), I can't count the words in a highlighted selection without using a "hack-job macro". The last version of OO I used also lacked a means of counting words by using keyboard commands, which I also really, really appreciate while writing papers (Alt-T-W in Word).
I agree (I last experiemented with OO in KDE as well), and I also have no idea which is truly to blame.
Though, to be fair to OO.org on loading times, I believe Office preloads some things on start up, like IE does, to give the illusion of a faster load time.
As I understand it, it's a Windows startup folder shortcut that is added by default with an Office install ("Office Startup"). I have long removed this "feature," and Word still takes no more than two seconds to open. I believe that's what you're referring to.
I attempted to use OO with an open mind, as I attempt with any new piece of software, but it just didn't perform. With the exception of the word count and page numbering (the latter being my bigger peeve), it's just personal preference.
The lowdown: the advantage to OO.org is really the price, which can't be beat. And since it works pretty well, there's also some value there, as well.
I guess my bottom line is that Office amortizes well for me. The fact that Word97 still, again, in my opinion, performs better than the 2004 version of OO means that my investment years ago is still worthwhile.
-
Inventor of the term 'pardon my French'.
I find this odd - when dreamweaver first came out, one of it's primary selling points was that you could do your WYSIWYG editing in one pane, and switch to another pane to go straight into editing the HTML - something us old hats absolutely loved and was the reason we bought/stole/paid attention to the program in the first place.
Now it has all this extra crap in the program, and the last document that I got that was purely generated in dreamweaver that I had to reformat for some HTML jockey was total rubbish - no indentation, missing closing tags, I could go on.
What happened?
I was hoping to post this on the blog instead of here. Unfortunately comments have been closed. My hope is to isolate some key mistakes that could have gone a long way to preventing this problem from taking so long to address, or perhaps ever happening.
// KB #123456 - "Disk is Full" Open FH bug
Granted I am judging from his description of how the system works and was assembled from scratch, but especially in reference to the multi-undo system, it was fairly obvious that the problem had absolutely nothing to do with the oversight of the developer regarding the open file limit, because the system was too complex to begin with.
Since (I hope) it's obvious that undo in an editor is such a unique and fundamental problem - a new pattern or a new assembly of smaller patterns needs to be applied to specifically address the undo issue. What I saw was a very typical problem in large and growing development environments, applying crow bar logic to implementing new solutions.
Proper use of exception handling and event-driven programming would have fixed the open file problem by itself, at least in my admittedly limited view. Instead of printing "Disk is full", the class exception or the file event itself could have caused a unique error to be printed with that information to aid the QA and developers. And of course, descriptive text for the user.
The second thing, Microsoft has this enormous knowledge base, would it have been too hard to do this in front of the 2 lines of code?
Since this bug had already been fixed and (hopefully) entered into the KB, the developer of the Mac fork (which I'll address in a minute) not only had a place to start, but a simple grep (or the MS equivalent) would have solved this problem in short order. I suspect if this pattern is not already adopted, it would fix a TON of these communication problems (which is really what this consists of), and code review would enforce that comments like these were injected on each bug fix. If they don't want to comment it (as many small bugs would prove prohibitive), properly address this in your CASE tool of choice.
Forks are ALWAYS bad in closed software development. If you have to fork your code, you have definitely done something wrong. I don't care how much system-specific code there is, it can be abstracted in almost any language - and a company like Microsoft which not only creates the applications but the development tools as well has no real excuse.
I know, a lot of this is "woulda coulda shoulda" stuff. Both Experienced and Novice developers and management have made these mistakes before, and it won't change anytime soon. Release pressures can really warp the logic of any member of the team - the "Get it out yesterday" school of logic rarely does any good in the long-term.
Two points:
1) Try LyX, it brings WYSIWYG to LaTeX, mostly.
2) When writing, you should be concerned about the content and the structure, and that's it. Leave sorting out how it looks till later. It makes one messily-tied-together task (working with layout and content) into two cleanly separated tasks.
If you are using Emacs, you can open the xdvi from within its LaTeX-mode and place it next to the editor window, and then just have Emacs scheduled to run latex on the document every, say, ten seconds. The changes will automatically update on xdvi.
But, as the other poster wrote, you should be paying more attention to structure than presentation.