Re: need advice learning driver development

>

Once you overcome the learning curve, you will be going downhill. The
curve in
my definition is how to build a driver, setup a debugger and load the
driver
with debugger attached.

That can be a bit of work to set up, but it’s all documented and is just
a matter of following the ‘bouncing ball’. It’s more process than
knowledge.

Writing driver (apart from dealing with the device technologies
specific to
your hardware), is no more than RTFM and DISASM. The first part tells
you what
have been said that one must know and remember. The latter tells you
what have
not been said but you will need at some point of time.

Having reasonable understand of how the OS works will help you make
sense of
what the documents say hence you could remember it and turn it into
your
mother nature. Once you have the basic, you can learn anything in
Windows on
your own.

I can’t say I agree with your dismissal of driver writing as “not more
than RTFM and DISASM”. There is a lot you need to understand before you
start developing. A lot of it you can learn by doing it wrong and then
figuring out why it blew up in your face, but you still need that
understanding to get anywhere or else you can make some fundamentally
wrong design decisions. KMDF does take a lot of that pain out of driver
development though.

James

>> There is a lot you need to understand before you start developing.

Well, I never dismiss the necessity of understand before starting doing
something.

> A lot of it you can learn by doing it wrong and then figuring
> out why it blew up in your face, but you still need that understanding
> to get anywhere or else you can make some fundamentally wrong design
decisions.
> KMDF does take a lot of that pain out of driver development though.

I’m not advocating trial and error neither. But you need to build something
to prove and challenge your understanding of newly acquired knowledge. Many
times, you found yourself didn’t actually understand until you tried to
build something and it failed miserably. One may talk like a Phd when comes
to control theory on paper but he may end up getting an oscillator only when
he tried to build an amplifier and have no clue how to stabilized it in the
lab. I saw people like that.

To me, I found it’s more effective learning by read-exercise-read again. I
just can’t sit there reading all day long keeping my hands idle. YMMV.

Calvin

> Unless you know your OS fundamentals, you won’t even know what done LOOKS like. You run your driver… it works in your lab. Is it DONE? Just because it doesn’t blue screen does not mean it’s correct.

Or, let’s try: You send multiple asynchronous requests from your driver to driver X. MUST driver X complete those requests in order? Maybe in your experience driver X DOES complete them in order… but is what you’re observing the result of an architectural precept, a detail of implementation, or pure coincidence?

People who learn how to write Windows drivers by trial-and-error, without understanding architectural fundamentals, only have a partial picture… they don’t know what they don’t know.

They don’t know what they don’t know — This is the most scary part. It scares the hell out of my a??.

-pro

On Sat, 10 Jul 2010 22:22:30 -0400 (EDT)
xxxxx@osr.com wrote:

No, no, a thousand times NO… This is PRECISELY what I’ve been
saying is the wrong approach. This is exactly how to become a driver
writer who should never be allowed to write a production driver for
Windows.

One can certainly learn how to write C# .Net GUI apps by starting to
hack on an example before you know what you’re doing, but you will
take you AGES to learn how to write proper Windows drivers this way…

It’s the same problem with .NET applications too: I’ve seen far too
many people who think that C# and .NET are so simple they can dive
right in - and they end up with a barely-working mess. Having a solid
grounding in userland Windows and the tools is fairly important in my
opinion so you can understand things like thread priorities, COM
apartments, Winsock, and finally how to actually solve problems when
they occur.


Bruce Cran

This definitely is an interesting discussion as I am sort-off in the same situtation as the OP (OSR is too far away, but I don’t work for a company and don’t have anyone experienced around me who could help).

The way I started doing things was reading the really basic papers/documents, to be able to build a nothing driver and setting up windbg connected to a VM so I could debug it.
Then bit by bit I tried to extend this driver with the knowledge I had and by looking at the samples that did simmilar work. The obvious downside of this approach as mentioned before is that I did not know what I had to know (e.g. I knew there was something called an IRQL, but I ignored it). So what I learned from this approach is that it is extremely easy to shoot yourself in the foot… I needed more knowledge.

