r_harvey| Requiem for a lens | Elspeth And Twigg | Books | Engineers | A little mouse bug | A CD-R in the window | Vicuna Frittata | Worms and Viruses | Software cracking | HLT! Who wastes there? | The 64-bit excess | Out-of-Time-line | Get licensed. Get legal. | You're A Star | Renting Your Data | But It Worked Yesterday | The Price of... | We use... | Escape from MASM | The Packaging is the Medium | The Process is the Medium | Product Names | Home page
r_harvey
A few informal thoughts.
It's been tough getting started today. Maybe the problem is that I'm in mourning. My favorite lens of all time, one I've known since 1980, has some tiny metal flakes inside, resting on one of those precious glass elements. The lens still works--it has never failed me--but I'm sure the focusing helicoid is quite worn, and some light is blocked by those tiny dots.
I remember meeting this lens... saved up the cash and walked into Reseda Photo in the San Fernando Valley. A long wall was covered with new lenses in boxes. This was one of the first few of that model, made in the New FD lens mount. For all of these years, if I've traveled light, carrying just a camera and one lens, this has been the lens. Focussing has always been slightly stiff, but it has never been scratchy... but now I can imagine that it is and must have been, and if I had listened carefully for it, the metal flakes might never have happened.
It's truly a wonderful lens; always receiving Excellent or Outstanding or A+ or 72+ in reviews. This lens has been sitting on the desk most of the time while I've been writing a book; the camera is mentioned by name in the book, but this lens only in spirit. My great and dependable friend... the Canon New FD 50mm f/3.5 Macro.
I'm writing a book. Another one, actually, and at the same time as another one or two. The new one's called Elspeth And Twigg, and it's an experiment in an episodic tale that will be posted, one part at a time, on the home page. Perhaps it will eventually move to a blog-like Web site. It's a warm tale of friends getting along, and who just happen to be animals, and just happen to live in the woods.
How can we possibly write something like that, and reveal just a bit at a time, and not make it slow moving, and not make it sound like it's just for children, and give it some sort of artistic value? And how do we show a whole book online, without asking for readers to wait while a huge file downloads, just so they can read a thousand new words at the end of it? I guess we will find out together.
I suppose it's doomed from the start to sound like a hundred other books about animals that live in the woods. Most animals do, you know. It would be like complaining about a story sounding derivative because it's about people who live in the city. It has to be different because while they are cute (most animals are, you know), they live real lives, with pain and predators--which is also true about people in the city.
Another goal is to see how hard it is to write long-form using a mark-up language. I'm doing this book in HTML, with symbols and quotes entered manually with codes, in a plain text editor that highlights keywords. More than a year ago, when I started another long book of fiction, I wanted to use LaTeX, but I was concerned that it would be very hard to do creative writing in two languages at the same time--so far, with HTML and this new book, it looks like I was right.
I selected MS Word for the other book, because of familiarity and because of good performance when working with large documents (other word processors I tried bogged-down with huge files). Only having to write in English, without any concern for how the text looks or how to enter quotation marks or accented characters, makes it easier to concentrate on the rules of the story and of English, which are quite enough for me.
I'm also updating HTMLcat, which uses MS Word with embedded mark-up codes and extensive calls to custom functions written in C or Assembly language. So, HTMLcat uses WordBasic macros, the help viewer's embeded mark-up language, C and Assembly, and the setup program's mark-up language, and to top it off, the book is all about HTML, CSS and JavaScript. I think too much of the creative process is sucked-away by getting unnecessarily involved in the methods used. Sometimes it's amazing when it all works. Sometimes it doesn't work, but it's still amazing.
It's such an odd business.
Fiction books, that is. Looking at it from the inside, there are so many duffers and ego-freaks and people with personal stories, who keep annoying you with unedited drivel. Every six months, they surely send it all again. You can't help but come up with some wall of defense. Sure you miss a few gems, but if the writer has enough drive and some convictions or something, they will eventually get through--or not, but it's survival of the fittest.
Requirements for manuscript submissions are outdated and dopey, in today's world. Give them the whole thing, or two sample chapters, or twenty pages, or just a synopsis plus pull quotes... or don't. One-inch margins for these people, one and a quarter for others; print it in Courier for here, or Times Roman for there. Turn italic into underlines... or don't. Make it single or double or one and a half spaced, depending on the... well, I don't know what it depends on.
Sure the requirements do make the author invest more into it before sending it to you--which helps qualify their intentions and commitment--but it slows the process. Instead of wanting a daunting stack of manuscripts in front of them, they should ask for PDF or DOC file. You can tell on-screen in just a few minutes if there is any merit to a book; only then should you even consider sitting through the whole thing.
If you want to qualify the author's intentions, require them to do ten hours of community service before you'll read their submissions--it'll do more good for the community, and it'll give the writer some exercise.
Look at the odd little books that do get published, just because the author knows someone or is someone. Thousands of little titles would've been ignored had the writer not been a recognizable name--probably for the better.
Getting that name--or connections who have names--is a different skill than writing the stuff; I don't have the confidence or aggressiveness or social skills to make good connections.
What an odd business. I guess it's a crapshoot. It's like movies, where they think the audience is fickle, and they just throw packages out there and hope to win. It's truly odd that they put up great barriers to entry, and yet they are surprised that the stuff that does get through, doesn't sell.
The problem for someone like me is if I find an outfit that will just throw it out there on a whim, they will also be as likely to abandon it if there is a weak opening. I can imagine thousands of copies left sitting in a warehouse, when the 27-year-old executive has lost faith in it.
Oh, there is a point to this rant; there are several, I suppose.
In the '80s, I belonged to an HP calculator users' group. All of those engineers dressed like Dilbert, wore multi-function wristwatches, and carried Swiss Army knives. One HP calculator meeting started early (of course), and at 9 p.m., their wristwatches all beeped precisely on the hour.
Two minutes later, another watch beeped. The meeting stopped, everyone looked at that guy like he must be from another planet (Earth, most likely). The guy was treated with disdain for the rest of the evening.
Luckily I didn't have a watch... or they'd have known that I was a spy.
Engineers wear belts, sensible shoes, and white socks. I've heard them discussing socks; each one agreed that when they find a pair they like, they buy forty more pair exactly the same, so they don't have to think about it for a few years.
A very intelligent, left-brainer, engineer friend has (I am not kidding) memorized logarithm tables. He can't tell you the color of his house, but he can do square roots in his head. He told me what he thought was an amazing story:
"My girlfriend left her keys on the kitchen table. I wanted to set the table for dinner, so I moved the keys to the hall table. I told her that I had moved the keys, and she simply said "okay." It was like she had a little picture of it in her head--she could move the keys in her head, and her memory would be updated... just-like-that! It's bizarre!"
After the story, I tried to explain visualization; it didn't work. I said "Imagine a picture of a tree..." and he stopped me right-there. He didn't want anything to do with that black-magic, occult stuff. They're a different breed.
About fifteen years ago I participated in a Microsoft beta test. I noticed that if you moved the mouse while the mouse software was loading, the computer would crash. I reported the bug; they fixed it. Another beta test came around with another new mouse driver; the mouse-moving bug returned; I reported it; they fixed it again. I hadn't been on a Microsoft beta that included mouse software for a couple of years, so when the Chicago (Windows 95) beta came around, I was surprised to see the mouse bug back; they fixed it again. Other problems follow the same pattern. I've been trying to figure out why improvements are so slow to come.
It's an aggressive, confrontational atmosphere, where fixing things is relegated to rookies, implementing new features is done by sophomores, designating changes is done by marketing, and denial is managed from the top. Production code is done at the bottom, in the trenches, with an endless stream of young workers learning the processes anew, and doing the same things time and again, while gasping for air and treading water; this is evidenced by previously-fixed bugs returning after upgrades, and recurring sophomoric mistakes.
It's a tough culture; many quality programmers burn out, sensitive artist-type programmers quit, and the most aggressive are promoted out of the trenches--
By the time programmers go through the trials necessary to learn the craft (and make no mistake about this: it takes several years), they are no longer working as programmers. Dedicated but non-aggressive employees count the days until they can quit the rat-race and open a bakery.
In a culture like that, the same problems come back, again and again. No growth, no maturity model, never truly ready. Again and again.
There is not a culture of long-term interest in projects, where you would have integrity or personal desire--perhaps selfishly or to bolster your own ego--to make them as good as possible. What they do and how they work shouldn't matter to us, the computer users.
This is the point where I offer a solution for us, the users. I don't have one.
In version 1.0 of his mural of the Last Supper, Leonardo DiVinci, always the innovator, mixed his pigments with walnut oil. From an artist's point of view, walnut oil is much preferable to linseed oil: it smells better, is easier to use, and it has little effect on the color. Unfortunately, it also has a tendency to turn rancid or sag, long before it ever dries. It's a terrible thing for an artist to see his work disintegrate in his own lifetime... it's even worse when it happens next Tuesday.
Leonardo scrubbed the walls clean and started again. Version 2.0 used conventional techniques. Artists and scientists are now wary of the quality, consistency and stability of pigments and dyes, as well as the canvas itself.
CD-R discs aren't real CD-ROMs. We write to CD-R by using a laser to rearrange the molecules on a layer of dye, while a real CD-ROM has valleys fabricated in the foil layer. The effect is much the same, since laser light is refracted when the disc is read. Dyes, especially red, and especially those exposed to light or heat, fade.
I've heard that if you leave a CD-R face-up on your desk over the weekend, by Monday it'll be unreadable. It's a terrible thing to see your work fade. However, dyes used in CD-R must be tolerant of high-temperature laser, and they're about as far from red as you can get; most cyan-
I took a fourteen-cent bulk CD-R, recorded 700MB of data, and placed it shiny side up on a South-
Someday soon, the inexpensive drive won't be able to read the disc. The lesson learned so far is that you can leave a disc on your desk over the weekend.
If you want your art to outlive you, store it on a high-
Update: The test is done. Finally, after three months of Arizona summer on the window sill, the CD is unreadable by the innexpensive drive (a LiteOn). But it's still readable by the quality drive (Yamaha). The disc's surface is scratched from dust-bunny attacks. The half of the disc that had faced the sun is markedly faded.
Update: Here it is a few years later, and some of those fourteen-cent CD-R discs are failing, even some that were recorded then stored in the dark and rarely used.
What was the song from that Disney feature? You know, the one with all the merchandising and stuffed animals and fast-
What was that song? Come to think of it, what was that movie? Oh well, maybe they'll release it again. Or another one just like it.
I've seen a flood of e-mail worms/viruses lately. Each one represents someone whose life and work have been disrupted--
As much as I appreciate beautiful text and pictures, I accept e-mail only as plain-text. I never accept or send unsolicited binary attachments. And I've never been hurt by a worm or virus.
Every worm/virus looks different and they're all different file sizes. They often have a comma before or after your name in the To: section (the people who write these things are, after all, immature children, so you can't expect them to be able to parse a name correctly). It doesn't take much to spot these things: look for a big attachment that you didn't expect, then throw it away, even if it's from somebody you know. Don't read it. Don't try to look at the pretty picture show. Trash it. Please.
It's disheartening to see that a customer had first tried to find a stolen copy of your product, before reluctantly purchasing it. That has happened to me.
HTMLcat 4 was never cracked, even though many tried.
Sophisticated techniques cost hundreds of hours of development time. Yet they help it sell no more copies, and stop no one from stealing. The time would be better invested adding features to the product. So while we haven't ignored security, we have emphasized features for the user, not the cracker.
HTMLcat 5 is due soon (as of this writing). It's much larger and more complex, but with less advanced security. The DLL is now written in C/C++; you could get a good look at much of it with a disassembler -- it was written for the user, not for the cracker. We put that time to better use by adding ten-times the functionality to the DLL. Time is now invested in making the product more useful, instead of engaging crackers in their games.
Honest users suffer through complex installation and fussy registration processes because 31337 crackers and warez fans are just having fun.
You are throwing away electricity just by running your computer. Intel-compatible processors built since the early '90s or so have included a little-known instruction: HLT. This instruction stops the CPU until something happens, such as mouse movement or clock tick. While napping, the CPU consumes very little electricity. A typical processor could take a 27-million Hz nap between clock ticks.
Microsoft Windows spends most of its time sitting around waiting for something to happen. Most of the time, nothing happens -- yet the operating system does not use the HLT instruction. Between keystrokes and mouse-clicks, there's little to do but wait. They are wasting your electricity.
Microsoft Windows offers a few tools to power-down peripherals after you've been away from your computer for a half hour, but nothing to help throughout the day. Unfortunately, constantly turning on and off components like hard drives and monitors, prematurely wears them out.
We need real-time power conservation.
Take an AMD K6-2 processor running at 500MHz; it's not a very thermally-efficient processor, but it's typical of a few years ago. Running flat-out, this CPU consumes about 31-watts, and idles at about 19-watts; let's average that to 25-watts. In a business, that's over a kilowatt hour (KWh) per week. If the operating system used the HLT instruction, this processor would average about 7-watts, and save about 0.72KWh per week. If we changed 200-million similar computers to use HLT, we could save 144 million KWh per week.
Most of these kilowatt hours are converted to heat. In warm climates, it takes at least two watts to remove one watt of heat. (in one test of this CPU, using HLT reduced the case exhaust temperature by 2.5 degrees.) With at least 200 million KWh per week -- at just $0.25 per KWh, we are wasting $2.6 billion per year.
It's getting worse: the typical CPU now needs 40-60 watts.
There should be no difference in the electrical efficiency of desktop and portable computers. It would cost little to change the idle loop in Microsoft Windows to conserve more power -- certainly less than $2.6 billion.
Another step is to move the world from CRT monitors to LCD displays. As the price difference slips to little more than the cost of the electricity saved over three years (about 400 KWh) the CRT is becoming history.
September 14, 2000 will be remembered as the day MS-DOS died (Windows ME was released, without support for MS-DOS mode). Here are other milestones:
January 1, 2001:
Microsoft no longer provides support for the following programs: Windows 95, Windows 98, Office 95, Office 97.
January 1, 2002:
Windows 1.x through 3.x, and Windows for Workgroups, and DOS versions through 6.22 are gone.
June 30, 2003
Windows NT 4 Workstation and Windows 98SE are stricken from the records.
64-bits is the answer. The Jeopardy question is: "How can you double performance without improving it?"
Moving computers from 16- to 32-bits was wonderful. I believe it was a significant contributor to the country's economic growth in the '90s. Really, I do. Now we're moving to 64-bits -- disk file systems are there now, in order to recognize drive sizes larger than 4GB.
Every bit you add to a binary number, you double the maximum value it can represent; for instance, a 16-bit (signed) number can represent numbers up to 32,767, but if you move to just 17-bits, you can represent 65,535. Moving to 32-bits increases the (again, signed) maximum value to 2,147,483,647, which is two-billion. This was a huge number a few years ago, but now it's not large enough to represent a typical hard drive size. Again, moving to just 33-bits, we get four-billion, and 34-bits is eight-billion. However, engineers reasoned that since we moved directly from 8- to 16-bits, then from 16- to 32-bits, it must be time to move from 32- to 64-bits.
That's 9,223,372,036,854,775,807, which is nine-quintillion. I'd like to draw an analogy to help put that number in perspective, but I've no clue just how big a stack of nine-quintillion of anything would be. Whatever the thing is, I'm sure nobody needs quintillions of them.
There are two separate bittedness values that are often confused (probably because of sloppy C programming practices):
These are two separate units (or they should be). When programs are recompiled for 64-bits, the size of pointers doubles -- and the amount of compiled code required to represent those pointers doubles. We don't see it in use, but pointers are a major chunk of compiled program code. If nothing else changes, the program size will increase by 20-50 percent, which means in order to maintain the same performance, disk transfer speed (to load the program) will have to increase. Once the program is loaded, memory access speed, the time it takes to load an instruction from main memory into the CPU, must increase proportionally. Increasing performance beyond the 32-bit level will be difficult, because 64-bit programs begin with a natural performance disadvantage.
We do need 64-bit values today, to represent high-precision floating point numbers -- or a numbered list of everthing that ever was. We will one day need huge pointer values, such as to represent every byte in a virtual copy of the Library of Congress. For the next half-decade or so, I doubt that most of us will see hard drives as large as a terabyte, which can be represented by 40-bits. We may never see truly gigantic hard drives, because other kinds of non-volatile storage will prove more practical and reliable.
Programs written without hard-coded assumptions about the size of a pointer can work in 32-, 48-, or 64-bit environments, without concern that our grandiose dreams exceed the hardware's ability, or the user's budget.
48-bits is a brilliant stop-gap, one that should serve the desktop user for years -- until everyone decides to carry a bitmap image of the surface of the entire planet in a shirt pocket. I like 48-bits. It's good-enough for 256-terabytes, or about 32,000 full-length movies. I often use 48-bit integers to get a little more range than 32-bit integers, but not quite the overhead of 64-bit integers. And 140,737,488,355,327 of anything still makes a pretty big mound.
Note: After writing this, I noticed that the proposed ATA/ATAPI-6 hard drive specification will likely use 48-bits. See the Maxtor White Paper. AMD's next-
The Business Software Alliance is targeting your city.
Get compliant before they target you.
A postcard from Microsoft began with "Heads up. The Business Software Alliance (BSA™) is targeting organizations in your area..." to remind me again why I'm reconsidering my software purchase and use patterns. Click to see the postcard.
Is it the $150,000, or are they trying to discourage small companies from using their products? I'm just not sure. What do you think they're saying?
Update: Before this card was a letter; they've continued since this card, but so far no registered mail.
BSA is a trademark or registered trademark of The Boy Scouts of America.
"Captain we're nearing `The Johnson's Beloved Schnauzer Skippy' in the Nebular-7 quadrant." Yes, for only $48 you too can name a star. Imagine that, in a thousand years, your name will live in the skies -- on the tongue of every resident on every planet in the `The Johnson's Beloved Schnauzer Skippy' solar system. Umm, right.
Adobe Systems is a big, important, powerful software company; I use several of their programs. Their Portable Document Format (PDF) is changing how we use online documentation. They're introducing a new way to purchase paperless books that requires online registration, with a unique identifier that is keyed to just one computer.
If you decide to use the paperless book on a different computer, such as your laptop while traveling, you have to purchase a separate license. Or if your hard disk should fail, you would have to apply for a new license, because the unique identifier is keyed to just one computer configuration.
I understand the issue of protecting intellectual property; steady streams of intellectual property march across the Web without the owner and author receiving any return for their creative investment. The problem may be finding the best way to protect others' intellectual property, while protecting our privacy and our right to use our own data.
Microsoft Office now requires online registration. Apply to the Microsoft Bureau of License Enforcement for a software usage permit, based on a Globally Unique Identifier (GUID) that is keyed to your computer. If, again, your computer configuration should change, you will have to apply for another permit based on your new GUID. The number of times you can apply for a permit to use your software is limited, before you are required to purchase a renewed license. Think of a GUID as a software tracking device. This is just the first step; in coming generations of Windows software, we will be required to pay rental fees; if you don't pay the rental, the software will stop working. Let's hope you're not on a slow boat to the Delta Quadrant when the license expires. Let's hope we like every software upgrade the rental fee entitles us to, because we will be required to use it--
A software license? Not really. It truly is a license to use our own data. If we don't continue to pay the rental fees, we won't be able to access our own data-- Most folks are aware of this, at least on a subconscious level. Many small companies and individuals are waiting, not sure why, because of uncertainty of the future of software and hardware. Many like the software they're using today, and they are waiting for a year or two before making any big decisions. Within a year or two, we will have our choice of closed, proprietary software with monitoring and rental fees, versus open operating systems and powerful, open software packages available free or low-cost. If most folks take the path of least resistance, it will mark the beginning the end of the free enterprise system (for software, anyway). Free Enterprise is dead? The assumptions being made in places like Redmond in the last couple of years will prove to be impractical in an open-source world. We're not heading for either the rental system or the free/open/post-modern model. It'll be an entirely different mix, where huge corporate-backed software development cooperates with huge open source projects. There will ultimately be fewer, but much more complex, products. It's a long bumpy road; along the way, those who resist should watch for ruts. Back to r_harvey home page. Or, more likely it worked until you installed an application, or upgraded your operating system (and installing some applications silently upgrades your operating system without telling you). Besides blaming it on video or peripheral drivers (an effective scapegoat), the problem is the result of improved performance. Simply re-compiling programs using the latest compilers can noticeably improve performance--and introduce uncontrollable bugs. Without getting too technical, here's one issue: the processor's EBX register. In Windows 3.1, we used only half of that register, which was called BX. Because of the way memory addressing worked (and because there were never enough registers), BX was used by everybody, assumed to be volatile, and never used for storage during function calls. When 32-bit Windows started shipping, EBX was now assumed to be reserved, so it should now be preserved within called functions. Just one more paragraph... When programs were rewritten for 32-bit Windows, they began with Windows 3.1 code, and simply changed from BX to EBX. In most cases this was fine. After 32-bit Windows shipped, and long after most of those first 32-bit applications were compiled, optimizing compilers were changed to preserve EBX, and to also assume that functions called would do the same. We're done! And so are some applications. Because every now and again we find an application that didn't get the message when the rules were changed. That's why some applications and operating system versions just don't get along -- they aren't playing by the same rules. Afterthought: if you quietly enforce those rules later, everybody will have to buy upgrades. Back to r_harvey home page. Sandra Bullock was the latest victim on the covers of supermarket tabloids as I waited my turn at the checkout counter. I feel obligated to change the subject when it's my turn, so I began with: "Look at her (Sandra Bullock); everybody likes her because she's real. One day she'll become Melanie Griffith, then finally she'll turn into Cher, and we'll have forgotten what we saw in her in the first place. Money and fame change everything." She answered: "Well, I wouldn't want to go through it, myself." "Yeah, I'd probably rather wave groceries at a laser scanner for forty years, myself" is what I thought, but I said, "Plastic will be fine." I don't know if the clerk fell into my trap, or I into hers'. Well, I'd give it a shot. And I'd hire thugs, whose job it was to beat-up paparazzi, or anybody who tried to violate my personal space or make eye-contact without first getting permission from my people. I wouldn't go crazy, like guys who require the green M&Ms filtered in or out; I'd just eat M&Ms as they come... as long as they are flown-in fresh daily, of course. Find a good tool, learn it well, wear it out, and replace it when it's outdated. More computers are made to use Microsoft than any other leading brand. Low-level programmers once roamed the earth in packs. In the bad old days, everybody wrote everything in Assembly language because all programming tools were terrible, and computers were slow. As someone who spent the last decade programming mostly in Assembly language (I proudly sport a collection of genuine MASM T-shirts), I can say from too much personal experience that it is not an easy life. It takes a special mind-set to stand at the threshold of actually being able to ship completed code, only to say "Nope, I'm not fully in control of the code. I won't ship until I've personally tilled every grain of code... even if it never ships." (The term MASM, by the way, is an acronym for Macro Assembler.) More memory and faster computers are not, as everyone laments, a license to write bloated, sloppy code. At least not always. Needs for productivity and features have grown as fast as computer performance; it is no longer necessary to do it all by hand. And program complexity means that we cannot maintain today's programs with yesterday's tools. Most programs worth having, begin at ten thousand lines of high-level code; written in Assembly language, they would be five to ten times larger. The more lines of code in a program, the greater the number of bugs; if we wrote ten times more code, we would have ten times more opportunities for bugs. MASM is dead. Long live... well, MASM. After all, the goal is still correct, fast, small code. Ask your software vendor: if there is no Assembly language in it, they don't care about you; if it's 100% Assembly language, it's probably not shipping yet. Back to r_harvey home page. A new sound card came in a box big enough to hold a couple dozen sound cards. I reached to the back of the stack for another box, because the first one felt empty. You could drop a palette-full of these boxes from the roof, and they would all blow away without a trace, not even one box would reach the ground. Yes, bulky packaging cuts theft in the retail store, gives the manufacturer more shelf space and more room to list product features on the box, and it protects the product during shipping. The main reason, though, is that it makes the product seem more real. If it came in a box that fit it, it would look like it was worth less money. If you don't over-package, it seems less real, less tangible, less valuable. An online or shareware product doesn't seem real at all, since you cannot even hold it in your hand (it comes pre-blown-away in the wind). Intellectual property and creativity would be easier to sell if they came in big 4-color boxes. Imagine big red banners touting design innovations, bulleted-lists promoting optimization, features and usability. And every double-shift or all-nighter spent in development would make the box a tenth of a millimeter larger. 87-percent of anonymous respondents in a recent survey said they had nothing against using stolen software (read this as: they have no problem with stealing if they are sure that they won't get caught). I wonder how different computers would be if it were difficult to steal software, but easy to steal hardware. Maybe we would see a world of 2GHz Pentium™ 4s running PC-DOS™ 2.1 and WordStar™ 3.31. Back to r_harvey home page. A computer peripheral company had a reputation for reliable, high-quality products. Unfortunately, they never made very much money. An analysis of their processes showed that they were just as efficient as anybody else in manufacturing, but they spent too much on testing and quality control. The solution was simple: eliminate product testing; unless something is obviously wrong, just ship it. Now, they can reduce the price of their products because they don't have to pay for quality control. They are shipping and selling more, and they are letting dealers and customers do and pay for product testing. The percentage of defective products is actually lower than it was when they did their own testing, because minor defects go unnoticed. Everybody apparently wins: the manufacturer makes more money and employs more people, and customers get cheaper products. What about the dealer who has to pay for quality control and handle numerous customer complaints. And what about the customer who has lost time and data, and perhaps their own business when their computers go down. Back to r_harvey home page. In early 1997 I searched the world for the name HTMLcat™ before using it. I eventually found only one reference to somebody who uses ASCII characters to draw pictures of cats (the page is still there). After HTMLcat was released, somebody in France used the same name for an Atari™ program; I haven't contacted them, but I wish they would reconsider. After all, there are a few hundred times more references on search engines and shareware sites to my HTMLcat than to theirs. A company in Ireland unfortunately chose a similar name a couple of years later; we have agreed that they can use a similar name (see Html-CAT). During the first Microsoft Visual C++™ beta around 1990 (a pleasant experience, and a valuable product), I saw the need for quality fixed-pitch fonts for programmers. I began development of the Console font family, and made copies available to Microsoft programmers and fellow beta participants. A few years later, Microsoft released the Lucida Console font family, which filled a similar need. By the way, "Visual C" was a product long before Microsoft began using the name; Microsoft did the right thing, and purchased the product name. In 1991 I needed a book title. The * For Dummies books were all the rage, and the Mastering * books appealed to the more-experienced reader (I had earlier written a book titled Mastering the HP-27S). I finally found the word Explorer, which nobody was using, then I finished the book titled Explorer's Guide to the HP 95. In 1994, Microsoft also discovered the word, and now they use Explorer for several products. There are more examples, but that's enough. I'm now more sensitive about names. It's tough for the little-guy to come up with, and be able to keep, a unique name. A product now under development was tentatively called TextCalc™. There are lots of things, mostly in Germany, using that name, along with virtually every variation and synonym. The only names I've not found are TextCog™, Textulator™, Textize™, Wordeze™ and Wordize™, none of which sound as good or convey the meaning as well (though I hereby reserve trademarks for all of them, and if you want to use any of these names, you can pay me). Top | Notice | Home | | © Copyright 2007 R. E. Harvey, All rights reserved.But It Worked Yesterday
The Price of...
We use . . .
Nobody knows more about the operating system than the folks who wrote it. Their programming tools are tuned to their operating system. However, we don't necessarily use the latest releases. Compilers and Assemblers continue to work just fine when the operating system changes.Escape from MASM
The Packaging is the Medium
The Process is the Medium
Product Names