Converting projects to VB.NET

[Mike Mitchell]

On 30 May 2002 12:53:07 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
wrote:

>uh-huh.
>Keep paddling.

Hey, come on in! The water's fine! And I have learned how to manhandle
the crocodiles!

MM

[Mike Mitchell]

On 30 May 2002 13:34:35 -0800, "Jay Glynn" <jlsglynn@hotmail.com>
wrote:

>FWIW that "feature" disappeared with Windows ME.

And a very good reason why I, on taking delivery of my PC with ME
preinstalled, immediately ran FDISK and installed Windows 98SE. I
chucked the ME recovery disk in the trash.

MM

[Bob]

In article <3cf6a2c3@10.1.10.29>, "Kunle Odutola" <kunle.odutola@<REMOVETHIS>
okocha.freeserve.co.uk> says...
>
> "W.E.(Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
> news:3CF6881D.6127A981@netzero.net...
>
> > That will never happen. It would mean exposing some of their beloved
> > "Top Secret" APIs, formats, and protocols. A major part of their
> > illegal practices involves reserving significant parts of the OS for
> > use by Micro$oft products only.
>
> Rubbish. Any half decent developer with a debugger can spot undocumented API
> calls in a heartbeat. That so few instances of undocumented API ussge have
> been found pours cold water on your baloney.
>
> As usual....
>
> Kunle
>
> PS I support legal moves to outlaw the practice though.
>

Kunle,

I'm not so sure I agree 100% with your PS. I am familiar with at a least one
OS that has undocumented APIs, into various pieces of the software. One
example might be something like APIs that bypass certain time-consuming
routines. The benefit would be significantly higher performance in certain
critical areas. The price would be corrupted data or if you are lucky, the
equivalent of a BSOD, if it's not done correctly. From a system integrity
point of view, I'd prefer that only the OS vendor use those APIs. The good
news is that in the instances I am familiar with, certain levels of privilege
are required to use these APIs. As such, I would be suspicious of, say an
accounting package that required special privs to run.

Bob

[Bob]

In article <3cf6a9bf@10.1.10.29>, nospamjrbutler@btinternet.com says...
>
> "turbofish" <junk@turbofish.com> wrote in message
> news:MPG.175f54b8367891a2989680@news.devx.com...
> > Well, most of what I do is either desktop accounting programs/office
> > automation with very little network use. Maybe a maximum of 5-7 clients on
> one
> > database at a time. There are a LOT of programs and offices out there just
> > like this. .NET focuses on the SQL server. In fact, every book I have on
> .NET
> > when it comes to covering database stuff, they won't even mention anything
> > less than SQL 2000.
> > It's a real shame that Microsoft has forgotten that not everyone has a
> need
> > for large scale database apps.
>
> I haven't used it, but what is wrong with the OleDB driver in .NET? Far as
> I've seen, it works the same ways as the sql server.net data provider I
> use....Is it slower or less capable? I'm curious, as I haven't seen any
> issues reported...and I might need to use an Access database for a
> customer's website, for an upcoming project....
>
> Rgds
> John Butler
>
John,

Supposedly, the OleDB driver in .NET is slower than the SQL driver because it
effectively sits on top of the SQL driver and hence adds another layer of
translation between the app and SQL. I have not read any hard figures as to
just what this penalty is.

Re: turbofish

The Beginning VB.Net book from WROX uses the OleDB calls in ADO.Net.

Bob

[W.E.(Bill) Goodrich, PhD]

In article <MPG.17613a2c73218c3a989701@news.devx.com>,
Bob <no@spam.com> writes:

> In article <3cf6a2c3@10.1.10.29>, "Kunle Odutola"
> <kunle.odutola@<REMOVETHIS> okocha.freeserve.co.uk> says...

> > "W.E.(Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
> > news:3CF6881D.6127A981@netzero.net...

> > > That will never happen. It would mean exposing some of their
> > > beloved "Top Secret" APIs, formats, and protocols. A major part
> > > of their illegal practices involves reserving significant parts
> > > of the OS for use by Micro$oft products only.

> > Rubbish. Any half decent developer with a debugger can spot
> > undocumented API calls in a heartbeat. That so few instances of
> > undocumented API ussge have been found pours cold water on your
> > baloney.

> > As usual....

> > Kunle

> > PS I support legal moves to outlaw the practice though.

> Kunle,

> I'm not so sure I agree 100% with your PS. I am familiar with at a
> least one OS that has undocumented APIs, into various pieces of the
> software.

So am I - Windows. Kunle the Troll is just up to his braindead games
again. He is pretending that he does not know that the issue of those
"secret" APIs was one of the major issues of the antitrust trial, or
that it was both proven (in that trial) and admitted by such minor
Micro$oft employees as Bill Gates and Jim Allchin. His pretense is
obvious, since he participated in earlier discussions of those facts.
He is hoping to get some sucker(s) to buy into his extrapolations from
false premises instead of paying attention to the facts - and to
provoke an amusingly emotional response by those who are aware of the
facts.

> One example might be something like APIs that bypass certain
> time-consuming routines. The benefit would be significantly higher
> performance in certain critical areas.

Exactly the sort of thing Micro$oft was caught at.

