Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #2192 > unrolled thread

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

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  Am I mistaken, or was .NET originally offered only as a "subscription"? jsigmo@gmail.com - 2014-12-20 11:35 -0800
    Re: Am I mistaken, or was .NET originally offered only as a "subscription"? "Mayayana" <mayayana@invalid.nospam> - 2014-12-20 14:40 -0500
      Re: Am I mistaken, or was .NET originally offered only as a "subscription"? jsigmo@gmail.com - 2014-12-20 11:53 -0800
        Re: Am I mistaken, or was .NET originally offered only as a "subscription"? GS <gs@somewhere.net> - 2014-12-20 18:32 -0500
        Re: Am I mistaken, or was .NET originally offered only as a "subscription"? "Mayayana" <mayayana@invalid.nospam> - 2014-12-20 22:01 -0500
          Re: Am I mistaken, or was .NET originally offered only as a "subscription"? GS <gs@somewhere.net> - 2014-12-20 22:08 -0500
            Re: Am I mistaken, or was .NET originally offered only as a "subscription"? "Mayayana" <mayayana@invalid.nospam> - 2014-12-20 22:34 -0500
              Re: Am I mistaken, or was .NET originally offered only as a "subscription"? GS <gs@somewhere.net> - 2014-12-21 04:46 -0500
          Re: Am I mistaken, or was .NET originally offered only as a "subscription"? jsigmo@gmail.com - 2014-12-21 10:34 -0800
            Re: Am I mistaken, or was .NET originally offered only as a "subscription"? ralph <nt_consulting@yahoo.com> - 2014-12-21 18:57 -0600
              Re: Am I mistaken, or was .NET originally offered only as a "subscription"? jsigmo@gmail.com - 2014-12-21 20:52 -0800
                Re: Am I mistaken, or was .NET originally offered only as a "subscription"? GS <gs@somewhere.net> - 2014-12-22 01:24 -0500
                  Re: Am I mistaken, or was .NET originally offered only as a "subscription"? GS <gs@somewhere.net> - 2014-12-22 01:25 -0500
            Re: Am I mistaken, or was .NET originally offered only as a "subscription"? "Mayayana" <mayayana@invalid.nospam> - 2014-12-21 18:08 -0500
            Re: Am I mistaken, or was .NET originally offered only as a "subscription"? GS <gs@somewhere.net> - 2014-12-21 19:52 -0500
            Re: Am I mistaken, or was .NET originally offered only as a "subscription"? GS <gesansom@netscape.net> - 2014-12-21 19:51 -0500

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

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.

[toc] | [next] | [standalone]

#2193

  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. 

[toc] | [prev] | [next] | [standalone]

#2194

On Saturday, December 20, 2014 12:40:30 PM UTC-7, Mayayana wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#2195

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)

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#2196

   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.

[toc] | [prev] | [next] | [standalone]

#2197

>    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)

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#2198

| 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. 

[toc] | [prev] | [next] | [standalone]

#2199

> 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!

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#2201

On Saturday, December 20, 2014 8:01:51 PM UTC-7, Mayayana wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#2202

On Sun, 21 Dec 2014 10:34:36 -0800 (PST), jsigmo@gmail.com wrote:


>
>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.

[toc] | [prev] | [next] | [standalone]

#2206

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!

[toc] | [prev] | [next] | [standalone]

#2207

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!!!

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#2208

Typo...

  IMO, the NTFS 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!!!

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#2203

  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.

[toc] | [prev] | [next] | [standalone]

#2204

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!

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#2205

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!

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web