The picture of the "original" Apple//c in the article appears to actually be a newer model. You can tell by its platinum-colored keyboard. Original versions had a tan keyboard. There were technical differences as well...
The screw up is in Microsoft's release system allowing hhctrl.ocx and user32.dll to be shipped with the exact same "DLL Base Address". They both share address 0x7E410000. I'm sure Microsoft has a system to prevent this, but either someone didn't follow it, or the system has flaws.
Normally clashes of base addresses happen all the time. For most DLLs the base address is sort of a suggested location, the OS load the DLL to this area if it can, but will "relocate" DLLs to free memory area if that space is taken. User32.dll isn't allowed to be relocated for some reason (a very good reason, I'm sure). If it's space is already taken (by HHctrl) the program using it cannot load. HHCtrl.ocx has no problem being relocated, but this will only happen if it's loaded after user32.
I'm surprised that anyone could manage to make an application that would load these DLLs in this bad order - but that's not the point I guess. Usually you'd HAVE to call a function in User32.dll long before loading anything COM - esp an HTML help control (which is what hhctrl is).
Take a look
hereor here
for more stuff from this blog.
Raymond often talks about new OS version having to keep application relying on hacks working. People don't care if game is doing crazy crap internally to determine something (which could have easily been queried with a documented API call)... they care that they upgraded to Windows XP and *it* broke their game.
The company I work for develops an RFID system used in libraries. We use small donut-shaped tags that fit around the hub of the libraries' CD/DVDs. We've used several different RFID designs (different readers, different RFID ICs attached to different antennas) designed in house and off-the-shelf. We're lucky to get 6 inches of read range, let along 6 meters. The metal on the discs themselves often hurts performance; especially on cd/dvd boxes contain multiple discs. Multiple tags in very close proximity often cause the tags to "couple", rendering then useless. We had to develop special boxes that would keep the dics far enough apart and attach secondary booster antennas in the tray to even hope to get reliable reads and extremely short distances. Worry about RIFD tags on the boxes, not on the discs.
I've used both DevPartner Profiler (aka TrueTime) and Rational/IBM's Quantify. Both were roughly the same in functionality. They were both somewhat flakey at times as well (crashing, wrong results, no results).
DevPartner Suite was reasonably priced and, if I recall, contained a more tools in its suite (compared to Rational Purify Plus -- which Quantify is a part). It's always a struggle to get to work in my experience and I often have to spend lots of times messing with settings and excluding certain 3rd party DLLs from the profile run to get correct (or ANY) results. This was with Windows C++ development, I'm sure Java/.NET stuff don't suffer these problems.
Quantify (part of Purity Plus) seemed a little less buggy (but still had issues), but pricing was expensive and complicated (like all Rational tools).
I'm not sure of the exact details of the applications using RPC for same machine interprocess communication but don't blame the use of RPC itself as the issue. Blame the application(s) involved in the communication for not using (MS)RPC correctly to disallow remote invocation of those methods. Its been awhile since I programmed directly to MS-RPC, but I recall you could do all sorts of stuff to secure it, determine the caller's address/endpoint/whatever, and custmoize which network transport you listened/communicated on. Are you sure that remote (as well as local) calling of those methods wasn't actually a valid option?
I feel compelled to chime in w/ yet another me too reply... I have this motherboard as well, and had nothing but trouble with it. It was extremely unstable (system lock ups and reboots) until I bought new DDR memory on a suggestion from a message board to replace the lower end PC133 RAM (from my old system). The whole point of me buying the board was its support for either PC133 SDRAM or DDR SDRAM (I figured I'd upgrade later to DDR - no such luck). It seemed this was common issue.
I've had other issues as well; the experience has sort of turned me off of home-built systems in general (this was like the 3rd or 4th one I've done). I just not worth the cost savings for the headaches if/when things go wrong!
I can't believe someone who had an even worse issue (soldering?!) would consider that board to be "great"!
Code comments I find worthless and distracting are statements of who wrote the code, what bug number it fixes, and when it was done. Often I find "mature" (ok, old) code is filled with this type of stuff. For example (from a random file from the system I work on now):// 7/13/00 default conversion type is BCD ConversionType = BCC_BCD;
Who CARES the on 7/13/00 this change was made! Often these type of comments may include version numbers of the product (better, but still bad). Even worse I'll see JUST version info/dates:// 2.5 if (m_bSomeNewFlag)
Maybe this was helpful for the developer working on these v2.5 changes but don't leave these breadcrumbs around.
Names or initials are bad as well, especially bad when only used alone:// MCW// MikeW
OK, thanks Mike W. for all your hard work!
One issue with this type of stuff is that it's hard to maintain. How do you tell where the code added on "7/13/00" ends? What if I change that line, or add code near it? Do I change the date? Add my name to that code? There's 1000's of lines w/o names on them, who wrote those, and who cares?
Also, how the system worked in the past and how it's been changed can seem, in theory, to be useful... but what is the real benefit? A history lesson? I feel the code is not the best place for this. Often these type of comments included the commented old code, which I find very distracting from what the code IS doing. Even worse is commented code w/ no explanation of why it was commented and not just removed outright - but that's a bit off topic.
The who's, what's, and when's of code changes should be tracked in your SOURCE CONTROL and BUG TRACKING system, period. If those two systems work together, all the better. If you don't have one that can do this job, get one. Make sure it's easy, people are trained on it, accessible to everyone, and fast.
I **hate** Visual SourceSafe (VSS) more then you can possibly imagine but let's get the facts straight:
VSS does support a multiple checkout and merge model that works. It is a configurable option that is turned off by default. Any text file can be checked out by as many users that want to work on it. If the file had changed (someone else checked in the file before you) then you must merge these new changes into you copy before you can successfully submit the file.
If you want to bash VSS, let's talk about how it has a history of corrupting data, is slow, can't branch and merge well, crappy reporting, lousy labeling, not 3-tier, no change sets, poor local file management (detecting files modified outside source control, new files, clumsy "working folders")...
Also VSS is often used in companies you aren't investing the money, time, or brainpower on Source Control Management. So it often misused and/or not fully understood and/or poorly admin-ed. VSS isn't the entire problem in those cases.
As a side note, I read on a blog the some team at microsoft had that orb thing hooked into thier software build and test system.
As developers submitted source code changes an automatic system would incorperate these changes into a working build of the software. After the system was built an automatic test system would see if application still worked.
If any part of this didn't work (it may run the cycle several times a day) their Or would change color. Something like green == build/system test working, red == complier failed... It was in some public place, so the everyone would see as people broke the builds...
I work for a company (I'm a software developer)that develops RFID products for libraries.
I'd have to assume a library advanced enough to have a *friggin* ROBOT work the shelves may want to use an RFID system to track the books. The line-of-sight requirments for barcodes are bad enough, I can't imagine an automated system for books based off OCR/computer vision being at all reliable.
Slashdot Mirror
The picture of the "original" Apple //c in the article appears to actually be a newer model. You can tell by its platinum-colored keyboard. Original versions had a tan keyboard. There were technical differences as well...
http://en.wikipedia.org/wiki/Apple_IIc#Memory_Expansion_IIc_.28ROM_version_.273.27.29IIc
I found this quality comparison of different HD sources (Cable, FIOS, Blue Ray, etc...) to be interesting:
http://blogs.zdnet.com/Ou/?p=962
The screw up is in Microsoft's release system allowing hhctrl.ocx and user32.dll to be shipped with the exact same "DLL Base Address". They both share address 0x7E410000. I'm sure Microsoft has a system to prevent this, but either someone didn't follow it, or the system has flaws.
Normally clashes of base addresses happen all the time. For most DLLs the base address is sort of a suggested location, the OS load the DLL to this area if it can, but will "relocate" DLLs to free memory area if that space is taken. User32.dll isn't allowed to be relocated for some reason (a very good reason, I'm sure). If it's space is already taken (by HHctrl) the program using it cannot load. HHCtrl.ocx has no problem being relocated, but this will only happen if it's loaded after user32.
I'm surprised that anyone could manage to make an application that would load these DLLs in this bad order - but that's not the point I guess. Usually you'd HAVE to call a function in User32.dll long before loading anything COM - esp an HTML help control (which is what hhctrl is).
Menus? That's sooooo Office 2003/IE6! We don't have menus anymore! Move along, nothing to see here...
Oh, the humanity!
Passive RFID tags do get their power via the RF field of the RFID reader they are in range of. Sounds similar at least.
Raymond often talks about new OS version having to keep application relying on hacks working. People don't care if game is doing crazy crap internally to determine something (which could have easily been queried with a documented API call)... they care that they upgraded to Windows XP and *it* broke their game.
The company I work for develops an RFID system used in libraries. We use small donut-shaped tags that fit around the hub of the libraries' CD/DVDs. We've used several different RFID designs (different readers, different RFID ICs attached to different antennas) designed in house and off-the-shelf. We're lucky to get 6 inches of read range, let along 6 meters. The metal on the discs themselves often hurts performance; especially on cd/dvd boxes contain multiple discs. Multiple tags in very close proximity often cause the tags to "couple", rendering then useless. We had to develop special boxes that would keep the dics far enough apart and attach secondary booster antennas in the tray to even hope to get reliable reads and extremely short distances. Worry about RIFD tags on the boxes, not on the discs.
If a commercial tool is an option...
I've used both DevPartner Profiler (aka TrueTime) and Rational/IBM's Quantify. Both were roughly the same in functionality. They were both somewhat flakey at times as well (crashing, wrong results, no results).
DevPartner Suite was reasonably priced and, if I recall, contained a more tools in its suite (compared to Rational Purify Plus -- which Quantify is a part). It's always a struggle to get to work in my experience and I often have to spend lots of times messing with settings and excluding certain 3rd party DLLs from the profile run to get correct (or ANY) results. This was with Windows C++ development, I'm sure Java/.NET stuff don't suffer these problems.
Quantify (part of Purity Plus) seemed a little less buggy (but still had issues), but pricing was expensive and complicated (like all Rational tools).
Just in time!! I just finished Daikatana!
I'm not sure of the exact details of the applications using RPC for same machine interprocess communication but don't blame the use of RPC itself as the issue. Blame the application(s) involved in the communication for not using (MS)RPC correctly to disallow remote invocation of those methods. Its been awhile since I programmed directly to MS-RPC, but I recall you could do all sorts of stuff to secure it, determine the caller's address/endpoint/whatever, and custmoize which network transport you listened/communicated on.
Are you sure that remote (as well as local) calling of those methods wasn't actually a valid option?
Don't you hate pants?!
I feel compelled to chime in w/ yet another me too reply...
I have this motherboard as well, and had nothing but trouble with it. It was extremely unstable (system lock ups and reboots) until I bought new DDR memory on a suggestion from a message board to replace the lower end PC133 RAM (from my old system). The whole point of me buying the board was its support for either PC133 SDRAM or DDR SDRAM (I figured I'd upgrade later to DDR - no such luck). It seemed this was common issue.
I've had other issues as well; the experience has sort of turned me off of home-built systems in general (this was like the 3rd or 4th one I've done). I just not worth the cost savings for the headaches if/when things go wrong!
I can't believe someone who had an even worse issue (soldering?!) would consider that board to be "great"!
It's machine washable, that's a new feature.
By day, CEO...
but once the sun goes down...
MAGIC ON ICE!
Not quite a full mirror, it's missing pages 9 and 10.
:(
"We apologize, but a bug kept us from getting pages 9 and 10."
just when it was getting good
Code comments I find worthless and distracting are statements of who wrote the code, what bug number it fixes, and when it was done. Often I find "mature" (ok, old) code is filled with this type of stuff. // 7/13/00 default conversion type is BCD
// 2.5
// MCW // MikeW
For example (from a random file from the system I work on now):
ConversionType = BCC_BCD;
Who CARES the on 7/13/00 this change was made! Often these type of comments may include version numbers of the product (better, but still bad). Even worse I'll see JUST version info/dates:
if (m_bSomeNewFlag)
Maybe this was helpful for the developer working on these v2.5 changes but don't leave these breadcrumbs around.
Names or initials are bad as well, especially bad when only used alone:
OK, thanks Mike W. for all your hard work!
One issue with this type of stuff is that it's hard to maintain. How do you tell where the code added on "7/13/00" ends? What if I change that line, or add code near it? Do I change the date? Add my name to that code? There's 1000's of lines w/o names on them, who wrote those, and who cares?
Also, how the system worked in the past and how it's been changed can seem, in theory, to be useful... but what is the real benefit? A history lesson? I feel the code is not the best place for this. Often these type of comments included the commented old code, which I find very distracting from what the code IS doing. Even worse is commented code w/ no explanation of why it was commented and not just removed outright - but that's a bit off topic.
The who's, what's, and when's of code changes should be tracked in your SOURCE CONTROL and BUG TRACKING system, period. If those two systems work together, all the better. If you don't have one that can do this job, get one. Make sure it's easy, people are trained on it, accessible to everyone, and fast.
That's not a bug, it's a feature!
Just type in binary, you just need 2 keys.
I **hate** Visual SourceSafe (VSS) more then you can possibly imagine but let's get the facts straight:
VSS does support a multiple checkout and merge model that works. It is a configurable option that is turned off by default. Any text file can be checked out by as many users that want to work on it. If the file had changed (someone else checked in the file before you) then you must merge these new changes into you copy before you can successfully submit the file.
If you want to bash VSS, let's talk about how it has a history of corrupting data, is slow, can't branch and merge well, crappy reporting, lousy labeling, not 3-tier, no change sets, poor local file management (detecting files modified outside source control, new files, clumsy "working folders")...
Also VSS is often used in companies you aren't investing the money, time, or brainpower on Source Control Management. So it often misused and/or not fully understood and/or poorly admin-ed. VSS isn't the entire problem in those cases.
A what??? IIe?? Umm no, never heard of it. I fondly remember my "Apple ][e". Not to be confused with the "//c".
Mmmmmm.... She-Hulk....
As a side note, I read on a blog the some team at microsoft had that orb thing hooked into thier software build and test system.
As developers submitted source code changes an automatic system would incorperate these changes into a working build of the software. After the system was built an automatic test system would see if application still worked.
If any part of this didn't work (it may run the cycle several times a day) their Or would change color. Something like green == build/system test working, red == complier failed... It was in some public place, so the everyone would see as people broke the builds...
I work for a company (I'm a software developer)that develops RFID products for libraries.
I'd have to assume a library advanced enough to have a *friggin* ROBOT work the shelves may want to use an RFID system to track the books. The line-of-sight requirments for barcodes are bad enough, I can't imagine an automated system for books based off OCR/computer vision being at all reliable.