> Joerg wrote:
>
>>>> Your are probably right. However, that's a "version control" scheme
>>>> that is totally foreign to me.
>>
>> Yes. What were they thinking? In order to remain compatible it seems
>> you must install the old versions along with the latest. Man, the FDA
>> would rip me apart in the air if I ever designed something like that.
>
>
> Let me guess - you design devices which have one, or maybe two, interfaces,
> being mostly in simple master-slave relationships?
>
They are a bit more complicated than that but not five-digit. The
largest ones I design typically still have less than 100 locations that
need to exchange data. But some of those are realtime to the point
where, for example, another section of the whole system needs to trigger
on an ECG signal within spec'd accuracy. Failure to do so in timely
fashion can cause some grief.
> Now try considering a system of 30,000-50,000 separate components, each one
> with a dependency on from 5 to 50 of the others, each one potentially with
> flaws and outstanding change requests, and you get some concept of the
> configuration complexity. We're talking hundreds of millions of times more
> configuration risk (in terms of ramifications of a change in any one of
> those
> interfaces) than you have in your devices.
>
> I'm not saying your devices aren't more complex internally, or that each
> interface isn't complex in itself, and it's probable that *that* complexity
> is higher than each of the elements of a generalized software runtime, but
> they still aren't even on the same planet when you consider configuration
> risk.
>
> It doesn't help that the Windows APIs are at least an order of magnitude
> more numerous than strictly required... but that's exactly why the .NET
> runtime was necessary... it forms a new platform that's vastly simpler
> than the old one, and can move off Intel architectures to boot (vis Mono).
>
I don't dispute the need for something like .NET. It's just that I find
the implementation not to be as organized as I'd like it or as agencies
may request that our systems live up to.
--
Regards, Joerg
http://www.analogconsultants.com
Reply by Clifford Heath●September 27, 20072007-09-27
Joerg wrote:
>>> Your are probably right. However, that's a "version control" scheme
>>> that is totally foreign to me.
> Yes. What were they thinking? In order to remain compatible it seems you
> must install the old versions along with the latest. Man, the FDA would
> rip me apart in the air if I ever designed something like that.
Let me guess - you design devices which have one, or maybe two, interfaces,
being mostly in simple master-slave relationships?
Now try considering a system of 30,000-50,000 separate components, each one
with a dependency on from 5 to 50 of the others, each one potentially with
flaws and outstanding change requests, and you get some concept of the
configuration complexity. We're talking hundreds of millions of times more
configuration risk (in terms of ramifications of a change in any one of those
interfaces) than you have in your devices.
I'm not saying your devices aren't more complex internally, or that each
interface isn't complex in itself, and it's probable that *that* complexity
is higher than each of the elements of a generalized software runtime, but
they still aren't even on the same planet when you consider configuration
risk.
It doesn't help that the Windows APIs are at least an order of magnitude
more numerous than strictly required... but that's exactly why the .NET
runtime was necessary... it forms a new platform that's vastly simpler
than the old one, and can move off Intel architectures to boot (vis Mono).
Clifford Heath.
Reply by Joerg●September 27, 20072007-09-27
Eric Schwartz wrote:
> Joerg <notthisjoergsch@removethispacbell.net> writes:
>
>>AFAIU you need to have a VB copy on each PC it gets installed
>>on. Sure, you can then remove it but that scrapes the fringes of the
>>legit range. Also, IT folks dislike installing programs that don't
>>come from major SW design houses.
>
>
> You know, I'm not the world's most fervent Microsoft admirer by a long
> shot, but I would find it hard to describe them as anything other than
> a "major SW design house".
>
It wasn't about them. It was about me (or rather someone more versed in
programming) writing VB Code. That would be a not so major SW design
house ;-)
--
Regards, Joerg
http://www.analogconsultants.com
> AFAIU you need to have a VB copy on each PC it gets installed
> on. Sure, you can then remove it but that scrapes the fringes of the
> legit range. Also, IT folks dislike installing programs that don't
> come from major SW design houses.
You know, I'm not the world's most fervent Microsoft admirer by a long
shot, but I would find it hard to describe them as anything other than
a "major SW design house".
-=Eric
Reply by Joerg●September 27, 20072007-09-27
The Real Andy wrote:
> On Thu, 27 Sep 2007 00:48:17 GMT, Joerg
> <notthisjoergsch@removethispacbell.net> wrote:
>
>
>>Robert Adsett wrote:
>>
>>
>>>In article <LovKi.9066$JD.147@newssvr21.news.prodigy.net>, Joerg says...
>>>
>>>
>>>>I am not a fan of .NET. It seems to have serious backwards compatibility
>>>>issues. Case in point: New scope SW came, must have .NET. Installed 2.0,
>>>>did not work. Inquired -> Must use 1.1 because 2.0 is not compatible.
>>>>Great. <shaking head>
>>>
>>>
>>>That appears to be Microsofts latest approach to solving version
>>>dependancy issues. Just run a separate copy of every version. So if
>>>you have a program using version 1 and another program using version 2
>>>you get both copies in memory.
>>>
>>>It appears they've given up on the idea of actually getting it right. I
>>>don't know if it's a reasoable approach but it sure rubs the wrong way.
>>>
>>
>>ROFL! That was a good one. But it sure looks like it. Now if it was only
>>.NET that would be one thing. The world would keep spinning without it.
>> However, it seems there is now an "oh s..t" experience even with Vista.
>>
>>Anyhow, I have become very careful WRT adopting all this newfangled
>>stuff from up there. Ordered a new desktop today. With XP. Surprisingly
>>the sales guy at the small biz desk told me right off the bat before I
>>had even brought it up "And you want XP on there, right?"
>>
>>It's not that I am dissing MS for everything. They did produce some nice
>>and useful SW packages. Office being one of them, but also MS-Works.
>>
>>
>>
>>>Just in case you were wondering why disk and memory requirements keep
>>>climbing w/o bound.
>>>
>>
>>Bloat without bounds. Funtionality doesn't grow in proportion though.
>>This whole problem with RS232 into spreadsheet was a non-issue in the
>>DOS days. I used MS-Works. It had a built-in terminal program that could
>>pipe in the data, a spreadsheet, a word processor and a database. So
>>when I wanted to recreate and decode a datastream out of my logic
>>analyzer (to diagnose ADC distortion effects) I grabbed a serial cable,
>>plugged it in, and bingo. No .NET, no Active-X, no DLL hassles. It
>>simply worked.
>
>
> Yes, but back in the DOS days there was no braodband, and there was no
> fancy monitors and digital cameras. there was no CD's (maybe just) and
> no MP3's. There was no portable music players and skype. There was
> text based word processors and dot matrix printers. Monochrome screens
> (4 colours if you were lucky) and speakers that beep instead of
> playing music.
>
Hey, I had a Freecom CD box, 16 colors, and a well functioning HP
DeskJet. Later a HPII LaserJet. Web sites were not fluffified but
practical. Case in point: Sabre. Since I flew an enormous amount of
miles some airlines allowed me to call my flights in directly. Sabre was
strictly ASCII based, meaning blazingly fast over the 7-8K my modem
could realistically yield. Then Sabre was bought up and it was all over,
it suffocated in new fluff :-(
> Now tell me functionality has not increased.
>
For engineers who design electronic circuits it hasn't increased too
much. Ok, there is a whole lot more content on the web now versus back
then. But when I look at my design process I see this:
DOS:
The OS is nearly unconditionally stable and blazingly fast. Laptops ran
6hrs on an old technology NiCd battery no sweat.
OrCad 3.22 (MUCH better than today's)
MS-Word 5.0 (imported schematics and graphics just fine)
MS-Works 2.0 (did all the biz books)
Mosaic browser (the best I ever had, never crashed, not once)
CompuServe email client (also the best, did _not_ do single file)
MS C-Compiler 7.0 (if I wanted to be dangerous...)
Windows today:
OS is totally sluggish, need two PCs at any given time to reach same
productivity as with DOS. Laptops slurp up the charge of an expensive
LiIon battery in under 2hrs, a large percentage of which is wasted in
Windows overhead activity. Crashes galore.
Eagle (OrCad costs 3x of the DOS version, crashes too much IME)
MS-Word 2000 (Ok, but does crash once in a while)
MS-Works for Windows (Ok, but slow, too much fluff)
Mozilla (Crashes much less than IE but bloated)
Thunderbird (Ok, but also a bit largish)
IAR Suite because I went to uC (Pretty nice, actually)
So, there.
Look at how often the word crash occurs in each category. I know that
the picture changes for someone like a marketing pro or graphics artist
but for a HW designer the main difference is that both reliability and
speed took a dump.
>
>>Heck, if I have my druthers one day I may just go back to that MS-Works
>>program. It's still here, on a 5-1/4 floppy. I wonder if the COM ports
>>can be addressed from a DOS window.
> In article <%QCKi.29677$eY.9501@newssvr13.news.prodigy.net>, Joerg
> says...
>
>>Clifford Heath wrote:
>>
>>>You should be congratulating MS for finally doing something positive about
>>>solving DLL hell, not castigating them for your mistake.
>>>
>>
>>Your are probably right. However, that's a "version control" scheme that
>>is totally foreign to me. And I bet in my line of biz (FDA regulated)
>>the Federales wouldn't let that fly. With our SW newer versions must
>>support the old stuff. Just imagine the ER doc loading a patient file
>>because he urgently needs to get some info, then a message pops up
>>"Requires DICOM version x.xx, please contact your IT administrator".
>
>
> Or, a handheld device that needs to communicate with some sort of
> controller. Regardless of version upgrades in either they must still
> work together. An old handset must work with new controllers and vice
> versa. Carrying around two handsets is not an option.
>
Yes. What were they thinking? In order to remain compatible it seems you
must install the old versions along with the latest. Man, the FDA would
rip me apart in the air if I ever designed something like that.
<banging head on table>
--
Regards, Joerg
http://www.analogconsultants.com
Reply by Joerg●September 27, 20072007-09-27
The Real Andy wrote:
> On Thu, 27 Sep 2007 01:14:58 GMT, Joerg
> <notthisjoergsch@removethispacbell.net> wrote:
>
>
>>Clifford Heath wrote:
>>
>>
>>>Joerg wrote:
>>>
>>>
>>>>40MB to get to the ports, wow ...
>>>
>>>
>>>Getting to the ports might be all *you* wanted, but the runtime provides
>>>an entire JIT compiler-interpreter and its runtime library, i.e. it's an
>>>entire platform, and actually quite small for what it is.
>>>
>>
>>I just don't understand why Billy's folks restricted mscomm.ocx. It
>>prevents tons of Excel and Office sales into labs from happening. From a
>>revenue POV that is like shooting themselves in the foot.
>>
>
>
> They dont restrict it. If you package it up using VB, then you can
> distribute it freely. IF you have any questions about distributing it
> as part of excell then send an email to MS legal, they will give you
> the answer.
>
> What you are doing is outside the realms of what Excel was designed to
> do, why dont you just obtain a second hand copy of VB and use that?
> You can then package up the ocx and install it on any pc you want.
>
AFAIU you need to have a VB copy on each PC it gets installed on. Sure,
you can then remove it but that scrapes the fringes of the legit range.
Also, IT folks dislike installing programs that don't come from major SW
design houses. With an Excel file that's different even if they have to
click ok for macros because it is still considered a file. Although a
heavily VBA-laden file is in reality software.
>
>>>>Your are probably right. However, that's a "version control" scheme
>>>>that is totally foreign to me.
>>>
>>>
>>>So you'd expect that old DOS program to still work under Vista, would you?
>>
>>
>>Honestly I do not care because I won't let Vista into the business here.
>>I did run some in XP. Actually I have to because some of the old filter
>>design routines don't come any other way. The usual, a prof had an
>>excellent group that wrote all this. Then he got older, retired, new
>>prof came in, had other priorities on his mind and the project withered
>>away.
>>
>>If XP wouldn't have run it I would just downgrade to Win2K. The only
>>price a biz user really pays is that some stuff might then only be
>>driveable in plain vanilla modes.
>>
>>
>>
>>>Myself, I'd rather that the platform moves on occasionally, and that means
>>>breaking compatibility with programs that depend on bugs and design flaws
>>>in the old version. At least with .NET you have the option of running old
>>>programs on the old runtime, and new ones with the new one. It's not as
>>>though they've released hundreds of versions, after all - there are only
>>>two in play currently and a third coming.
>>>
>>
>>In the med biz we don't like such moves. Our liability insurers don't
>>either ;-)
> Joerg <notthisjoergsch@removethispacbell.net> writes:
>
>
>>Clifford Heath wrote:
>>
>>
>>>Joerg wrote:
>>>
>>>
>>>>40MB to get to the ports, wow ...
>>>
>>>
>>>Getting to the ports might be all *you* wanted, but the runtime provides
>>>an entire JIT compiler-interpreter and its runtime library, i.e. it's an
>>>entire platform, and actually quite small for what it is.
>>>
>>
>>I just don't understand why Billy's folks restricted mscomm.ocx. It
>>prevents tons of Excel and Office sales into labs from happening. From
>>a revenue POV that is like shooting themselves in the foot.
>>
>>
>>
>>>>Your are probably right. However, that's a "version control" scheme
>>>>that is totally foreign to me.
>>>
>>>
>>>So you'd expect that old DOS program to still work under Vista, would you?
>>
>>
>>Honestly I do not care because I won't let Vista into the business
>>here. I did run some in XP. Actually I have to because some of the old
>>filter design routines don't come any other way. The usual, a prof had
>>an excellent group that wrote all this. Then he got older, retired,
>>new prof came in, had other priorities on his mind and the project
>>withered away.
>>
>>If XP wouldn't have run it I would just downgrade to Win2K. The only
>>price a biz user really pays is that some stuff might then only be
>>driveable in plain vanilla modes.
>
>
> For your own use, you might want to look at vmware. There is a free
> "server" version and a pay "workstation" version. You can setup
> complete "virtual machines" running dos, windows 98, whatever you
> like. It's very slick. The virtual machines can actually access
> hardware, serial ports for sure maybe parallel ports too. I actually
> use this on linux, but you can run it under windows too.
>
Thanks, I forgot about that.
> For the customer stuff, I guess the win32 API is the way to go -
> assuming you can access this from visual basic (or VBA for office
> programs?). There are only a couple of functions you need IIRC. I
> might have a look at this myself - we have some custom windows
> software for collecting data from serially connected equipment (using
> modbus). It would be neat to be able to send someone a spreadsheet and
> have this talk to the devices "directly". But I don't know if this is
> really practical, and it will probably break on vista or office 2007
> etc.
>
Yes, exactly, it'll be customer stuff so has to run on whatever their IT
guys have blessed. And that will be the usual Windows/Office setup.
Sometimes MS thoroughly messes up, like with .NET or Vista, but with
Office they have (so far, knock on wood ...) not wrecked backward
compatibility. If they did the repercussions from the business community
would be severe. There is a lot more legacy stuff in business that
remains crucial and will be used for years to come. Many of their
financial files and routines date all the way back to the 80's.
--
Regards, Joerg
http://www.analogconsultants.com
Reply by Joerg●September 27, 20072007-09-27
The Real Andy wrote:
> On Thu, 27 Sep 2007 10:05:01 +0100, John Devereux
> <jdREMOVE@THISdevereux.me.uk> wrote:
>
>
>>Joerg <notthisjoergsch@removethispacbell.net> writes:
>>
>>
>>>Clifford Heath wrote:
>>>
>>>
>>>>Joerg wrote:
>>>>
>>>>
>>>>>40MB to get to the ports, wow ...
>>>>
>>>>
>>>>Getting to the ports might be all *you* wanted, but the runtime provides
>>>>an entire JIT compiler-interpreter and its runtime library, i.e. it's an
>>>>entire platform, and actually quite small for what it is.
>>>>
>>>
>>>I just don't understand why Billy's folks restricted mscomm.ocx. It
>>>prevents tons of Excel and Office sales into labs from happening. From
>>>a revenue POV that is like shooting themselves in the foot.
>>>
>>>
>>>
>>>>>Your are probably right. However, that's a "version control" scheme
>>>>>that is totally foreign to me.
>>>>
>>>>
>>>>So you'd expect that old DOS program to still work under Vista, would you?
>>>
>>>
>>>Honestly I do not care because I won't let Vista into the business
>>>here. I did run some in XP. Actually I have to because some of the old
>>>filter design routines don't come any other way. The usual, a prof had
>>>an excellent group that wrote all this. Then he got older, retired,
>>>new prof came in, had other priorities on his mind and the project
>>>withered away.
>>>
>>>If XP wouldn't have run it I would just downgrade to Win2K. The only
>>>price a biz user really pays is that some stuff might then only be
>>>driveable in plain vanilla modes.
>>
>>For your own use, you might want to look at vmware. There is a free
>>"server" version and a pay "workstation" version. You can setup
>>complete "virtual machines" running dos, windows 98, whatever you
>>like. It's very slick. The virtual machines can actually access
>>hardware, serial ports for sure maybe parallel ports too. I actually
>>use this on linux, but you can run it under windows too.
>>
>>For the customer stuff, I guess the win32 API is the way to go -
>>assuming you can access this from visual basic (or VBA for office
>>programs?). There are only a couple of functions you need IIRC. I
>>might have a look at this myself - we have some custom windows
>>software for collecting data from serially connected equipment (using
>>modbus). It would be neat to be able to send someone a spreadsheet and
>>have this talk to the devices "directly". But I don't know if this is
>>really practical, and it will probably break on vista or office 2007
>>etc.
>
>
> Office 2007 uses the same technology (VBA) but i just had a look and i
> cant see the com control object. It may still be shipped with office
> but its not immediately visible.
Was the same in '97. They do not allow the use of mscomm unless you also
buy a VB Pro license. At least that's how I understood it. Makes
absolutely no business sense on the part of Microsoft but then again a
lot of things don't make sense.
--
Regards, Joerg
http://www.analogconsultants.com
Reply by The Real Andy●September 27, 20072007-09-27
On Thu, 27 Sep 2007 00:48:17 GMT, Joerg
<notthisjoergsch@removethispacbell.net> wrote:
>Robert Adsett wrote:
>
>> In article <LovKi.9066$JD.147@newssvr21.news.prodigy.net>, Joerg says...
>>
>>>I am not a fan of .NET. It seems to have serious backwards compatibility
>>>issues. Case in point: New scope SW came, must have .NET. Installed 2.0,
>>>did not work. Inquired -> Must use 1.1 because 2.0 is not compatible.
>>>Great. <shaking head>
>>
>>
>> That appears to be Microsofts latest approach to solving version
>> dependancy issues. Just run a separate copy of every version. So if
>> you have a program using version 1 and another program using version 2
>> you get both copies in memory.
>>
>> It appears they've given up on the idea of actually getting it right. I
>> don't know if it's a reasoable approach but it sure rubs the wrong way.
>>
>
>ROFL! That was a good one. But it sure looks like it. Now if it was only
>.NET that would be one thing. The world would keep spinning without it.
> However, it seems there is now an "oh s..t" experience even with Vista.
>
>Anyhow, I have become very careful WRT adopting all this newfangled
>stuff from up there. Ordered a new desktop today. With XP. Surprisingly
>the sales guy at the small biz desk told me right off the bat before I
>had even brought it up "And you want XP on there, right?"
>
>It's not that I am dissing MS for everything. They did produce some nice
>and useful SW packages. Office being one of them, but also MS-Works.
>
>
>> Just in case you were wondering why disk and memory requirements keep
>> climbing w/o bound.
>>
>
>Bloat without bounds. Funtionality doesn't grow in proportion though.
>This whole problem with RS232 into spreadsheet was a non-issue in the
>DOS days. I used MS-Works. It had a built-in terminal program that could
>pipe in the data, a spreadsheet, a word processor and a database. So
>when I wanted to recreate and decode a datastream out of my logic
>analyzer (to diagnose ADC distortion effects) I grabbed a serial cable,
>plugged it in, and bingo. No .NET, no Active-X, no DLL hassles. It
>simply worked.
Yes, but back in the DOS days there was no braodband, and there was no
fancy monitors and digital cameras. there was no CD's (maybe just) and
no MP3's. There was no portable music players and skype. There was
text based word processors and dot matrix printers. Monochrome screens
(4 colours if you were lucky) and speakers that beep instead of
playing music.
Now tell me functionality has not increased.
>Heck, if I have my druthers one day I may just go back to that MS-Works
>program. It's still here, on a 5-1/4 floppy. I wonder if the COM ports
>can be addressed from a DOS window.