Re: need advice learning driver development

> NDIS is not documented, but in the past if you were willing to go the NDIS/WDM route you could

develop an NDIS miniport with almost no NDIS in it. I suspect the same is true today with NDIS/KMDF.

???

If you don’t use NDIS in your NIC driver how are you going to expose it to the protocol stack then???

The only thing you can do here is to implement a layered miniport, i.e. write WDM or KMDF driver that actually deals with the hardware details of your NIC, plus a virtual NDIS miniport driver that deals with above mentioned WDM or KMDF driver on its lower edge and with NDIS library on its upper one,effectively interfacing your NIC to NDIS.

Although there may be some reasons why you may want to go this way (for example, you may want to be able to queue separate DPCs for TxComplete and Rx events, i.e. something you are unable to do within NDIS framework), avoiding dealing with NDIS is DEFINITELY not among them…

Anton Bassov

What he meant was using NDIS for hw access (ie PCI). If you are not a PCI based NIC, you are a defector NDIS-WDM, now NDIS-KMDF, NIC

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Saturday, July 10, 2010 6:30 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Re: need advice learning driver development

NDIS is not documented, but in the past if you were willing to go the
NDIS/WDM route you could develop an NDIS miniport with almost no NDIS in it. I suspect the same is true today with NDIS/KMDF.

???

If you don’t use NDIS in your NIC driver how are you going to expose it to the protocol stack then???

The only thing you can do here is to implement a layered miniport, i.e. write WDM or KMDF driver that actually deals with the hardware details of your NIC, plus a virtual NDIS miniport driver that deals with above mentioned WDM or KMDF driver on its lower edge and with NDIS library on its upper one,effectively interfacing your NIC to NDIS.

Although there may be some reasons why you may want to go this way (for example, you may want to be able to queue separate DPCs for TxComplete and Rx events, i.e. something you are unable to do within NDIS framework), avoiding dealing with NDIS is DEFINITELY not among them…

Anton Bassov


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

We already established that taking a seminar is out for the OP. I didn’t suggest he take one, in fact.

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…

There are simply too many little details, “gottchas”, and issues for a new driver writer. 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.

To learn this, it doesn’t matter if you take a seminar, read some books, read The NT Insider, or read a bunch of papers on WHDC.

To quote my first post on this topic: http://www.osronline.com/ShowThread.cfm?link=185282#T11 – What you need to really understand are:


Thread and processes, key
data structures, how you get into and out of kernel mode, how requests are I/O
processed, IRQLs, I/O completion, synchronization. Of these you really need
to understand and internalize the flow of an I/O request from initiation at the
user application to completion. AND you need to understand IRQLs.

Only AFTER you know these things should you embark on steps (a), (b), and (c) – iterating through b and c, above.

So, OP… start reading. When you think you get it, start working your way through an example or two. But… NO HACKING ON SAMPLES until you understand the basics. Just like no driving your car until you know the traffic laws.

Peter
OSR

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.

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.

Calvin

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of piyush jain
Sent: Friday, July 09, 2010 11:48 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] need advice learning driver development

I never at any point of time said that I will going a new project or i need
to write a driver from scratch. I need to learn driver development and I am
surrounded by quite a few experienced guys (mostly 5+ yrs) in driver
development.

Problem is that they don’t have time to babysit me (and their approach is
not easy to understand–knowing and ‘to be able to teach’ are 2 different
things) but they are happy to help me with doubts.

Now, my request was simple. i need to learn and how do i go about it. if u
see a person in my situation, how will u guide him? that all i asked, I
think only few like Peter provided help and how to go about it; and to me,
others are making unnecessary discussion !

Please do not take any offense. I just wanted to be clear and wanted to make
this tread useful even for others, who see it later.

On Fri, Jul 9, 2010 at 10:45 PM, Calvin Guan
wrote:

I believe OSR is good although I never have the luxury to get there.

I agree with Pavel’s point. If I were the manager to start a new project
that is critical, I would hire experienced who has been there and done that.
Initial quality and time to market are vital for a project to survive IMO.
Instead of sending a fresh man to OSR, it makes more sense to hire osr (or
whoever that is capable) to do the initial work.

For sustaining effort, it’s ok for less experienced given that the original
work does not require major overhaul or rewrite.

Calvin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, July 09, 2010 8:22 AM
To: Windows System Software Devs Interest List

Subject: Re:[ntdev] need advice learning driver development

> From: Pavel A. [mailto:xxxxx@fastmail.fm]

> With all due respect to OSR courses and others, they teach generic
knowledge,
> a lot more than one needs for a specific project, that requires time
and
> effort to understand.

Have you actually taken an OSR class? Yes the knowledge is generic, but
most of it is applicable to many classes of drivers. The thing about
OSR and the other good instructors is not that they teach you the
subject matter, but they guide you into how to find the data you need.

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


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

— 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

>

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