I then picked up the Windows Internals book and started reading… it clearly explains things like IRQL, and gives you an understanding as to why you can’t access paged memory at DIRQL instead of just telling you “you just can’t”. I also took a course on Operating Systems at my university, eventhough we didn’t use Windows it was still very helpful.

The next step is getting the ‘Developing with WDF’ book (I’ve ordered it weeks ago… but somehow there is a huge delay).

So in essence… any learning approach is somewhat personal, if you ask 10 students how they prepare for a test you might get 10 different answers. So in your case I would definitely try to ask your experienced colleagues to help you get on your way but after that don’t rely on them too much, do a lot of reading and make sure that you to some degree know what you are talking about. When people see that you put a lot of effort in yourself they tend to be a lot more helpful when you are stuck somewhere. That’s true on this list and probably with colleagues as well but I have no experience there ;).

>To me, I found it’s more effective learning by read-exercise-read again. I
just can’t sit there reading all day long keeping my hands idle. YMMV.

Couldn’t agree more. There’s something magical about the whole think-type
exchange.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Sunday, July 11, 2010 12:10 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] need advice learning driver development

> There is a lot you need to understand before you start developing.

Well, I never dismiss the necessity of understand before starting doing
something.

> A lot of it you can learn by doing it wrong and then figuring out why
> it blew up in your face, but you still need that understanding to get
> anywhere or else you can make some fundamentally wrong design
decisions.
> KMDF does take a lot of that pain out of driver development though.

I’m not advocating trial and error neither. But you need to build something
to prove and challenge your understanding of newly acquired knowledge. Many
times, you found yourself didn’t actually understand until you tried to
build something and it failed miserably. One may talk like a Phd when comes
to control theory on paper but he may end up getting an oscillator only when
he tried to build an amplifier and have no clue how to stabilized it in the
lab. I saw people like that.

To me, I found it’s more effective learning by read-exercise-read again. I
just can’t sit there reading all day long keeping my hands idle. YMMV.

Calvin


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

>It’s the same problem with .NET applications too: I’ve seen far too many
people who think that C# and .NET are so simple they can dive right in - and
they end up with a barely-working mess.

Welcome to user mode!

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruce Cran
Sent: Sunday, July 11, 2010 4:51 AM
To: Windows System Software Devs Interest List
Cc: xxxxx@osr.com
Subject: Re: [ntdev] Re: need advice learning driver development

On Sat, 10 Jul 2010 22:22:30 -0400 (EDT) xxxxx@osr.com wrote:

No, no, a thousand times NO… This is PRECISELY what I’ve been saying
is the wrong approach. This is exactly how to become a driver writer
who should never be allowed to write a production driver for Windows.

One can certainly learn how to write C# .Net GUI apps by starting to
hack on an example before you know what you’re doing, but you will
take you AGES to learn how to write proper Windows drivers this way…

It’s the same problem with .NET applications too: I’ve seen far too many
people who think that C# and .NET are so simple they can dive right in - and
they end up with a barely-working mess. Having a solid grounding in
userland Windows and the tools is fairly important in my opinion so you can
understand things like thread priorities, COM apartments, Winsock, and
finally how to actually solve problems when they occur.


Bruce Cran


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

> It’s the same problem with .NET applications too: I’ve seen far too

many people who think that C# and .NET are so simple they can dive
right in - and they end up with a barely-working mess.

