.NOT My Views

[Ken Halter]

Intergalactic ways and you dontNetters are more than just a little
scornful
about being trapped raking out the muck from your earth bound trenches. <<

For what it's worth, I still drive around in a 1981 DeLorean, which by
your standards would be old and obsolete. However, it still get's me the
chicks and way more attention that the new and improved gas guzzling SUVs
that were once considered the future of automobiles.

Again, new is not always better. They call it "classic" for a reason.
<g>

- Kev (who can do without the Back To The Future jokes)

Plus, that flux capacitor's a real conversation starter, eh? <g>

 

[mayayana]

You

can order a free windows xp sp2 cd from microsoft.com and it'll be delivered
to you anywhere in the world. It does not even require the delivery charges.

And it even says that once you install it, you can just pass the cd to
someone else.

Oooh. Mr. Bill is turning into a generous softie in his
old age. It might be fun to order a CD just so that I
can have the pleasure of legally giving Microsoft
software to someone who uses XP.

That reminds me of another reason I don't move to
..Net: The IDE won't run on Win98SE and I don't want
to switch to Windows Xtra Problems. I find it ironic
that most Java and .Net developer software runs only
in very limited environments. Yet both systems aim to
be thoroughly cross-platform.

(still havnt read the article) Mark is an expert. No problem with that.

What
he says, he definitely is talking with all his knowledge and worried about
all the resources that .net creates and the way it works currently. But is
he the only expert? What about all the great guys writing on msdn mag? Jeff
Richter, Don Box, etc.,. Are they not experts. Ofcourse u n me know that
they are. Are they not worried about .net consuming all these resources? I'm

sure some of them maybe. But they dont quit .net for this reason.

This all started with you asking why there might be
a problem writing dekstop software on .Net, but you
keep bringing it back to a question of whether .Net is
good out of that context. The whole point of Mark's article
is that there is a difference. He thinks .Net is fine for
web-based software. The point he's making is that
it's basically Microsoft's version of Java and doesn't
belong on the desktop. It may be true that new hardware
will solve the resource problem, but it's hard for me to see
that as progress. Needing 4 GB of RAM to write letters
and send email is a pitiful state of affairs.

Well said. You must be a very good dev. And I assure you that you can do all
this in .net too. There is a greate place for devs like you in the .net
community. You can play with wsock32.dll or anyother you like, and the
quality of debugging that you'll get with vs.net...

That's kind of you to say, but there wouldn't be much
value in using .Net if I'm just going to do it all unmanaged.
I'm surprised that I could write an email sender
using wsock32.dll without problems. That's good to know.
But then, I don't need the runtime or .Net if I do it that
way. I'd have a 50 KB program, with no dependencies,
if I do it in VB6. If I write the same thing in .Net it will
require the 25 MB runtime and probably compile
to about 10 MB!
Can you see how different that is from the point of
view of people writing desktop software? Maybe you're
doing ASP.Net on a corporate server, or something like
that. That is very different from someone writing small,
downloaded software to be used on all versions of
Windows. Avoiding an extra 500 KB of installer size
or an extra dependency that might cause incompatibility
problems on some systems is a significant improvement for
me. And since I can do what I want with a pre-installed
API that's on all Windows versions, it would be crazy
to switch. It would be like getting an 18-wheel truck to
transport my car to where I'm going. It makes much more
sense to just drive the car.

 

[Cor Ligthert [MVP]]

Al,

You point on one of the biggest problem in the use of all symbolic language
design.

The use of lower language parts in symbolic languages.

This is not new, it has been a problem in every symbolic program-language
when there were big upgrades.

This is one of the reason that I try to avoid those as hell and only use
them as they are really needed, not because of VB, just because of earlier
expiriences with that. (I know that it is often much nicer and customers
want that so it was almost impossible to completly avoid them in languages
before the Net languages)

I don't know how your programs are, however I have seen in past programs in
so called symbolic languages which where only the concatinating of lower
program calls.

