Well, they've always (more than 15 years?) insisted that updates to MS products be dl'd with IE, so is this different? Maybe for just this reason, to keep people using IE, after Netscape came out.
Thank you so much. I made a point to try this first with Firefox and it's dl'ing fine. It first wanted to execute it, because of the .msu, I guess, but I'm only saving it, for another machine.
I'm sure you've told us as much about that file as I could glean.
Thanks a lot.
I had a client that was heavily into NIH mode. At the time the woods were full of competing Z80/8080 buses and cards for industrial control systems like the STD but they wanted their own and I was happy to oblige.
You have to train the engineers right :) DEC salted the colleges heavily with their equipment. When the young engineer gets out in the real world and starts politicing for equipment, what's he going to advocate? Then there was Unix during the period where you couldn't exactly buy it. Half of Boston was running an OS that fell off the back of a truck someplace.
M$ did that with the $99 academic versions of Visual Studio. Lately they've expanded that with the Express and Community editions. Get them hooked and they'll be begging the boss to buy the Enterprise package.
Our MSDN just came up for renewal and they've changed the game a bit. You can still buy the full meal deal but I saw in the pricing matrix that you can also rent it for $45/month. They're easing the world int the new model.
This state had a massive 2400 baud backbone. I suppose it was a step up from a 300 baud acoustic. I was on Delphi and that was really styling.
Ah, curses... The early db_VISTA database had a curses based management tool. When Windows dropped ANSI.sys in 7 that was all she wrote -- almost. The gamers who loved their old DOS games had developed DOSBox and life was good again.
Have it your own way.
That's the advantage of building it into the actual object that uses it (e.g., configuration files). You *know* where you will be going to make the changes -- and, there is the information you need to make them!
In my current project, all of this is centralized in an RDBMS (there is actually no concept of a "file system"; all persistent storage happens
*in* the RDBMS so it's harder to create some ad hoc entity than it is to create a structured one!).Each schema is commented so you can examine a description for each "column parameter". Individual rows (entries) can place comments in the "comment parameter" (present in all of the tables I build).
Of course, no way to force future developers to perpetuate this discipline. But, I've built mechanisms that automatically convey these things to the user (i.e., "What's the role of the 'Delay Prior to Restart' parameter for the HVAC controller?" "The 'Delay Prior to Restart' parameter controls the hold-of period between the end of one furnace activation and the start of the next") So, hopefully, future developers will find it easier to "fill in the blanks" in the database instead of having to develop their own "help system".
*If* they remember it -- and haven't just worked-around it.I believe people are lazy. And, always opt for expedients. So, I try to cater to that and provide my solutions to tolerate (or even encourage!) that sort of behavior (as above).
The problem is much greater, IME, when you are dealing with highly disparate knowledge domains. E.g., hardware folks are often oblivious to the concerns (or capabilities!) of software folks; neither are savvy to the issues regarding packaging and physical interfaces; NO ONE cares about the things important to the bean counters; programmers document the code for other programmers -- but not the user; etc.
I was real tight with my best friend from school. At one time, we worked on a joint project -- I designed the processor (built entirely of bipolar logic) and he wrote the code for it. Nothing on paper -- just ideas that we "discussed over lunch".
When I got the prototype built, we installed his software (written without having access to any hardware or even a "simulator"). NOTHING worked! Despite each of us being 100% confident in our own designs AND in the capabilities of the other party!
As it turned out, I had designed a 16b machine. Everything was 16b (or multiples thereof). He had thought of everything in terms of bytes. So, all of his (byte-oriented) addresses were twice *my* (word oriented) addresses! I.e., "CALL 6042" should really have been "CALL 3021". A true "Homer" moment. But, one that we could fix in a few minutes (tweak the assembler he wrote to divide everything by two and reassemble the sources).
Folks anxiously watching us bring up the new hardware were amazed at the fact that it "came up on the first attempt" (discounting this SNAFU). Without all sorts of formal documents to indicate how everything SHOULD work.
But, that sort of deep sympatico is rare -- not something I'd encountered with anyone else in the years since!
OTOH, there are a lot of projects that are just too large for small organizations to tackle. I've worked on multidisciplinary "teams" of
1 to ~30. The smaller ones are far more agile than the larger. Less formality required in the interactions. OTOH, you've got lots of extra minds and bodies with the bigger ones so you can get more done per unit time.In my current project, I have to deal with an undefined, faceless "support team" that will take my work in directions I've probably not foreseen. So, I have to build a solid foundation to impose as much guidance as I can on the design to keep it from meandering in the absence of my guidance down the road. "Talking to the future" is tough cuz they can't talk back!
The opposite is true -- worse -- now. All these little "stamps", arduino, rpi, etc. Folks seem to think all they need to do is buy a premade board and they're all done!
Until they discover that the board doesn't come with controls suitable for driving a fractional HP motor. "Ah, but we can buy a daughter card to handle that!" Then, they realize the daughter card has no provisions for a safety interlock to shut down the motor (even if the CPU is crashed) before the mechanism that it is driving crashes into its stops. "Ah, we can buy..."
And, when they're done, they look at this hodgepodge of cards glued together and realize they have a $300 solution -- based on a $10 CPU board. "Hmmm... maybe we can layout our own board and combine all of these?" (Yeah, *if* you had the expertise to do that to start with...)
I have a colleague who has built all of his development tools! Incredibly impressive -- his own OS, his own window system, his own compilers, etc. But, I'd rather BUY that than MAKE it. OTOH, I have to roll my own RTOS because there's nothing available "at any price" that can do what I want (and need) done.
Yup. At Athena, you had your own *personal* VAX! When the rest of the world was struggling to afford $5K "XT's" with a whopping 128K of RAM and a single-tasking "toy" OS!
Many vendors (including apps) have taken the same approach. The more specialized the knowledge required to operate a tool, the bigger the payoff for presalting the future employee pool! If someone can learn how to use vendor X's product offering in a few days, then there's not much value to the prior experience he may have had with vendor Y!
OTOH, if it takes thousands of hours to become proficient, then there's a big incentive to drawing on that pool of EXPERIENCED users instead of trying to reeducate them for some other tool (because someone at your firm flipped a coin and chose Y over X)
I ran OpusV (AT&T w/ BSD extensions) on an Opus 110PM (later, more advanced models from the product line) in the mid 80's *in* my 386. A fairly zippy system (currently have it running in a Compaq Portable 386 as the PM is ISA based).
Most of the OS's in school (other than MULTICS or TOPS-10) were little one-of-a-kind works that professors had written and deployed on whatever hardware they could scrounge for their classes. I.e., each class ran on different hardware, OS, languages, etc. It wasn't like you could use the tools from class A to work on a project for class B (and you had to walk *to* wherever the machines/terminals for that class happened to be physically located!)
In the early 80's, JRT Pascal tried the same approach -- $29.95 Pascal compiler. They couldn't make/ship them fast enough! (literally, they went belly up from the popularity) And, it was cheap enough that you'd just buy it to get a hard copy of the manual (how much is your time worth to xerox a manual??)
Yup. MS is slow to the party. But, you can bet your *ss they're not going to miss out! Great time to be squirreling away everything that is precious and rethinking which path you want to follow, going forward!
[What happens when you "leave" the community -- and then have to come back at some future date to support some legacy product? What if the "old tools" are no longer available for use?]
One of my favorite books is 'The Mythical Man-Month'. In any social structure the abilities of the individuals vary. The larger the organization the more hiding places for the timeservers and those who should have been in another career entirely.
There is an advantage to corporations that are too big to fail. Lockheed Martin and Northrup Grumman consistently fail but the money keeps flowing in.
That's the latest failure in my field. Missing the go-live date might have been smoothed over with a penalty but reading between the lines London had no confidence that NG could ever deliver a working system.
I found it a delightful programming environment! It was relatively trivial to "pop up" an error message and leave the majority of the screen/display intact (instead of forcing the user to look back through a list of commands/responses that might remain, serialized, on his screen).
Likewise, putting a "current time" display (with seconds ticking off!) in the corner of the screen really was over-the-top compared to competing products (where you had to ASK for the current time -- which was displayed as a snapshot of "the time as of when you asked")
Lack of a mouse (telephone line??) made it less convenient than modern point-and-click GUI's. But, tabbing between fields and using hot keys (by HIGHLIGHTING one of the letters in the displayed field!) made it relatively easy for folks to do things quickly and efficiently.
It's sad to see folks forgetting old solutions. Or, failing to realize how those could be applied to modern problems! (e.g., how many little devices have "serial consoles"? Why restrict them to "sequential command lines" when you could present a windowed user interface to the user -- like screens(1)!)
An old IBM "mini" had a delightful feature that I've been waiting to use. The user interface operated asynchronously with the job scheduler. So, you could type a head while the previous job was still running.
Unlike PC's (where those keystrokes aren't YET visible), the user interface would display the commands you'd "typed ahead". So, you could see what you were typing and what you'd ALREADY typed (you could get pretty far ahead of the machine if it was doing some real crunching!).
Whenever there was typeahead information queued, the display would split into two halves -- the screen as it existed while you were awaiting the results of the currently running job would be on top; and the screen containing the list of enqueued type-ahead keystrokes was visible on the bottom.
As jobs finished, the corresponding commands from the type-ahead queue would be pulled up into the top portion of the screen and the bottom portion shrunk, accordingly.
This is brilliant! Consider what it's like to type-ahead on a UN*X box -- you don't readily know what you've got enqueued for the system at any given time!
Couple this with a scrollback buffer (so you can review past commands and the associated output) and you've got a powerful -- but cheap -- UI!
| Well, they've always (more than 15 years?) insisted that updates to MS | products be dl'd with IE, so is this different?
I didn't know that. I've never downloaded anything from MS via IE. I haven't had IE online since about
1999. I download SDKs, service packs, etc and it's never insisted that I need to use IE. Maybe you mean going to the Windows Update site? In any case, it's indefensible for them to say that.| Thank you so much. I made a point to try this first with Firefox and | it's dl'ing fine. It first wanted to execute it, because of the .msu, | I guess, but I'm only saving it, for another machine. |
I save all such patches. One never knows when they might be unavailable. Microsoft have far more broken links on their sites than any other domain I know of.
Now it's worse! You have to build for web deployment, smart phone, PC, Mac, etc.
In my case, I have to assume the UI can be haptic, visual or aural (or combinations of the above). I drew the line at English speaking, though -- way too much to learn to address those language and cultural issues! :<
Hmmm... interesting.
There isn't! Just "entertainment systems"! :-(
(I wonder how many people actually use computers for "computer stuff" vs. entertainment-related activities)
There's nothing wrong with them HIDING! It's when they end up in positions from which they can make decisions (or even obstructionist participation) that problems happen. ("The Peter Principle") Folks promoted out of positions where they HAD to be productive (worker bees) and INTO positions where they are inevitably OBSTRUCTIVE (cuz they can't recognize the difference between the hole in their *ss and the one in the ground in front of them!)
With bigger organizations, these folks seem to want to "be noticed"... made to feel important (or, at least, "significant"). So, they get involved in things for which they have no qualifications. Then, fall back on the "I'm the boss" credential to ensure things stay f*cked up. All the while, thinking of how they can hope for a change in events that will let them shift the blame to someone/thing else.
I had a PHB who was visibly upset with me for stumbling on a problem in a colleague's design. Catching it when I did saved the company several months and several tens of kilobucks!
*But*, it meant the boss had to go in and report the problem to HIS boss, TODAY! He couldn't wait for the 3rd party vendor to perhaps miss a delivery date (that he could then use to rationalize the delay -- by obfuscating the pertinent details).Unfortunately, they'll still be on the list of approved vendors!
The more interesting issue is the apportioning of the incompetence that is undoubtedly involved. Were the requirements too vague? Too lofty? Or, was the execution flawed?
I was invited to bid on a nice, lucrative project, locally (most of my clients have been remote so this would have been a blessing!). After talking with the principal, it was immediately obvious that he:
- didn't understand his problem
- had already come up with an approach (that wouldn't work)
*If* he'd just stated his problem and was willing to sit back and wait for a solution, it would have been a manageable (and profitable) project. But, you just KNEW he was going to have his fingers in the pie throughout -- then wonder why it was taking too long and costing too much! [I learned to avoid T&M jobs for exactly this reason; let me give you a fixed cost quote -- then, it would be ludicrous of me to give you any say on the design after accepting those terms!]A local nonprofit has a serious data management problem. I formulated a comprehensive, automated solution and presented the idea to the "staff member responsible". It was a project that I would tackle pro bono -- no skin off their back!
"No thanks! The Board approved $250,000 for the project and we've hired a guy to do it."
So, a quarter of a megabuck later, they have an MSAccess database and hired two full time staff who just sit and transcribe the hundreds of forms that come in each week. And, they wonder why the data is always suspect!
("How come last week's records are missing the data for Foo?" "I dunno. Maybe I deleted it, by accident?")
People don't "realize" what they don't "understand". Yet, blissfully make decisions based on that misinformation. Then, end up with "striped camels" instead of horses and wonder why they're so hard to ride...
I missed that one. I'm not a Pascal fan but when TurboPascal came out I dropped the $50 out of curiosity. I was using Zolman's BDS C on CP/M and when I did the obligatory Hello World with Turbo my first thought was something had went wrong, it couldn't have compiled and linked that fast.
Later I used the Borland C++ compiler and IDE with OWL. I preferred it to MS but by Visual Studio 1.5 the race was just about over. That whole period wasn't exactly a highpoint. I'm not a big C++ fan. It was a premature birth without real libraries so MS invented their own, along with their Hungarian notation style. I still have some older ArcObjects C++ code but I've moved on to C# as well as plain old C for speed. I'll leave 'Modern C++' to the kids.
There was that brief blip for C++ when MS was pushing WinRT but that seems to history along with Windows 8, Sinofsky, and Ballmer. The final nail was when MS bought Xamarin.
I don't have any hard figures but some of our users prefer the tabs and so forth even with a GUI. I recently fixed a bug that we had a hard time reproducing. It was a simple form with a few preset fields. We'd edit the one field of interest, click on Okay, and it worked as intended. Even watching the user remotely we didn't pick up on the additional action. He would tab, triggering a value changed callback which would reset the field to its original value and then click.
No problem fixing it after we found the path but it was one of those thing that leaves you scratching your head. "It's been like that for 10 years, and this is the first person to hit on the bug?"
I've never done much 'business' programming but I did an inventory application for the company I was working for. It was a very primitive interface based on BRADS, a cut down sort of RPG that came with an IBM
5110. I learned quickly that the people inputting the inventory info didn't even look at the screen after a short time. field, tab, field, tab, field, tab, field, enter, and on to the next item.
Hopefully the solution we're proposing will be viable for a while. C#, WPF, and Xamarin.forms for the mobile devices. Using a MVVM architecture makes it fairly easy to abstract the business logic from the presentation layer and Xamarin handles the Android/iWhatever/Windows Phone end. Macs aren't a problem. PSPAs just don't Apple desktops although iPads and iPhones are popular.
I read a set of requirements recently that when you parse the fine print suggested the system had to be usable by deaf, dumb, and blind dispatchers. We've done Spanish which must be a hoot to Spanish speakers. Google translate only gets you so far. Native Spanish speakers don't exactly grow on trees here particularly ones that know the right idiom. One man's camión is another man's autobus.
Yeah, I have a copy of the v3.0 manual still on the shelf (as a language reference) -- alongside Wirth's 2nd ed.
Yup. I had an old 512KB CP/M (ZCPR3) box that would run like greased lightning (use the large RAM as a disk cache or a semiconductor disk). For most 64K machines, the speed of secondary storage was the limiting factor as most compiler/assemblers/etc. were multi-pass -- not smart enough to tackle everything in a *single* pass! (even with restrictions on forward references, etc.)
Yup. I have the "two tone" volumes on the shelf above the Pascal texts (things are sorted in alphabetical order by language name). Ditto for Pascal with Objects, etc. (I've purchased a LOT of software over the decades!)
I still have a copy of Borland 5.0 on one of the laptops. I use it as a glorified lint(1) when I'm traveling (if it doesn't compile under EVERY compiler, then I must have a syntax error, someplace)
The idea of object-based designs is a good one. But, I'm not sure that you need an object-oriented language to accomplish that!
E.g., my current system is object based -- but written primarily in C. Each object has a "handle" managed by the RTOS. You invoke operations (methods) on the handle by giving the handle and the operation information to the RTOS. It then dispatches the operation, on your behalf, to whatever "active entity" (process) manages that particular instance of that particular type of object. (I.e., the "object" may "reside" somewhere else in the physical system; you don't care!)
Hungarian notation. Yet another stupid idea. Like walking around with name tags that say manDonY, motorcyleHarley, gasstationCitgo, etc.
I was reading one of Stroustrup's texts some years ago. Got to a discussion regarding pre/port in/decrement operators. Read the page two or three times wondering "what am I missing here? this seems entirely WRONG -- yet, it can't be! It's so simple and this is coming from the Horse's Mouth..."
I eventually wrote him, head bowed in humble respect, begging for enlightenment. "What am I *missing* in your description? It seems completely WRONG -- forgive my insolence..."
His reply: "Because it IS completely wrong! I'll have to fix that in the next edition..."
I figure if the acknowledged expert can't get the *simple* things right, then I haven't a chance!
(If you think C++ bad, look at Ada! One of those things where they want you to invest your career in it -- so you never can afford to walk away from it!)
MS keeps wanting to have things their own way. Without ever making any commitment to keeping them that way! It would be like someone deciding that ints should be 37 bits, henceforth. Then, in the next release, realizing that this was a bad idea and that 28 bits would be much better -- and, giving you glue libraries to fixup all such references!
I left MS's tools at VC++ 1.0. I had found a bug in C++ 7 (or whatever predated VC++) and, rather than give me a fix, they offered to sell me the new product at the bargain $99 price!
"No thanks. I think I'll find another development environment..."
You can't support these things after-the-fact. You have to plan on them in the initial design.
E.g., you'd design a microwave oven differently if you knew it had to be usable by blind/deaf folks and not just sighted ones. There's nothing inherent in the concept of a microwave oven that precludes addressing these users. It's just been simpler for folks to resort to displays and flat membrane keypads instead of indicators and controls that can be identified without vision.
(given the diabetic emergency in this country, I suspect a lot of folks are going to find blindness "late in life" to be a real challenge! No time to learn how to adapt to the loss as you would if you'd grown up with it)
The keypad for the initial Reading Machine had no labels on it. Folks would walk up and ask, "But how do you know which key is which?" Smile politely and tell them to close their eyes and repeat the question...
(there was a button called "nominator" that was in an easily accessible location. Press it and it announces the functionality of the next button you press)
Yes. Mouse/GUI requires you to take your hands off the keyboard. Then, find their proper positions, again, once you've adjusted the mouse. Much quicker to move a particular finger up to a particular "next field" key and leave the mouse off in the corner.
Watch a touch-typist and you'll see how incredibly inefficinet GUI's are. And, why you want a common set of keystroke shortcuts that spans applications!
I do much the same when entering columnar data, etc. Keep my eyes focused on the input text (cuz relocating where you *were* is prone to errors and takes a fair bit of time each time you look away) and let some "background process" control my fingers.
Much of Windows is tedious for me to use because of the GUI aspect of the OS/window manager AND all the applications!
E.g., if I have to rename a bunch of files, it's easier to dump the list of files into a text file. Then, copy each filename to the end of its current line (inserting a space between the first and second instances). Then, pasting "RENAME " in front of each line and manually walking down the list of "second instances" changing them to whatever I'd like them to be.
I was editing MP3 tags last week and faced with this problem. Easy to change filenames (using this trick). But, virtually impossible to change the associated tags IN each file -- because the application didn't provide a means to "export" the tags to a simple text editor and later reimport them!
(There's a reason I use UN*X as much as possible!)
I worked on a RFP a few months ago. The first thing I did was to list the conflicting requirements plus some of the completely unfeasible requests that weren't going to happen. It didn't make me too popular but I wasn't going to sign off on the impossible.
Early in my career the company I worked for bid a project over the advice of myself and the mechanical engineer. There was a requirement for a 7 second cycle time but the VP said they didn't really mean it. We got the cycle down to a reliable 15 seconds. The client said, 'That's nice but we need 7 seconds'. Trying to find those 7 seconds was like building a top fuel dragster. After you make your 4 second pass you rebuild it. It got to the point where the said VP could look at a dial indicator showing critical parts bending under stress and declare it wasn't happening before trundling off for a few Rob Roys.
I'm still not shy about undertaking difficult projects but I try to avoid the impossible. In real life the impossible doesn't take a little longer.
I think (esp as a contractor) clients often float RFP's as a cheap way to get someone to find the flaws in their ideas. Learning to recognize when someone is looking for "free labor" (in the guise of soliciting for a supplier!) is an important skill that is hard to acquire.
Often, the best bid is "No bid"! :>
In my career, the most enjoyable ones were always the ones where I *thought* I could tackle it -- but wasn't quite *sure*!
Anything that I was *sure* of wasn't interesting (what's to learn from that? I already KNOW how to do it so its just trading my time for your money -- I can do that lots of different ways; why not find one that I'll consider INTERESTING?!)
Anything that I know I couldn't do was just setting myself up for failure.
So, the sweet spot are those things that you *hope* you can do (with your level of experience, tools, financial resources, level of dedication, discipline, etc.).
I'm convinced I will never "finish" my current project with the years I have left on the planet -- there's no really "defined end". So, I can expect to remain interested and engaged as long as I am capable of being interested and engaged! Enjoy the mini-successes and accomplishments along the way and let someone else enjoy the "finished" product (if they can ever settle for some definition of "finished"!)
I left Wirth's book somewhere along the way. When I moved from NH I gave most of my development boards, documentation, computers and so forth to a high school teacher who was trying to get a computer lab going.
At the time the University of Maine used Pascal as a didactic language, which was its true calling. The best description I've heard was 'a language that specializes in telling secrets to itself since there is no i/o.' Sprague's tantalum capacitor operation in southern Maine tended to hire out of UM. Kept me in work writing drivers so they could happily program in Pascal and interface to real test equipment.
Our architecture is based on a number of objects -- and it's all C. I haven't read Stroustrup's latest edition but the early one I have looks a lot like C, snake_case and all, with classes used very sparingly. I blame some of what it turned into on academics. 'Here we have the Animal class. The Dog and Cat class inherit from Animal, but we'll override speak() so Cat says meow and dog says woof.' I don't know how many hideous class architectures I've seen because someone figured since it was C++ everything had to be a class.
We've had a few koolAid drinkers in the past. The most notorious is an mostly obsolete map program. There are literally variables like theMap, thePixel, theSegment. It's good for a chuckle. When I'm doing maintenance work I try to maintain the original style as much as possible but sometimes I just can bring myself to do it.
I never nibbled on that hook. I remember the Boston Globe Sunday ads from companies looking for programmers with two years Ada experience -- before there was a working Ada compiler. Got to love HR drones. The bait smelled familiar. I had bad memories of the subtly named Programming Language One.
We thought long and hard about WPF. It doesn't give you confidence when MS took SilverLight and WinForms out behind the barn and shot them. At one time ESRI was promoting either Silverlight or JavaScript for web based applications. I lucked out and went with the JavaScript API, figuring that wasn't going away.
Even with WPF we're going to go to great pains to make sure the view stays the view.
That was my first go around with ATL. I thought it was a shortcoming on my part but, no, it was a bug in the ATL code.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.