MSWINSCK.OCX ver 6.0.98.16 won't work on Win2K 
Author Message
 MSWINSCK.OCX ver 6.0.98.16 won't work on Win2K

I have just spent TWO FRIGGING HOURS fixing an obscure bug with my UDP
Sender application.

I am currently building a new box with Win2K Pro on it instead of
Win98SE, which I am finally retiring as it is no longer powerful
enough to run either Firefox or Opera.

In the process of building the new box I have installed VB6 and
service pack 6B.

*************************************************************************

I also installed the following from the MS web site:

VB60SP6-KB926857-x86-ENU.msi
VB60SP6-KB957924-v2-x86-ENU.msi

*************************************************************************

Okay. Fine. Everything hunky dory. Connection to internet works. Email
works. NNTP works.

And then this morning I just happened to use my UDP Sender to send a
quick message to another PC running XP, and on my new PC I get "Error
10049 Address is not available from the local-machine"

I've never seen this error before.

After two hours of scratching my head, running the code in the IDE,
setting breakpoints, Googling for hints, putting the old drive back in
briefly, I finally decided to check the version of MSWINSCK.

Version on new PC: 6.1.98.16
Version on old PC (and on XP box): 6.1.97.82

So I replaced MSWINSCK.OCX with the 6.1.97.82 version and bingo!
Problem solved!

But now I am worried that the official updates I installed to VB6,
which must have updated that control, may have screwed up other
controls. Later today I'll run one of my apps to compare ALL version
numbers of OCXs on old and new machines, but this is very worrying.

Has anyone else experienced a VB6 problem after installing those
"security" updates?

Thanks.

MM



Fri, 02 Aug 2013 18:37:02 GMT  
 MSWINSCK.OCX ver 6.0.98.16 won't work on Win2K

Additional information:

http://www.tek-tips.com/viewthread.cfm?qid=1546795

describes several problems people have experienced after running the
"cumulative update rollup 957924", including a problem with
MSWINSCK.OCX that I also had after the 10049 error.

Others, too, are asking the same question: What has the Update done to
f**k up other stuff?

Is it possible to COMPLETELY uninstall VB6 and all service packs and
OCXs, so that I can re-do the installation and OMIT the cumulative
update rollup?

Or do bits and pieces stay behind all over the place?

MM



Fri, 02 Aug 2013 20:09:30 GMT  
 MSWINSCK.OCX ver 6.0.98.16 won't work on Win2K
For anyone searching the newsgroups, the OP posted the following in a
different thread:

This is important for anyone who has installed the cumulative update
rollup.

I found this:

http://www.*-*-*.com/

Scrolling down, you get to the Comments:

<quote>
Indeed, by searching the MSKB, I found another later hotfix:
http://www.*-*-*.com/
Download at:
http://www.*-*-*.com/
</quote>

I reinstated MSWINSCK.OCX 6.1.98.16, verified that the bug was back,
then I downloaded the above hotfix and installed it. This updated
MSWINSCK.OCX to 6.1.98.17 and the bug has gone!

Downloading the hotfix, however, is a bit convoluted. For some reason,
Microsoft has password-protected it and the password changes every few
days. So you have to send them your email address, then they send you
a link to the hotfix plus the password to use. Why on earth all this
extra-cautious behaviour over something they{*filter*}ed up, beats me.

Anyway, it works again now.

MM



Fri, 02 Aug 2013 21:16:28 GMT  
 MSWINSCK.OCX ver 6.0.98.16 won't work on Win2K


Quote:
>For anyone searching the newsgroups, the OP posted the following in a
>different thread:

I posted it separately because it's too important to get lost
(overlooked) in that first one.

MM



Sat, 03 Aug 2013 01:10:04 GMT  
 MSWINSCK.OCX ver 6.0.98.16 won't work on Win2K


Quote:
> I have just spent TWO FRIGGING HOURS fixing an obscure bug with my UDP
> Sender application.

I just can't resist.   Please take this with a grain of salt.  <g>

In light of your recent thread on getting a list of available references and
my comment about being less dependent on DLLs and OCXs, if you had been
using WinAPI functions for this instead of the WinSock OCX, you'd likely
have never had this problem.

I just found this too ironic to not make some kind of comment.

--
Mike



Sat, 03 Aug 2013 06:24:28 GMT  
 MSWINSCK.OCX ver 6.0.98.16 won't work on Win2K


Quote:



>> I have just spent TWO FRIGGING HOURS fixing an obscure bug with my UDP
>> Sender application.

>I just can't resist.   Please take this with a grain of salt.  <g>

>In light of your recent thread on getting a list of available references and
>my comment about being less dependent on DLLs and OCXs, if you had been
>using WinAPI functions for this instead of the WinSock OCX, you'd likely
>have never had this problem.

>I just found this too ironic to not make some kind of comment.

This is just stupid. You might as well say if Fred hadn't been driving
that day, the collapse of the building on his way to work wouldn't
have mattered to him.