Often those lower languages parts make it completely impossible to upgrade
(not only with VB again).

Probably will we all once have that lesson.

Very pretty is, that in VBNet there is much less need for Api's and in the
next 2005 version even much less.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/win32map.asp

(The call the Net and VisualBasic namespace classes here Api's probably to
make it regonizable I have it never seen done on another place).

It does not help you much with the problem, however I have never seen a
solution for that.

Why do you think that so many companies are still on Cobol?

The upgrade tools warns you how to do that in VV6-> VBNet by the way

However it stays a hell of a job.

Just my thougth,

Cor

 

[Stefan Berglund]

past was remembered and thats how such a greate framework came into being.
Other wise microsoft would also have become history like vb6.

Actually, that's a work in progress. Stay tuned for further developments...

 

[Cor Ligthert [MVP]]

Ralph,

To be fair to Karl, and to maintain true VBness, the "Integer" should
probably have remained 16-bit. A Long 32-bit, and they could have come up
with something new for a 64-bit thingy. Perhaps a 'Fred'. <g>

It is already written in this newsgroup however you missed it probably, and
with that what you write not using the performance of the newer computer
untill you change all your 'int' in 'Fred'

Cor

 

[Ralph]

Still searching for "Deprecations and code breakages" to C++.

What??? MS wouldn't do it as it would *BREAK* Office?
Come on!!! Re-write & re-test like the VB'ers!

The closest in C++ was when it changed out the the 'standard' class
libraries for the STL. However, class libraries continued to be available
(even today), and the only danger was when one attempted to mix them.

Which is sort of everyone's point - MS could have created 'managed'
extentions or migration path for VB - a la C++. They choose not to.

I still don't know if it was a deliberate marketing act to force more
developers to .NET, based on some insiders research knowledge, or just a
dumb mistake born from arrogance.

Perhaps, all three.

-ralph

 

[Al Reid]

Al,

You point on one of the biggest problem in the use of all symbolic language
design.

The use of lower language parts in symbolic languages.

This is not new, it has been a problem in every symbolic program-language
when there were big upgrades.

This is one of the reason that I try to avoid those as hell and only use
them as they are really needed, not because of VB, just because of earlier
expiriences with that. (I know that it is often much nicer and customers
want that so it was almost impossible to completly avoid them in languages
before the Net languages)

I don't know how your programs are, however I have seen in past programs in
so called symbolic languages which where only the concatinating of lower
program calls.

Often those lower languages parts make it completely impossible to upgrade
(not only with VB again).

Probably will we all once have that lesson.

Very pretty is, that in VBNet there is much less need for Api's and in the
next 2005 version even much less.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/win32map.asp

(The call the Net and VisualBasic namespace classes here Api's probably to
make it regonizable I have it never seen done on another place).

It does not help you much with the problem, however I have never seen a
solution for that.

Why do you think that so many companies are still on Cobol?

The upgrade tools warns you how to do that in VV6-> VBNet by the way

However it stays a hell of a job.

Just my thougth,

Cor

Cor,

You seem to have completely missed my point and latched onto a single sentence. With respect to API's, I was not referring to
Windows API's or low level API's. I am referring to high level API's used to integrate or extend other large scale applications.
One of them I use is to automate the capture process for a document management system, another is to automate a PDF conversion
application, for example. The API's are COM based. My point is that dotNet places a wrapper around them that sometimes works and
in other cases it introduces some unwanted side effects, along with a performance penalty. So I am going to have to stick with VB6
until the vendors release a dotNet version of the API's AND until there is some economic, performance or feature reason to mess with
already stable, robust and working code.

 

[Ralph]

Ralph,


It is already written in this newsgroup however you missed it probably, and
with that what you write not using the performance of the newer computer
untill you change all your 'int' in 'Fred'

Cor

