Excel-RS232 via Cheapcomm: Where?
in [Embedded]
|
Prev: About NXP TDA8007 (smart-card chip controller)
Next: GNUARM multiple definition of AT91F_AIC_ConfigureIt
From: Robert Adsett on 26 Sep 2007 19:03 In article <LovKi.9066$JD.147(a)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. Just in case you were wondering why disk and memory requirements keep climbing w/o bound. Robert -- Posted via a free Usenet account from http://www.teranews.com
From: Joerg on 26 Sep 2007 20:30 Clifford Heath wrote: > Joerg wrote: > >> 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> > > > You're missing the point entirely. For the first significant time that MS > has done it, you can have all 3 versions of the .NET runtime installed at > the same time without them interacting, and whatever products or components > you install get the same version isolation. It takes more disk space > (though not that much, it's only 40Mb or so), but it does avoid DLL hell. > 40MB to get to the ports, wow ... > I've heard this whine from you multiple times, presumably all relating to > the single occurrence, but it was *your* mistake because you installed the > wrong version. Perhaps your supplier didn't give you enough info, but that > doesn't make it MS's mistake. > I've heard the same whine from hardcore SW guys, except that some of them used words I could not repeat in public. > 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". -- Regards, Joerg http://www.analogconsultants.com
From: Joerg on 26 Sep 2007 20:48 Robert Adsett wrote: > In article <LovKi.9066$JD.147(a)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. 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. -- Regards, Joerg http://www.analogconsultants.com
From: Clifford Heath on 26 Sep 2007 21:02 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. > 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? 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. Clifford Heath.
From: Joerg on 26 Sep 2007 21:14
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. > 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 ;-) -- Regards, Joerg http://www.analogconsultants.com |