Am I mistaken, or was .NET originally offered only as a "subscription"?

[j***@gmail.com]

For whatever reason, I remember thinking it might be nice to try to move to VB.Net many years ago, but part of what turned me off was the thought that I could no longer "own" the development program the way I owned VS6, but instead had to subscribe to it.

Perhaps I was wrong then. It appears that now this is not the case.

[Mayayana]

I don't think it was ever a subscription. But if that
was the only reason you hesitated then you might
want to read up on it. There are lots of pros and
cons comparing VB to VB.Net. And now with MS
pushing Metro apps, the landscape is dramatically
changing. Which tools make sense will depend on
what you're wanting to do.


| For whatever reason, I remember thinking it might be nice to try to move
to VB.Net many years ago, but part of what turned me off was the thought
that I could no longer "own" the development program the way I owned VS6,
but instead had to subscribe to it.
|
| Perhaps I was wrong then. It appears that now this is not the case.

[j***@gmail.com]

Post by Mayayana
I don't think it was ever a subscription. But if that
was the only reason you hesitated then you might
want to read up on it. There are lots of pros and
cons comparing VB to VB.Net. And now with MS
pushing Metro apps, the landscape is dramatically
changing. Which tools make sense will depend on
what you're wanting to do.

I may be completely wrong, but I remember, at the time, that there was a lot of hand-wringing about MS moving to a "subscription only" sales model and how it was scary to be dependent on an internet connection and successful handshaking any time you wanted to fire up your new VB environment to do work.

That was many years ago, and looking at what MS is offering now, it appears that you can simply purchase VS2013, or have, for free, the Visual Community suite.

But you bring up another very good reason I've always held off investigating or pursuing moving to VS.Net. The incompatibility between that and my familiar VB6.

I'm looking to update to something new because I am having increasing problems trying to get new VB6 (or update old VB6) programs to play well with Win 7 systems. (I should ask specific questions in a different thread).

So I guess, to hijack my own thread, what do you folks recommend as a forward-path for an old VB6 programmer? I'm as lazy as the next guy, comfortable with VB6, but seem to be running into problems that seem as though they may only be resolved by finally moving away from VB6.

[GS]

Perhaps you should describe the 'problems' you're getting so folks here
can provide help! (My VB6 apps work just fine up to Win8.1)

[Mayayana]

As Garry asked, what are the problems?
The only showstopper I know of is 64-bit.
I have an Explorer Bar I can't install on
Win64 because it runs in the Explorer process.
And security can be a bit of a headache. Aside
from that I haven't had problems. VB6 is still one
of the most widely compatible off all tools, running
on virtually all current Windows systems with no
added support files necessary.

[GS]

Post by Mayayana
As Garry asked, what are the problems?
The only showstopper I know of is 64-bit.
I have an Explorer Bar I can't install on
Win64 because it runs in the Explorer process.
And security can be a bit of a headache. Aside
from that I haven't had problems. VB6 is still one
of the most widely compatible off all tools, running
on virtually all current Windows systems with no
added support files necessary.

Is that Windows Explorer or Internet Explorer? (I have a file manager
app that has its own builtin file explorer that, so far, works fine up
to Win8.1)

[Mayayana]

| Is that Windows Explorer or Internet Explorer? (I have a file manager
| app that has its own builtin file explorer that, so far, works fine up
| to Win8.1)
|

I use it in Windows Explorer, but actually the
two can't be fully separated. What I wrote is
not a file explorer but an Explorer Bar. It's a
shell extension. You can find the standard ones
in folder windows under View -> Explorer Bar.
I wrote my own with XP to replace the custom
folder.htt that I used in Win98.

http://www.jsware.net/jsware/jsfv.php5

It works in XP and Win7, but 32 shell extensions
can't run in 64-bit processes. Originally I think
Win7-64 used 32-bit Explorer and IE by default,
but that's no longer true.

[GS]

Post by Mayayana
Originally I think
Win7-64 used 32-bit Explorer and IE by default,
but that's no longer true.

Yes.., I discovered this when I installed TextPad x64 on my Win7 Pro
machine and met with weird behavior from the context menu. Otherwise,
my file manager app automates TextPad regardless of x-bit without issue
and so the installer uses whatever the OS x-bit is when users select
that option during setup!

[j***@gmail.com]

Post by Mayayana
As Garry asked, what are the problems?
The only showstopper I know of is 64-bit.
I have an Explorer Bar I can't install on
Win64 because it runs in the Explorer process.
And security can be a bit of a headache. Aside
from that I haven't had problems. VB6 is still one
of the most widely compatible off all tools, running
on virtually all current Windows systems with no
added support files necessary.

OK. Here goes :)

I've written a number of programs that access data on other computers on our network.

Whenever one of my VB6 programs, running on a Win 7 machine, reads any file on another Win 7 machine, that file is, for some reason, "locked" for a very long time after the file has already been read.

This interferes with other programs reading or writing those files in a timely manner.

Since the purpose of these programs is to gather data continuously, and then allow that data to be accessed and displayed by other programs on various workstations in the system, this extended "lock time" is a serious problem.

It seems to take several minutes for a file that's been read by one of the Win 7 machines to become accessible again to to other machines on the network.

However, when I run these same VB6 programs on an XP machine, their reading of these same files, off of the same win 7 machine, DOESN'T cause the files to be locked for any period of time that I can see (just as we'd hope for).