> The price would be corrupted data or if you are lucky, the
> equivalent of a BSOD, if it's not done correctly.

Which, of course, points out one of the major fallacies of his
argument - that "finding" the API does not give enough information to
allow safe usage. Another MAJOR fallacy is his pointless (and baseless)
claim that the number of such API calls found can be described as "so
few". For instance, Jim Allchin characterized the number of such secret
APIs in the .NET CLR as 1/3 of the total APIs therein.

> From a system integrity point of view, I'd prefer that only the OS
> vendor use those APIs.

That is where we significantly disagree. From that same point of view
(and those of relevant State, Federal, and international laws), I would
strongly prefer that the OS vendor fully document all such APIs rather
than reserve them for use by their non-OS products.

> The good news is that in the instances I am familiar with, certain
> levels of privilege are required to use these APIs.

The bad news is that some of the relevant APIs literally checked
whether the calling program was a Micro$oft product, and sabotaged the
results if it was not.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

[W.E.(Bill) Goodrich, PhD]

In article <3cf69b9c@10.1.10.29>,
"Mark Jerde" <jerde@sanspamcompuserve.com> writes:

> Phil --

> > > They have already significantly decreased the level of
> > > support, and have admitted that they intend to reduce
> > > it even more over those few years.

> > PhD: Where? Can you provide a cite? Thanks!

> I used to give MSDN URLs for specific sections of the VB6 docs,
> but I don't see them on the MSDN site anymore. It makes it harder
> to give newsgroup help.

Exactly. If one were a suspicious sort, one might put together the
fact that Micro$oft monitors certain newsgroups with the fact that
certain oft-cited portions of the site have been removed and come to
interesting conclusions. For instance, the pages I have cited in the
past which support the statements above. Even the "life cycle" page
has been modified.


--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

[Phil Weber]

> I used to give MSDN URLs for specific sections of the VB6
> docs, but I don't see them on the MSDN site anymore.

Mark: VB6 docs on MSDN start here:
http://msdn.microsoft.com/library/en...bstartpage.asp
---
Phil Weber

[turbofish]

> The Beginning VB.Net book from WROX uses the OleDB calls in ADO.Net.
>
> Bob
>

Yep, I have that book. Look at page 41. That is the last time they will
address Access database. "Why Use Desktop Engine Instead Of Access?" All
further examples use MSDE/SQL Server

[Bob]

In article <MPG.1763420c44754c1a989684@news.devx.com>, junk@turbofish.com
says...
>
> > The Beginning VB.Net book from WROX uses the OleDB calls in ADO.Net.
> >
> > Bob
> >
>
> Yep, I have that book. Look at page 41. That is the last time they will
> address Access database. "Why Use Desktop Engine Instead Of Access?" All
> further examples use MSDE/SQL Server
>
Interesting. I don't like the book, so I didn't buy it.

Bob

[Mark Jerde]

Phil,

> Mark: VB6 docs on MSDN start here:
> http://msdn.microsoft.com/library/en...bstartpage.asp
> ---
> Phil Weber

You're right, I wonder where they were hiding the last time I looked?
;-)

Thanks.

Mark Jerde
Biometrics - www.idtechpartners.com

[Kunle Odutola]

> > > PS I support legal moves to outlaw the practice though.
>
> > Kunle,
>
> > I'm not so sure I agree 100% with your PS. I am familiar with at a
> > least one OS that has undocumented APIs, into various pieces of the
> > software.
>
> So am I - Windows. Kunle the Troll is just....

....a figment of your imagination.

> > One example might be something like APIs that bypass certain
> > time-consuming routines. The benefit would be significantly higher
> > performance in certain critical areas.
>
> Exactly the sort of thing Micro$oft was caught at.

Perhaps some examples of this (apart from IIS on NT) ?

> > The price would be corrupted data or if you are lucky, the
> > equivalent of a BSOD, if it's not done correctly.
>
> Which, of course, points out one of the major fallacies of his
> argument - that "finding" the API does not give enough information to
> allow safe usage.

Finding the API is all that is needed to prove it exists. And that it is
being used unfairly by MS application software as opposed to the OS or it's
components.

> Another MAJOR fallacy is his pointless (and baseless)
> claim that the number of such API calls found can be described as "so
> few". For instance, Jim Allchin characterized the number of such secret
> APIs in the .NET CLR as 1/3 of the total APIs therein.

Apples and Oranges.
"How many such APIs are being used unfairly by MS aplications?" is the real
question. The answer is probably zero.

> > The good news is that in the instances I am familiar with, certain
> > levels of privilege are required to use these APIs.
>
> The bad news is that some of the relevant APIs literally checked
> whether the calling program was a Micro$oft product, and sabotaged the
> results if it was not.

In most cases, this is exactly what they should do.
HTH!

Kunle

[Mike Mitchell]

On Fri, 14 Jun 2002 00:02:48 +0100, "Kunle Odutola"
<kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:

>> > One example might be something like APIs that bypass certain
>> > time-consuming routines. The benefit would be significantly higher
>> > performance in certain critical areas.
>>
>> Exactly the sort of thing Micro$oft was caught at.
>
>Perhaps some examples of this (apart from IIS on NT) ?

But that is like the accused saying, aw, cummon, judge, it was only
ONE little murder!

MM