Your <g> is rejected, sir!

MM



Sat, 03 Aug 2013 14:55:36 GMT  
 MSWINSCK.OCX ver 6.0.98.16 won't work on Win2K
| >I just found this too ironic to not make some kind of comment.
|
| This is just stupid. You might as well say if Fred hadn't been driving
| that day, the collapse of the building on his way to work wouldn't
| have mattered to him.
|

  It's exactly the point. Problems with controls,
especially cross-Windows-versions, are common.
And in many cases the direct code is more flexible.
It just requires some initial work to get that
functionality. (Good examples are the messages
left out of the Listbox control [even though that's
an "intrinsic" control] and the fact that
a RichTextBox control is stuck using v. 1 of RichEdit.
Also, there was such a mixup with the files used
in RTB that the PDW had to be coded to specifically
deal with that.)

  I've never actually used the winsock control. When
the time came that I needed winsock functionality,
straight code didn't seem to be less confusing than
the winsock OCX methods. As is so often the case, I'm
guessing the winsock control is just there to avoid
awkward data types and CopyMemory calls.

   So a better analogy than the collaapsing building
might be that Fred
bought an Acme Car Security, Starter & Garage Door
Opener kit. If he had just stuck with using his arm
to open the garage door, and turning the key himself
to start the car, it would require more effort to get
to work, but he would also avoid a lot of superfluous
complexity. He wouldn't risk standing in his
driveway, unable to get to work because every time he
tries to open the garage door with his Acme remote
control his car alarm goes off....
  And Acme went out of business... And their user's
manual is 45 pages but only 1 1/2 of those are in
English...

   The collapsing building is pure coincidence. What
you're doing is choosing to install an Acme gizmo.
That may seem like the simpler route at the time:
The Acme guy is right there and he can have your
Jetsons Magnum II controller model installed within
the hour. "What's not to like?", as the marketers say.
Nevertheless, the Acme controller is still an extra
add-on. It's still a choice you're making. The extra
wrapper *might* be easier in the long run. But it
would be foolish not to recognize that you are also
adding complexity and "brittleness".



Sat, 03 Aug 2013 22:36:31 GMT  
 MSWINSCK.OCX ver 6.0.98.16 won't work on Win2K


Quote:




>>> I have just spent TWO FRIGGING HOURS fixing an obscure bug with my UDP
>>> Sender application.

>>I just can't resist.   Please take this with a grain of salt.  <g>

>>In light of your recent thread on getting a list of available references
>>and
>>my comment about being less dependent on DLLs and OCXs, if you had been
>>using WinAPI functions for this instead of the WinSock OCX, you'd likely
>>have never had this problem.

>>I just found this too ironic to not make some kind of comment.

> This is just stupid. You might as well say if Fred hadn't been driving
> that day, the collapse of the building on his way to work wouldn't
> have mattered to him.

> Your <g> is rejected, sir!

No, it's exactly the point, as Mayayana even point out.  You're just being
blind or an ass now. I'm not sure which.


Sat, 03 Aug 2013 23:41:01 GMT  
 MSWINSCK.OCX ver 6.0.98.16 won't work on Win2K


Quote:







>>>> I have just spent TWO FRIGGING HOURS fixing an obscure bug with my UDP
>>>> Sender application.

>>>I just can't resist.   Please take this with a grain of salt.  <g>

>>>In light of your recent thread on getting a list of available references
>>>and
>>>my comment about being less dependent on DLLs and OCXs, if you had been
>>>using WinAPI functions for this instead of the WinSock OCX, you'd likely
>>>have never had this problem.

>>>I just found this too ironic to not make some kind of comment.

>> This is just stupid. You might as well say if Fred hadn't been driving
>> that day, the collapse of the building on his way to work wouldn't
>> have mattered to him.

>> Your <g> is rejected, sir!

>No, it's exactly the point, as Mayayana even point out.  You're just being
>blind or an ass now. I'm not sure which.

No, you're both being stupid or obtuse, I'm not sure which. I used the
winsock control. Microsoft broke it with one of their updates. Then
they fixed it with a hotfix. Problem solved. End of story.

MM



Sun, 04 Aug 2013 02:20:06 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. mswinsck.ocx VB6(SP5) - progs won't work with WinXP

2. mswinsck.ocx VB6(SP5) - progs won't work with WinXP

3. Date time picker (Mscomct2.ocx) dont work on win 98

4. AppActivate doesn't work with Win 98 SE

5. Default printer fonts for Win '95/98 not working

6. OCX won't register under 95 but will in 98/NT

7. Win API Call not working in vb.net app distributed to WIn 98

8. Can't get MSWinsck.OCX to work on server

9. VB4.0 - 16 bit ver for Win 3.11 ???????

10. script works under 98, not under win2k

11. Total bytes downloaded varies using mswinsck.ocx (6.0.89.88) on win2k

12. HELP - Error 50003 - VB5, Win 95, Win 98, Win NT

 

 
Powered by phpBB® Forum Software