So we can't run these programs on any win 7 machines without losing data due to the files being locked out for access by other machines for this excessive amount of time. Thus, I figure the VB6 file reading methods must interact badly with win 7 machines somehow. It's all very frustrating because it all works great when the "reading" machine is a win XP unit, but not when the "reading" machine is running Win 7.

There are some other issues as well, but that's just a start.

I keep thinking that if I used a different language, that was new and fully-supported, I wouldn't run into this.

[ralph]

Post by j***@gmail.com
However, when I run these same VB6 programs on an XP machine,
their reading of these same files, off of the same win 7
machine, DOESN'T cause the files to be locked for any period
of time that I can see (just as we'd hope for).

This is a problem with Windows 7 O/S and changing development tools is
unlikely to repair it.

"This issue occurs because of changes that were made in the Redirected
Drive Buffering Subsystem (Rdbss.sys) regarding the use of new oplocks
and the way it handles references to remote executable files."

http://support.microsoft.com/kb/2687753

In the past while 'file sharing' on a peer-to-peer basis often worked
well enough and was quite useful, soon or later, in a production
environment something always went wrong. Thus always re-worked the
topology to support a single store/messaging system.

[j***@gmail.com]

I appreciate the help from everyone.

And I am encouraged by the love shown for good old VB6 here! I am lazy, relatively old, and don't really relish having to learn a new programming language because VB6 is like a comfortable old friend. I may not be all that great at it, having learned it all myself by trial and error and reading on forums like this, but it's been very productive for me and allowed me to write some rather sophisticated and complex programs. (Even if they're ugly inside).

I always say my programming style is shaped mostly by my lack of knowledge and expertise! :)



I'll read that KB article and see if it offers any help.

The bizarre thing to me is that while the files in question are "hosted" on a Win 7 64 machine, what matters seems to be the OS of the machine running my VB programs. If the machine running my VB6 program (which is reading the files) is running XP, there are no problems. But if the machine running my VB6 program is a Win 7 machine, then the "hosting" machine has these file lock issues.

So something about how XP presents the network file requests or handles the transfers keeps the Win 7 "host" from having problems. But when my VB6 program runs on a Win 7 machine, and reads those same files from the same Win 7 "host", then the "host" gags for some fairly long time afterwards.

I think you folks are giving me some good clues about this!

I also (just to add to the amusement) am constantly writing to these files from a Win 98 machine running a QuickBasic program that actually does the data gathering (because Win98 allows me to directly access the I/O bus, which I need to do to bit-bang the registers in the data acquisition boards).

The Win98 machine has no problems interacting with the Win 7 "host" except if one of the other Win 7 machines has tried to read one of the files recently.

Oh, the Joy. :)

Maybe I need to just install a Win XP machine to act as the "host". That might actually be just fine and solve all of these file locking problems in one fell swoop.

Thanks again, everyone!

[GS]

IMO, the NTJS on Win7/8 is not the same NTFS on XP/w2k! There are
definitely issues with how the 2 interact with each other, the former
having to do some 'back-pedalling' (I suspect) to deal with the x86
NTFS.

Whether moving the archive to a Win7 machine will resolve anything is
something you'll have to try. I've never done that so I can't confirm
any advantage, but it's an interesting idea!!!

[GS]

Typo...

IMO, the NTFS on Win7/8 is not the same NTFS on XP/w2k! There are

Post by GS
definitely issues with how the 2 interact with each other, the former
having to do some 'back-pedalling' (I suspect) to deal with the x86
NTFS.
Whether moving the archive to a Win7 machine will resolve anything is
something you'll have to try. I've never done that so I can't confirm
any advantage, but it's an interesting idea!!!

[Mayayana]

Hopefully someone like Ralph will see this. Myself,
I don't deal with any sort of networking issues.
If someone doesn't show up to help with that particular
issue you might try posting to:

microsoft.public.vb.general.discussion

It gets more traffic.

[GS]

I've found Win7 slow when accessing my XP machine's external hard
drive, as well as the internal hard drive. No problems, though, going
the other way. Seems like the x64 OSs have difficulties managing files
on x86 volumes. When I move the external drive from the XP machine to
the Win7 machine it runs normal speed. (This is a powered drive, not a
flash drive!) I don't have a 'server' as such as my network runs thru
my router and so can't speak to any network configs outside that.

My Win8.1 machine hasn't displayed any querky behaviors as yet, but
then I don't use it for much for anything other than travel access to
email/internet. I've never liked the behavior of the x64 file explorers
anyway so I use PowerDesk Pro. I can confirm, though, that files opened
on the Win7 machine don't get released immediately when the using app
quits or closes the file. In some cases I found a process kept the file
open and so had to terminate the process via Task Manager before the
other OS could do anything with the file.

Note that none of this had anything to do with VB6 apps!

[GS]

I've found Win7 slow when accessing my XP machine's external hard
drive, as well as the internal hard drive. No problems, though, going
the other way. Seems like the x64 OSs have difficulties managing files
on x86 volumes. When I move the external drive from the XP machine to
the Win7 machine it runs normal speed. (This is a powered drive, not a
flash drive!) I don't have a 'server' as such as my network runs thru
my router and so can't speak to any network configs outside that.

My Win8.1 machine hasn't displayed any querky behaviors as yet, but
then I don't use it for much for anything other than travel access to
email/internet. I've never liked the behavior of the x64 file explorers
anyway so I use PowerDesk Pro. I can confirm, though, that files opened
on the Win7 machine don't get released immediately when the using app
quits or closes the file. In some cases I found a process kept the file
open and so had to terminate the process via Task Manager before the
other OS could do anything with the file.

Note that none of this had anything to do with VB6 apps!