I think .NET (and to some extend C#) are prone to this. It allows
people without a clue to screw up while promising productivity' and other marketing nonsense. I find it very difficult to write good applications in .NET. Yeah, it's easier to write visual bullshit/demo things, but it's in no way easier to write correct production level stuff then the old ways’. C + Win32 API require some technical
know-how that filter a lot of clueless people.

 Having a solid
grounding in userland Windows and the tools is fairly important in my
opinion so you can understand things like thread priorities, COM
apartments, Winsock, and finally how to actually solve problems when
they occur.

Most managers would not agree. Solid understanding people are
expensive. .NET programmers are cheap. Hey! They can build stuff, who
cares it’s sucks? Most .NET stuff is line-of-bussiness type of
applications. Internal stuff that’s not for sale, so the organizations
can just cope with whatever mess they produce.


Aram Hăvărneanu

Well, now we wander off topic…

It is entirely possible that when it comes to writing .Net apps, I am in the category of not knowing what I don’t know. Because *I* learned what I know of .Net programming from simple slash and burn hacking of the worst sort… precisely the kind of hackery that I constantly warn people off in learning driver development.

But it certainly SEEMS to me that I can write a very capable application… take some data, invoke some SOAP service, store some results, make a pretty something-or-other on the screen, masturbate some cool visual controls, get data from my serial port… without knowing a heck of a lot. I mean, seriously. If it works, have I not done it correctly? Now, I might not have done it OPTIMALLY, but… is it like kernel-mode programming where if I get it to work in my office, that tells me effectively nothing about whether it’ll work in my test lab or on my customer’s machine??

Now, surely… if you try to write something that’s more involved… adding multithreading, for example… you wind-up having to understand serialization. And, sure, not understanding serialization is certainly the sort of thing that wouldn’t necessarily show up when I test in my office.

But is .Net not intrinsically more “conceptually scalable” than Windows kernel-mode driver development? In other words, can’t I know relatively little and yet write relatively simple applications with confidence? And, then, if I need to write more complex apps, I learn a little more… and for yet MORE complex apps, I need to learn more STILL?? Whereas, with Windows drivers you must START with a chunk of knowledge before you can write “hello world” or you risk crashing and burning.

BTW, KMDF reduces the initial learning burden VERY considerably. I mean, miraculously in many cases. However, it does not relieve you of having to have SOME basic architecture stuff.

Peter
OSR

On Sun, 11 Jul 2010 13:53:15 -0400 (EDT)
xxxxx@osr.com wrote:

is it like kernel-mode programming where if I get it to work in my
office, that tells me effectively nothing about whether it’ll work in
my test lab or on my customer’s machine??

One example is numeric input and output. Everyone I’ve seen
programming .NET applications uses the default ToString() and Parse()
methods to handle numbers. It’ll all work fine in your office, but send
it to someone in mainland Europe and it’ll start crashing because there
will be a mixture of decimal separators in use. Likewise, send a
WinForms application that you’ve spent lots of time placing controls on
to someone in China and it’ll probably look very different, and
probably not very good (I believe this should be fixed with WPF). I’ve
seen both these issues in applications that had been deployed for over a
year, and were only found when customers complained about crashes and
other problems. I even saw one (internal) application that started
crashing when I changed the Windows country setting from US to UK!

Just like in the driver world, there are tools that can point out
issues like converting numbers from strings to floats and vice versa
and teach the user to avoid them in future - but, despite for example
the Code Analysis option being on the right-click menu in Visual
Studio, too few people seem aware of it and end up shipping
applications that fail to work in a large number of countries.


Bruce Cran

@Bruce: Two VERY good and easy-to-understand example. Nicely explained, thanks.

So, that DOES prove what I said earlier… when it comes to .Net programming, I really don’t know what I don’t know!

Peter
OSR

> with Windows drivers you must START with a chunk of knowledge before you can write “hello world”

or you risk crashing and burning.

It really depends on what you mean by the term “driver”…

If we assume that “driver” means just a KM module without any implication of its actual functionality, then the above statement is certainly false - after all, all that SCM-based “hello world” driver needs is practically do-nothing DriverEntry() and Unload() routines. Therefore, you can still gain knowledge incrementally while learning driver development.

In fact, Pavel’s advice is not that bad if we make a small adjustment to it - instead of dumbly screwing up a workable sample the way Pavel suggests you should use it as a reference while writing your driver from the scratch and incrementally adding functionality to it…

Anton Bassov

Actually Bruce’s examples show how even a generic course can help. I
know very little about .NET but having dealt with user space code in
Unix (and mini-computer OS’es) for many years before moving into Windows
device drivers, I have as one of my rules “Never trust an application
that can running in an international environment, until you have tested
it in all languages that will use it”. As I said in a previous post
over the years I took a number of OSR classes, and it is not the nuts
and bolts that were the great value, it was the insight and rules of
thumb that Peter, Tony and Mark conveyed that are the real value.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@osr.com [mailto:xxxxx@osr.com] Posted At: Sunday, July

11, 2010 2:48 PM Posted To: ntdev
Conversation: Re: need advice learning driver development
Subject: RE: Re: need advice learning driver development

@Bruce: Two VERY good and easy-to-understand example. Nicely
explained, thanks.

So, that DOES prove what I said earlier… when it comes to .Net
programming, I really don’t know what I don’t know!

Peter
OSR

__________ Information from ESET Smart Security, version of virus
signature database 5269 (20100711) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus
signature database 5269 (20100711) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus
signature database 5270 (20100711) __________

The message was checked by ESET Smart Security.

http://www.eset.com

> One example is numeric input and output. Everyone I’ve seen programming

.NET applications uses the default ToString() and Parse() methods to
handle
numbers. It’ll all work fine in your office, but send it to someone in
mainland
Europe and it’ll start crashing because there will be a mixture of decimal
separators in use.

It’s easy to be a sheep and go along with some comment that says “.Net is
bad”, but I was curious about the accuracy of this .Net bashing and looked
up up the doc page on .Net Parse.

You will get a FormatException if you use the Parse(String s) method on an
international format number. The docs for Parse are very explicit on its
behavior and limitations, and also refer you to fancier version of Parse
that will correctly work on culture local numbers. The docs section title
“Parsing Numeric Strings” gives the managed C++ example code:

CultureInfo^ MyCultureInfo = gcnew CultureInfo(“en-US”);
String^ MyString = “123,456”;
int MyInt = int::Parse(MyString, NumberStyles::AllowThousands,
MyCultureInfo);

It seems like .Net is getting bashed because some programmer didn’t read the
very clear and explicit docs on how to convert numeric strings to numbers.

One might argue that the simple version of Parse should just “do the right
thing” when presented with a culture local string, although it’s a religious
battle to say this is right or wrong, and depending on your religion you
will have a different opinion.

Let’s also look at alternatives. Off the top of my heard, when I think about
how much C code it would take to do the equivalent work of the culture
correct version of .Net Parse, I’d offhand say the work will often simple
not get done, and the effect will be the conversion of numbers will more
often be wrong when using culture local strings.

It sounds like the argument is: .Net is bad because it provides built in
methods to correctly handle culture local format conversion? Or perhaps:
.Net is bad because it raises an exception when code detects a condition it
can’t handle? Or based on a sample size of 1, where a programmer didn’t
follow the docs, we have just proven .Net is junk.

Beliefs are grown with evidence as fertilizer, and you need to take care
which fertilizer you use, and which seedlings you fertilize. Once a belief
is grown, changing its root system is pretty difficult, and before fully
grown its not always easy to tell the weeds from the flowers.

Jan

>Let’s also look at alternatives. Off the top of my heard, when I think
about how much C code it would take to do the equivalent work of the culture
correct version of .Net Parse, I’d offhand say the work will often simple
not get done, and the effect will be >the conversion of numbers will more
often be wrong when using culture local strings.

There’s always Boost…

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Sunday, July 11, 2010 7:14 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re: need advice learning driver development

One example is numeric input and output. Everyone I’ve seen
programming .NET applications uses the default ToString() and Parse()
methods to
handle
numbers. It’ll all work fine in your office, but send it to someone in
mainland
Europe and it’ll start crashing because there will be a mixture of
decimal separators in use.

It’s easy to be a sheep and go along with some comment that says “.Net is
bad”, but I was curious about the accuracy of this .Net bashing and looked
up up the doc page on .Net Parse.

You will get a FormatException if you use the Parse(String s) method on an
international format number. The docs for Parse are very explicit on its
behavior and limitations, and also refer you to fancier version of Parse
that will correctly work on culture local numbers. The docs section title
“Parsing Numeric Strings” gives the managed C++ example code:

CultureInfo^ MyCultureInfo = gcnew CultureInfo(“en-US”); String^ MyString =
“123,456”; int MyInt = int::Parse(MyString, NumberStyles::AllowThousands,
MyCultureInfo);

It seems like .Net is getting bashed because some programmer didn’t read the
very clear and explicit docs on how to convert numeric strings to numbers.

One might argue that the simple version of Parse should just “do the right
thing” when presented with a culture local string, although it’s a religious
battle to say this is right or wrong, and depending on your religion you
will have a different opinion.

Let’s also look at alternatives. Off the top of my heard, when I think about
how much C code it would take to do the equivalent work of the culture
correct version of .Net Parse, I’d offhand say the work will often simple
not get done, and the effect will be the conversion of numbers will more
often be wrong when using culture local strings.

It sounds like the argument is: .Net is bad because it provides built in
methods to correctly handle culture local format conversion? Or perhaps:
.Net is bad because it raises an exception when code detects a condition it
can’t handle? Or based on a sample size of 1, where a programmer didn’t
follow the docs, we have just proven .Net is junk.

Beliefs are grown with evidence as fertilizer, and you need to take care
which fertilizer you use, and which seedlings you fertilize. Once a belief
is grown, changing its root system is pretty difficult, and before fully
grown its not always easy to tell the weeds from the flowers.

Jan


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I don’t think anyone was saying .Net is bad… Not at all. I think Mr. Cran MIGHT have gotten a BIT carried away when he said “it’s in no way easier to write correct production level stuff then the `old ways’.” – I don’t buy that for a minute… but that’s WAAAAY off topic for the list.

Rather, I think Mr. Cran’s major point is that even for something as “simple” as apps in C# .Net there’s a basic, rudimentary, set of knowledge that’s required to accomplish real, production-level, tasks. Simply copy some shite from CodeProject and slashing and burning into doing what you want is NOT a guaranteed recipe for success.

He cited the decimal conversion issue with Parse specifically in reply to comment:

“If it works, have I not done it correctly? Now, I might not have done it
OPTIMALLY, but… is it like kernel-mode programming where if I get it to work
in my office, that tells me effectively nothing about whether it’ll work in my
test lab or on my customer’s machine??”

Mr. Cran gave us an example where the above is demonstrably not true… that’s all.

[quote]
Off the top of my heard, when I think about
how much C code it would take to do the equivalent work of the culture
correct version of .Net Parse, I’d offhand say the work will often simple
not get done

Oh, I couldn’t agree with you more. Absolutely right. SCREW string manipulation and parsing in C. It’s error prone, boring, time-consuming, and hideous.

Peter
OSR

On Sun, 11 Jul 2010 22:12:30 -0400 (EDT)
xxxxx@osr.com wrote:

I don’t think anyone was saying .Net is bad… Not at all. I think
Mr. Cran MIGHT have gotten a BIT carried away when he said “it’s in
no way easier to write correct production level stuff then the `old
ways’.” – I don’t buy that for a minute… but that’s WAAAAY off
topic for the list.

I didn’t say that, Mr Hăvărneanu did.


Bruce Cran

On Mon, Jul 12, 2010 at 2:14 AM, Jan Bottorff wrote:
> It’s easy to be a sheep and go along with some comment that says “.Net is
> bad”, but I was curious about the accuracy of this .Net bashing and looked
> up up the doc page on .Net Parse.
>
> You will get a FormatException if you use the Parse(String s) method on an
> international format number. The docs for Parse are very explicit on its
> behavior and limitations, and also refer you to fancier version of Parse
> that will correctly work on culture local numbers. The docs section title
> “Parsing Numeric Strings” gives the managed C++ example code:
>
> CultureInfo^ MyCultureInfo = gcnew CultureInfo(“en-US”);
> String^ MyString = “123,456”;
> int MyInt = int::Parse(MyString, NumberStyles::AllowThousands,
> MyCultureInfo);
>
> It seems like .Net is getting bashed because some programmer didn’t read the
> very clear and explicit docs on how to convert numeric strings to numbers.

Of course that the docs are correct, clear and explicit. The problem
is that most .NET programmers copy code from the Internet instead of
reading the documentation, because it is far easier to do so, and
mostly works.

It’s not a problem with .NET, it’s a problem with the .NET ecosystem
because the .NET ecosystem contains people. Up to this point, it seems
that people can’t be convinced to read docs.


Aram Hăvărneanu

Perhaps this is an Olympic 1600 meter sprint where some one might try to
fly :).