True, and there in lies the delima - VB never had an 'int' (A 'named'
datatype who's size could change.). But changing 'types' has always been an
issue in VB - look at all the advice to use a 'Long' and not an 'Integer'.

I didn't miss anything, I am just pointing out that this is not a dotnet
issue - it is nothing new. People get confused because they think VB's
'Integer' is an 'int'. It isn't and never was. It's size matched-up once
upon a time, but it was never an 'int'.

It was an issue that was long due.

-ralph

 

[Abubakar]

.Net recruiting propaganda. As I recall, the last XP SP

was about 275 MB. A dial-up user can't download
something like that. Do you really think that people
send away for the service pack CDs? I don't know
anyone (among non-tech friends) who has ever
installed any service pack. I don't even know anyone

You are right about the size. Umm, non-tech friends I think maybe true. You
can order a free windows xp sp2 cd from microsoft.com and it'll be delivered
to you anywhere in the world. It does not even require the delivery charges.
And it even says that once you install it, you can just pass the cd to
someone else.

Did you read the article? Mark Russinovich is a
Windows programming expert. He's not saying
that .Net lacks features. He's saying that it's sloppy
with resources, especially in terms of RAM
requirements; so much so that trying to run the typical
number programs at the same time, on current hardware,

(still havnt read the article) Mark is an expert. No problem with that. What
he says, he definitely is talking with all his knowledge and worried about
all the resources that .net creates and the way it works currently. But is
he the only expert? What about all the great guys writing on msdn mag? Jeff
Richter, Don Box, etc.,. Are they not experts. Ofcourse u n me know that
they are. Are they not worried about .net consuming all these resources? I'm
sure some of them maybe. But they dont quit .net for this reason. They know
that hardware is getting better and .net is also getting better and what
they do, .net is going to allow them do it better. This is a shift from past
generation technologies to the next gen techs. This is expected. I think it
always happen. If this kind of changes dont happen, the world would be
advancing much slower. If you cant join them, beat them, or join them again

Yes, you seem to have a good grasp of English slang!
It is a crude usage, like one might hear in a bar between two
arguing drunks, but you used it correctly.

thanks. Btw why I used this here cuz I recalled that last time I read this
"slang" it was a discussion that Linus Torvalds was doing comparing Linux to
Minix (& I was talking about com in c++ and com in vb)

I enjoy the craft of perfecting code and I think that it
pays off in the long run. For instance, in VB, if
I want to send an email, at one extreme I could
automate Outlook. If I want to go deeper I can
use MAPI. Deeper still, I can use a winsock
OCX and code the whole operation. Or I can
use the system sockets library directly and skip the
OCX. Each step down requires more work to write
the code. But each step down is also more efficient,
with less dependencies and a smaller memory
footprint. I can load 40 MB(?) of libraries to use
Outlook, with 1 KB of code, or I can load the 40 KB
wsock32.dll and write 30 KB of code. There are tradeoffs
both ways, so it's nice to have the choice. Some
people would say that my 30 KB of code is sloppy,
but that's only because they don't see the millions
of operations that are running invisibly, and the
multiple megabytes worth of libraries being loaded,
when they run something like:
"System.Mail.SendAnEmail".

Well said. You must be a very good dev. And I assure you that you can do all
this in .net too. There is a greate place for devs like you in the .net
community. You can play with wsock32.dll or anyother you like, and the
quality of debugging that you'll get with vs.net, specially the 2k5 version
thats going to be here next month, its just unmatched with any thing you
have ever seen. Guaranteed! (oh and the ide wont crash-n-burn if u r in a
middle of subclassed call and an error is raised _).

-Ab.
http://joehacker.blogspot.com

 

[Abubakar]

Yes. Simply open the project in VB 2005 and compile. Unfortunately some
of

the APIs like 'System.Web.Mail' have been deprecated, but the code should
still compile and work.

yes and proper warnings are given that what alternate api you can use. I
have upgraded a lot of my projects to 2k5 beta 2.

Ab.
http://joehacker.blogspot.com

 

[Abubakar]

"Those who cannot remember the past are condemned to repeat it."

--George Santayana

You'll understand it someday. Until then, good luck. You'll need it.

past was remembered and thats how such a greate framework came into being.
Other wise microsoft would also have become history like vb6.

Ab.
http://joehacker.blogspot.com

 

[Abubakar]

If you want another analogy, consider the programs I've developed with my

marriage to VB 6 my "children". Now M$ has suggested I divorce from VB6 to
enter into another marriage with .NET. Good marriages take time and work
and don't always work out for the better. I don't want a new marriage, I am
happy with the one I am in...and I certainly don't appreciate being told my
"children" are obsolete, along with my "wife" because they think the new
marriage would be better for me. What made my marriage to VB 6 won't work
for .NET. Plain and simple.

So, there it is. ;-)

