Re: Strange problem when using a class module in VBScript


"Ragnar Midtskogen" <ragnar_ng@xxxxxxxxxxxxxx> wrote in message
news:%23HmVztTuFHA.460@xxxxxxxxxxxxxxxxxxxxxxx
> Ralph,
>
> I realize that all OSes and software platforms have problems but I think
> that UNIX/Linux and Java has fewer
> problems and is faster than Windows and VB/VBA. It is no accident that IBM
> is using that combination.
> Even Microsoft is acknowledging this in developing their .NET platform,
> which is essentially their version of Java.
>
> Windows/VB/VBA is a quick and dirty way to develop and as long as you are
> careful when you distribute your software to avoid DLL hell. Performance
is
> slower and resource use is a lot higher, mainly because of the Registry
> which becomes bloated as time goes.
> The Wintel platform has been a series of compromises to preserve backwards
> compatability since the 8088 microprocessor and it's addressing
limitations.
> Why do it simple and elegantly when you can do it the Microsoft way?
>
> Take your pick
>
> Ragnar
>
> "Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
> news:-e2dneklAsJvFrrenZ2dnUVZ_s-dnZ2d@xxxxxxxxxxxxxxx
> >
> > "Ragnar Midtskogen" <ragnar_ng@xxxxxxxxxxxxxx> wrote in message
> > news:O7keVINuFHA.2568@xxxxxxxxxxxxxxxxxxxxxxx
> >> Thank you Chris,
> >>
> >> I have always had the project set to No Compatablity and never had any
> >> problem.
> >> I have probably updated this dll a couple of dozen times and it has run
> > fine
> >> on three different servers, starting with NT4 and progressing to 2003.
> >> It is called from some VBScript files to run some data feeds once a
day.
> >>
> >> It looks like I will have to stay with the debug version and just run
it
> > as
> >> a regular exe file.
> >> I don't want to start messing with this compatability issue, the dll
> >> contains two other classes that is used by a Web site so I can't afford
> >> to
> >> take chances with that.
> >>
> >> I think we should all be using UNIX/LINUX.
> >>
> >> Ragnar
> >>
> > <snipped>
> >
> > Ragnar,
> >
> > What if I told you that forking twice and throwing away two good
processes
> > to create a service sounds pretty dumb, and I don't want to mess with
this
> > forking issue, so I'll just stick with this executable test thingy?
> >
> > Which one of us sounds sillier?
> >
> > Each platform has its issues. You either learn to mess with them or
hack.
> >
> > -ralph
> >
> >

Actually the JAVA platform is Unix's version of the VB platform. .NET is
merely an expansion of that concept to the 'whole box' of which Unix is
rapidly attempting to match.

COM was a very successful solution to providing "binary" access to shared
libraries and applications. Yes, it has flaws, but the rigors of
implementing a COM solution is little different than adapting to the nuances
of some vendor's CORBA solution. (and quite a bit lighter on the pocket
book.)

JAVA is a quick and dirty way to implement a solution as long as you accept
the performance penalty. (Sorry but you're wrong about Java being faster.
Unix boxes are often faster, but it has nothing to do with Java. Java is
slooowww on a Windows box.) Also you must accept that whatever you write
will be as fast as it will ever be.

The Windows Registry since Win2k has far less effect on performance than is
often imagined. (very earlier versions, yes). It is best not to make
sweeping comments concerning a platform you know little about. It often
comes across as simple "sour grapes".

And I agree with you that to become proficient on a Windows Platform it is
best to do it Microsoft's way. Duh! Simplify and elegance is in the eye of
the beholder. Microsoft's way be frustrating at times, but so is whatever
"Unix" you are chewing on at the moment.

There are quite a few Microsoft-features that are quite elegant when
compared to alternatives. Most "modern" UNIX features wouldn't even exist if
they hadn't had the Windows model to inspire and copy.

Unix has a great deal going for it. (I was a Unix developer for 10 years)
But has essentially suffered and continues to suffer from the wide variety
of versions and tools (usually very expensive) available. While the world is
'open' before it (pun intended) in reality most implementations becomes just
as embroiled in a single vendor solution. If you roll 'r own - you just
become your own vendor.

"But let's not quarrel", as Duffy used to say. Differences is what makes
Horse Races. In some races my 'favorite' will win, in another your
'favorite' will win. And in keeping with an equestrian analogy - why beat a
dead horse? There are two major operating systems available to us. So far
the market place seems to have developed a niche for both.

-ralph


.

Relevant Pages

  • Re: COBOL to Java conversion
    ... experience and at least one of them is currently working in Java. ... platform, but also to change the language to be Java. ... I have not personally seen or worked on a Unisys conversion to Unix, ...
    (comp.lang.cobol)
  • Re: OT Java, C#, C++
    ... would you use Java or C++ - or something else? ... locked to 'Windows only'. ... platform' _and_ Windows Only lockin. ... I notice that it also supports the Glade interface designer. ...
    (comp.lang.cobol)
  • Re: OT Java, C#, C++
    ... would you use Java or C++ - or something else? ... locked to 'Windows only'. ... platform' _and_ Windows Only lockin. ... occasionally bypass the API and P/Invoke straight to the Win32 API. ...
    (comp.lang.cobol)
  • Re: OT Java, C#, C++
    ... would you use Java or C++ - or something else? ... locked to 'Windows only'. ... platform' _and_ Windows Only lockin. ... occasionally bypass the API and P/Invoke straight to the Win32 API. ...
    (comp.lang.cobol)
  • Re: Questions about the behavior for argv(0)
    ... manner not compatible with Unix system configuration and/or ... the Windows programmer wishes to continue to ... configuration of a Unix standard environment. ... porting "platform specific" code is hard, ...
    (microsoft.public.vc.mfc)