This not just .NET. Come on, it is all over !!

-pro

On Mon, Jul 12, 2010 at 2:14 AM, Jan Bottorff
> wrote:
>> It’s easy to be a sheep and go along with some comment that says “.Net
>> is
>> bad”, but I was curious about the accuracy of this .Net bashing and
>> looked
>> up up the doc page on .Net Parse.
>>
>> You will get a FormatException if you use the Parse(String s) method on
>> an
>> international format number. The docs for Parse are very explicit on its
>> behavior and limitations, and also refer you to fancier version of Parse
>> that will correctly work on culture local numbers. The docs section
>> title
>> “Parsing Numeric Strings” gives the managed C++ example code:
>>
>> CultureInfo^ MyCultureInfo = gcnew CultureInfo(“en-US”);
>> String^ MyString = “123,456”;
>> int MyInt = int::Parse(MyString, NumberStyles::AllowThousands,
>> MyCultureInfo);
>>
>> It seems like .Net is getting bashed because some programmer didn’t read
>> the
>> very clear and explicit docs on how to convert numeric strings to
>> numbers.
>
> Of course that the docs are correct, clear and explicit. The problem
> is that most .NET programmers copy code from the Internet instead of
> reading the documentation, because it is far easier to do so, and
> mostly works.
>
> It’s not a problem with .NET, it’s a problem with the .NET ecosystem
> because the .NET ecosystem contains people. Up to this point, it seems
> that people can’t be convinced to read docs.
>
> –
> Aram Hăvărneanu
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Actually, I don’t believe there is anything in the rules about flying. The
competitor must SURFACE at or before 15 meters, but there is nothing in the
rules about altitude above the surface of the water. :slight_smile:

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@garlic.com
Sent: Monday, July 12, 2010 4:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re: need advice learning driver development