Hey I also believe in having one marriage for life But .net is a diff
case

Ab.
http://joehacker.blogspot.com

 

[Abubakar]

As RR said,, its about exploring and getting ready for tomorrow's technology
today. We dont run away from new stuff.

Ab.
http://joehacker.blogspot.com

 

[Abubakar]

I have adjusted the time zone. I think its ok now.

Thanks,

Ab.

 

[Abubakar]

You are being dishonest. Why don't you post the code to do the

equivalent in the currently shipping version of VS.NET (which is v.2003)

the software company I work for got a smart devices project based on the
prototype I made in vs.net 2k5 beta 2. We have convinced our customer that
if they agree on the 2k5 solution we can do the project sooner and it'll
better than 2k3 (for us n for them). Plus u also have a go-live license for
it.

Dim oFile As FileStream = New FileStream(sFileName, FileMode.Open,
FileAccess.Read, FileShare.Read)
Dim oReader As StreamReader = New StreamReader(oFile)

Dim s As String = oReader.ReadToEnd

oReader.Close()
oFile.Close()

nope:

Dim sr as StreamReader(filename);
Dim contents = sr.ReadToEnd();
sr.Close()

pretty simple n small imo.

Ab.
http://joehacker.blogspot.com

 

[Gary Nelson]

Ralph,

I was refering to what you said:

How can you not be dependent on the size of the thing if you are reading
from a binary file? Even if you had been taught otherwise.

Gary

 

[Gary Nelson]

Herfried,

Mhm... I have rarely touched ASP.NET, so I am not able to confirm that.
I assume that the language remained stable but technologies changed.

The whole structure of the code behind modules for ASP.NET pages has
changed, amongst other things.

Gary

 

[VB6 User]

see this

MSDN Webcast Security Best Practices Protecting Your Intellectual Property
(Level 200)
http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032280205&Culture=en-US

..NUT ha ha ha

 

[Karl E. Peterson]

(still havnt read the article)

Seems clear that you really owe that much to yourself.

Mark is an expert. No problem with
that. What he says, he definitely is talking with all his knowledge
and worried about all the resources that .net creates and the way it
works currently. But is he the only expert? What about all the great
guys writing on msdn mag? Jeff Richter, Don Box, etc.,. Are they not
experts. Ofcourse u n me know that they are. Are they not worried
about .net consuming all these resources? I'm sure some of them
maybe. But they dont quit .net for this reason. They know that
hardware is getting better and .net is also getting better and what
they do, .net is going to allow them do it better.

Whoa! Think about that. What _do_ Richter, Box, et al, actually _do_, hmmm? (Okay,
I'll spell it out: They teach.) In their business, change for change's sake _is_ a
Good Thing!

 

[Karl E. Peterson]

The 'int' was defined in C as reflecting the natural size of integers
on the host machine. It was designed to be essentially 'sizeless' so
that code would be portable yet optimized.

I am _well_ aware of that historical difference between languages. MSBasic had a
fixed-size Integer, unlike some others.

"If you need a different type of data, create a new datatype!"

We suggested they restore the original definition of the keywords, but they balked.
The ideal solution would've been to introduce new names for fixed sizes, and
something like SysInt for platform sized variables. That simple concession would've
done a _lot_ to show that they understood the issue of gratuitous incompatabilities.