Perhaps this is an Olympic 1600 meter sprint where some one might try to fly
:).

This not just .NET. Come on, it is all over !!

-pro

On Mon, Jul 12, 2010 at 2:14 AM, Jan Bottorff
> wrote:
>> It’s easy to be a sheep and go along with some comment that says
>> “.Net is bad”, but I was curious about the accuracy of this .Net
>> bashing and looked up up the doc page on .Net Parse.
>>
>> You will get a FormatException if you use the Parse(String s) method
>> on an international format number. The docs for Parse are very
>> explicit on its behavior and limitations, and also refer you to
>> fancier version of Parse that will correctly work on culture local
>> numbers. The docs section title “Parsing Numeric Strings” gives the
>> managed C++ example code:
>>
>> CultureInfo^ MyCultureInfo = gcnew CultureInfo(“en-US”); String^
>> MyString = “123,456”; int MyInt = int::Parse(MyString,
>> NumberStyles::AllowThousands, MyCultureInfo);
>>
>> It seems like .Net is getting bashed because some programmer didn’t
>> read the very clear and explicit docs on how to convert numeric
>> strings to numbers.
>
> Of course that the docs are correct, clear and explicit. The problem
> is that most .NET programmers copy code from the Internet instead of
> reading the documentation, because it is far easier to do so, and
> mostly works.
>
> It’s not a problem with .NET, it’s a problem with the .NET ecosystem
> because the .NET ecosystem contains people. Up to this point, it seems
> that people can’t be convinced to read docs.
>
> –
> Aram Hăvărneanu
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer