The Old New Thing

I would've expected the answer to be "how would you like the float to show up in its textual representation" .. but the reason you described makes more sense.

> Most computer programs don't use floating point anyway.

Actually, there are only a few, mostly trivial, programs *not* using float (double, for that matter). Working in technical computing, my own software maybe does not count. It is completely about floating point math.

But almost any SW I use on a day to day basis does use floats (or has at least have some in the GUI, even if using fixed-point math internally).

But the main point is: Why are legacy burden like this not get deprecated in, say, WindowsME and phased out in XP? What seemed to be a good idea in times of the 8086 is stupid and API-clutter in times of Quadcores with inbuilt Physics-engines and 4 GB default Mem.

noone in particular:

What clutter? Wasn't the point that there is *no* function?

Deprecating is something, making something new is something else.

Or do you suggest deprecating the *Int versions?

If Intel had their way, the GetDlgItemFloat function would return 0.9999999 for an item that says "1".

> Why are legacy burden like this not get deprecated

Wait, I may have misunderstood "noone"'s comment, as it seems he wants to get rid of some API functions just to free 0.001% of memory and break backwards compatibility.

The legacy burden may also apply to the "not creation of new functions for floats", but really I can't be sure because of the formulation.

In either case, Igor Levicki will answer:

- Why did MS spend so much time creating these useless functions instead of making Vista stable?

- Why did MS remove these functions? SuperCoolSoft 2000 doesn't work under Vista!!! What a piece of crap!

Sitting here, sipping Pepsi-free in front of my C=64, reading your posting on Fidonet, I've got to say that makes a lot of sense.

Jonathan Wilson must be happy to know his question got somehow warped back to 1984.

Give people an OS and a SDK, and they'll ask for minimal reusable functionality.

The idea that you need a 8087 co-processor to process floating point numbers is just idiotic. You need it to *speed up* processing of things like transcendental functions, and to use the co-processor opcodes, but, guess what?, the 8087 doesn't have a "convert text to FP format" instruction. That code is written in plain-old x86 code *even if* you have a coprocessor.

GWBasic does just fine interpreting floating point text and numbers without an 8087 or an 8087 emulator library.

@noone in particular: Because it would just cost more to deprecate the function, document it, handle complaints, then remove it and handle more complaints and support requests. Meanwhile ISV's using the function would all have to write their own GetDlgItemInt.

Besides, "in times of Quadcores with inbuilt Physics-engines and 4 GB default Mem" you shouldn't have to worry about a function as small GetDlgItemFloat sitting next to other small (useless/useful) functions in a single memory page. Your desktop wallpaper probably needs a few orders of magnitude more.

I'm surprised nobody has yet announced that they didn't have to include a whole FP library because division by 10 is the only non-integer operation required to in atof. Actually, I'm almost surprised that Igor hasn't yet told us how trivially few bytes of optimized 8086 assembler it would take.

Of course maybe that's because it still leaves the point that the few people who want such a function can write it themselves by calling atof.

>Jonathan Wilson must be happy to know his question got somehow warped back to 1984.

>Give people an OS and a SDK, and they'll ask for minimal reusable functionality.

Basically Raymond's post reads: "When these particular functions were written, providing a float version was a Bad Idea™. No one has since had a need to go back and revise it. When someone working on windows components needs a float version and makes one, then you'll get that function. Until then, you'll have to make your own. Feel free to distribute your own library."

Most computer programs that use floating point should probably be using scaled integer arithmetic anyway. I've lost count of the number of times I've had to explain that there are only four values for the first two decimal places that can be accurately represented in floating point (and they are .00, .25, .50, and .75). Everything else is an approximation, which is what makes floating point so terrible for manipulating currency amounts.

Games still use a fair amount of floating point, I think. Quake was the first game I can recall that required the FPU. Any graphics computation in 2D ends up being clipped to pixels anyway, although GDI+ does all its text sizing in floating point.

Actually, GetDlgItemInt() does communicate the success of the attempted conversion, which atoi() doesn't.

But GetDlgItemInt doesn't do anything you couldn't already do with GetDlgItemText and strtol().

I wonder if that's how atof() really works. I wrote a dumb parser doing just that, and the accumulated round off errors were hugely apparent after the thousandths place. A'La the Intel comment about 0.999999, only worse.

Mike Dimmick:

> as it seems he wants to get rid of some API functions just to free 0.001% of memory and break backwards compatibility

Sure. But currency is only one small (in the number of applications, not the number of people doing it) part of programming.

"That code is written in plain-old x86 code *even if* you have a coprocessor."

Duh, which was why Raymond said, "as well as atof (which is not an easy function to write)."  Since nobody needed floating point support in the Window manager or whatever, there's no purpose of even providing atof for GetDlgItemFloat.

@alex.r.:

Yes, deprecating the *Int version as it is a two-liner to make it, or either get a decent API done, able to handle doubles as well as ints.

@Nawak:

I wouldn't think deprecating an API as old as some of its programmers breaking compatibility.

They dumped the MSDOS-API and that was a good thing.

No they better had dumped Win16 as well.

And prepare us to dump Win32 in a few years and switch to .NET

@xorl:

Everyone needing GetDlgItemInt could roll their own in two lines of code. (When doing MFC, I always prefered DDX)

And I am worried more about, say, API hygiene than actual memory usage of some DLL, which is loaded once and then mapped.

@Noone in particular:

What about SendDlgItemMessage? Do you also want it deprecated?

Wow - I can't believe the number of people who seem upset that the Win32 API doesn't contain GetDlgItemFloat() or that seem upset that it *does* contain GetDlgItemInt().

Let's get on to the important stuff though - where's my ten dollars (look - I'll settle for the five)?  I left my wallet at home today, and I need to buy lunch!

Noone in particular:

OK, well it may have symbolic value to deprecate it but since this was a public API, it would still have to be supported for a fair number of years before it can be removed.

... but ultimately, what would be the end goal? Having everyone write their own version of the function in the name of 'API purity'?

I guess I don't see the value in doing that.

I smell flimsy rationalizations.

Translate this article as "MS didn't need it, you didn't get it, because ultimately, MS didn't get it"

And apparently, some as MS still don't.  

A dark shadow in what is normally a bright ray of light.  Sad, really.

It's mind-boggling how many words some people can spew out through their keyboards without managing to express a single coherent thought.

"Get a decent API done?"  Okay Mr. Disgruntled Anonymous Nobody Posting on a Microsoft Employee's Personal Blog, I'm sure all you'd have to do is e-mail your resume to Steve Balmer along with a copy of your comments here, and he'd be more than happy to sign you onto the payroll to lecture their Windows designers on how to design a "decent" API.  Why not give it a try?

It makes me sad to think of all these people who's software failed to ship because MS didn't supply a GetDlgItemFloat.  

If that is the biggest problem holding up your software, then find another profession and do us all a favor.

(In response to another post, not Raymond) Most games use a HUGE amount of floating point.

I would have guessed that all font scaling for display purposes (as in every invocation of Microsoft Word, when it draws your text in some font or other, to the screen) and all screen drawing code would need floating point calculations.  But I could easily be wrong.  

:-)

This seems to be a reccuring theme in the Windows world.

Win32 developer: Why is there no API to do X ?

Microsoft: X is sooo easy, do it yourself.

Win32 developer: *Stumbles around for awhile on the MSDN, Google, forums, what have you. Eventually creates a solution that seems to work as if by magic.

<A few years pass>

Microsoft: Try out Windows N! It's got all these new features and frameworks and APIs!

Big name magazine: Program K doesn't work on Windows N! Windows N is the worst software product in the history of mankind.

<Microsoft disassembles program K>

Microsoft: *censored*

<few more years pass>

Raymond Chen: A few years ago, I ran into an interesting compatibility where a program (Let's call it program K) did F: ...

Software is so interesting :)

I would guess that a significant number of programs that use FP nowadays would have used integer math (fixed-point or BCD) 20 years ago. Pretty much all 2D graphics algorithms actually use fixed-point math instead of FP.

FP used to be a huge performance penalty that you would only pay if you had to. Now that almost all CPUs come with fast integrated FP units, there's no longer any penalty associated with FP and so programmers can use them without remorse.

@Triangle: but that makes it look like if Microsoft can always come up with better code then others. Hah. Hahahahaha. I don't agree with Igor but c'mon...

I was actually reffering to things like this http://blogs.msdn.com/oldnewthing/archive/2006/06/13/629451.aspx

Maybe it is just me, but I do not understand why people are going nuts over such a small thing.  And trying to summarize about all of Windows development from this one thing.

There isn't a float version!  The world IS GOING TO END!  Or rather, MSFT doesn't get it because I said so.

I had something interesting to say, but it's too hard to type with bruised swollen fingers.

Gabe

> there's no longer any penalty associated with FP

For most application, the penalty isn't noticeable, true, but there may still be one.

I say 'may' because I don't really know how an OS handles FP context on x86, but on powerpc, the OS can disable FP, and then skip the save/restore of the FP registers to lessen the context-switch time.

When an application use FP math, the OS handles the associated exception, activates the FPU for this task and does the save/restore thing.

Context-switch times are really important for some applications. Of course, my comment was mostly "FYI", as you must have meant "noticeable" when talking about the penalty and in this regard, you are right, for user-driven application, the penalty isn't noticeable.

@nearly everyone,

The reason MS put the function in in the first place was to deal with memory limitations in very early versions of windows. After that, they couldn't remove it, because even if you deprecate it, there will be some, new, 'enterprise', 'mission-critical' application using it, because it was built off of older examples, without reading docs or deprecation release notes. As others have said, it hardly costs anything to /keep/ at this point, so it's not worth pushing the issue and breaking all those applications.

@Nawak

I don't know how the Windows kernel handles FP, but Linux at least does exactly this technique. It would seem likely that windows would as well. Note that on Linux at least it will skip FP restore/save whenever the application spends a time slice (or at least time between schedules, if it yields earlier) without doing FP, so even applications which do /some/ FP get the benefit when they're in an integer math only path.

It's not there.....

I didn't miss it.

HTH

:)

On x86, the OS sets the TS bit of control register zero during a task switch. The CPU then generates interrupt 7 (device not ready) when it encounters an instruction that uses the FPU registers, at which point the FPU or MMX state is saved.

Whoops! Sorry if was premature, Raymond!

P.S. Ow!

"So why stop there? Why not also do floating point? Well, the 8086 processor doesn't have floating point support. If you wanted hardware floating point support, you had to shell out the extra bucks for an 8087 coprocessor."

And that was true until the 486, where there was a DX version that had a FPU, and there was a SX version that did not had a FPU. BTW, the "487SX" was really a 486DX that was modified with an extra pin to fit into a FPU socket on the 486 motherboard, and was designed to disable the 486SX. That FPU socket later became the OverDrive socket and later called "Socket 1", and the OverDrives that were supposed to plug into it disabled the 486SX in the same way as the 487SX.

"Quake was the first game I can recall that required the FPU. "

Which is why it made the 486 obsolete and is one of the programs which did benefit from a Pentium OverDrive.

BTW, Intel made the RapidCAD for a similar reason to this.

Triangle: Each version of Windows have some new features that don't require much resources to implement.

For example, Windows XP have support for SYSENTER and SYSCALL, which could benefit some Pentium Pros (not all, because of bugs), even if they can't run XP well. And Vista have CancelSynchronousIo and IsThreadAFiber, both of which don't require much resource to implement. BTW, have anyone trimmed Vista to the extent that it runs on older hardware well, while still having this kind of new APIs.

>>Of course maybe that's because it still leaves the point that the few people who want such a function can write it themselves by calling atof.<<

Surely you can call atof() but what if you want "live" edit box? What if you want to perform some calculation and display the result in a static control or in another edit box each time user enters a new digit into the edit field?

That is not just atof() anymore but validating each character on WM_CHAR, watching out for ".", "-" and eventually "e", making sure they are in right place and that the number is in a valid range, etc. To do that and pass the control keys to the parent dialog you have to SetWindowSubclass() on the edit control. Even better if you wrap it up in a neat C++ class where each object takes care of itself and you just pick the pieces together.

In my opinion, that is the kind of functionality we are missing in Windows API and which we are doomed to reinvent, not GetDlgItemFloat().

Just so you people know, Raymond Chen is censoring some of my comments, particulary those where I question lack of innovation and performance improvements in Microsoft's software products.

While I am trying to be objective, he is trying to ridicule me with those pre-emptive comments.

I'll miss some of you whose comments were sometimes more interesting than Raymond's posts.

Raymond, I'd rather censor myself at this point, thank you. So... goodbye everyone, and thanks for all the fish!

>Just so you people know, Raymond Chen is censoring some of my comments, particulary those where I question lack of innovation and performance improvements in Microsoft's software products.

Well, that is OK for me. I would not go as far as Igor would go in terms of Microsoft.

>particulary those where I question lack of innovation and performance improvements in Microsoft's software products.

Not the place for this, Igor.

I remember noticing the lack of a Get/SetDlgItemFloat in the 90s.

The GetDlgItemFloat might have work, but then you have the problem of the SetDlgItemFloat.  Most of the time of us who need this prefer handling the formatting ourselves anyway.  

At what point did floating point emulation come with Windows?  I remember loving that I didn't have to worry about floating point emulation in Windows 3.x.  Before that, we had to chose to support the co-processor or not at compile time.  

One thing before I go: an example of a common use of floating point in a dialog is for measurement, for example for paper size in a print dialog.

"Just so you people know, Raymond Chen is censoring some of my comments"

Is that a problem? You've got your own blog... if it's really that important that you get your message out, Raymond can't touch you over there.

Oh right, the traffic on Raymond's blog is much higher than you own. Well, maybe that's because nobody cares what you have to say?

"So... goodbye everyone, and thanks for all the fish!"

Seriously, I don't think you're going to be missed.

Then again, by not providing the float/double version, Microsoft just gave people one less way to hang themselves.

Floats and doubles are bad unless you understand why they're bad and how to work around the limitations. Like a floating point number is an *approximation*. Or how an extra bit is actually hidden away by normalization.

Or how you can have "if (0.4f + 0.6f != 1) { printf("Math go funny\n); }" actually print the message out. (You cannot test equality in floating point to have it work reliably). Or how doing a set of operations the wrong way can corrupt your number to uselessness.

Things get worse when you go embedded and realize the only way to transfer floating point data is via... text encoding.

See "What Every Computer Scientist Should Know About Floating-Point Arithmetic" (search it) for how to spend a week debugging floating point errors that go haywire.

@Ulric

"At what point did floating point emulation come with Windows?  I remember loving that I didn't have to worry about floating point emulation in Windows 3.x.  Before that, we had to chose to support the co-processor or not at compile time. "

I found some fascinating information on that -

"Win16 applications

Win16 applications are typically compiled to have fixup records in their object code that contain floating-point instructions and calls to the 16-bit floating-point emulator, WIN87EM. If the computer's processor supports floating-point instructions, or if a coprocessor is present, the loader resolves the fixups to the floating-point instructions, and the instructions will be executed. If floating-point hardware is not detected, the loader resolves the fixups to the calls to WIN87EM, and the emulator will be executed.

WIN87EM does not intercept floating-point instructions that applications execute; it runs only when it is explicitly called. Therefore, make sure that Win16 applications are compiled to support emulation, which will tell the linker to put fixup records in the executable."

Cunning eh? If you have an floating point processor you end up using it with maybe a small penalty. If not you end up in the emulation code without the penalty of an co processor not present exception.

I say small penalty because the FP instruction the loader overwrites as it processes the fixup may be smaller than a near call into the emulator, in which case you could pad it with NOPs so the loader has space to write the call. Or you could make all the floating point routines call the emulator by default and then overwrite those functions with an FP instruction and a return if an co processor was present. Either way it seems like you'll waste an instruction or two.

I wonder if there'll be more pre-emptive Igor comments now that he's gone (yaay) and Raymond is too (yaaa... uh... oh -.-'' )

No more Igor, yay!

@Igor:

You should start a joint-venture Vista bash-fest with Norman. THAT would be something I'd like to see :)

Ladies and gentleman... In the left corner, misterrrrrrr Normannnnn Diamonnnnnnnnnnnd!!!!! *cheers* *boos* And in the right corner, misterrrrrr Igorrrrrrrr Levvy-Levickai-Levickiiiiiiiiiiiiiiiiiii!!!!! *cheers* *boos* *more cheers* *even more boos* llllllllLLLLLLLLLLLLLLET's get ready to arguuuuuuuuuuuuuuuuuuuuuuuuuuuuue! Ding ding ding!

I think we're witnessing the elevation of spamming to an art form here.

sickofthisshit wrote:

"

That code is written in plain-old x86 code *even if* you have a coprocessor.

"

This code has to use FP operations (multiplications and additions), either emulated or not.

Windows would have to contain fmul and fadd emulation.

noone in particular wrote:

"

Working in technical computing, my own software maybe does not count.

"

Exactly. It highly depends of the domain.

In kernel/driver programming and non-mathematical applications (e.g. Microsoft Word) FP is rarely needed.

Would you want to deprecate integers?

Hey, integers are MUCH more reliable than FP.

If you don't believe me, read the C99 spec to see than things as simple as x+y == x+y aren't guaranteed. Then, test compilers such as GCC to see that they don't even comply with the quite-minimalistic C99 specs!

Using FP, with care, where they're appropriate is perfect (e.g. intersections, positions and movements computing in games & simulations).

Using FP where integers would fit (e.g. array indexes) is foolish. It opens the door to bugs.

noone in particular wrote:

"

I wouldn't think deprecating an API as old as some of its programmers breaking compatibility.

"

What's the rationale for deprecating GetDlgItemInt.

Deprecating an API makes sense when it's weak, insecure, or replaced by something better. I don't see such a thing there.

"

And prepare us to dump Win32 in a few years and switch to .NET

"

With this policy, be sure that everybody will switch to GNU/Linux+WINE.

1. atof doesn't use x87 coprocessor instructions.

2. atof doesn't handle locale specific decimal separators. Btw, how is a program currently supposed to read locale specific floating point numbers from an editbox?

3. What about other floating point formats, "10E5", "10e5" ".01", should a GetDlgItemFloat handle that to?

4. A corresponding SetDlgItemFloat would also be required, it would be trickier to implement without a floating point library.

5. EditBox do have a window style (bit) to only accept numeric characters, "number". It would be nice (required) to add another bit to the windows style dword (or exstyle dword) which would have the window manager to accept floating point numbers (and not any not arbitrary strings). That code would be much more complex (than validating simple integers) to support and validate every possible syntax of a floating point number.

Some DOS compilers actually provided two versions of the printf/scanf family of functions, one that included floating-point conversions and one that didn't; the compiler tried to guess whether your program needed floating-point conversions, and indicated to the linker to use the appropriate version.

0.4 + 0.6 equals 1 in any useful implementation, because they round in different directions.

Watching a debate of the de/merits of floating point is like watching a flame war about Mac vs. Windows vs. Linux. Horses for courses, people. Use the right tool for the job. Know your tools. Get over yourselves. Class dismissed.

btw I've been browsing this blog for years and I've never noticed Igor (but I've noticed Normand, who is omnipresent), so I wonder if this was a little bit uncalled for?  I believe this may not be ethical.  better delete posts that are offensive than single out posters on the main page.

Ulric, let him have it his way. He is just showing that he cannot accept criticism and convert it into actual code improvement instead of getting it personally. Fortunately there are other people in Microsoft who aren't like him.

During all my posting here I made one offensive post that I am aware of (something about weight and Americans) and it was not published although some other posts which were offending to people from Europe were left intact.

Anyway, I am out of here. Have a nice day everyone.

Igor:  Later, and it's nice to see you go!

Ulric: Norman was so last year... I haven't seen him (here) for a while.

Igor: I thought you'd left already? Your posts don't have to be offensive to be deleted. It's Raymond's blog; they're Raymond's rules. He can delete your comments for whatever reason he likes. As I already said, you've got your own blog so I don't see what the problem is.

I remember when we were having similar trouble with Norman, his argument was that he couldn't be bothered setting up a blog just so he could rant, but that argument doesn't work for you...

Raymond removed a lot of my comments too. Actually I don't quite miss most of them.

Why are you still posting? I thought you left for good, so shoo.

Raymond removed a lot of my comments too. Actually I quite miss most of them.

Then stop writing comments, LOL.

gotchas wrote:

"1. atof doesn't use x87 coprocessor instructions."

Did you get the source code?

The best I found is GLIBC's source code, and it definitively uses FP instructions.

Windows Forms uses floating point, according to

<a>http://msdn2.microsoft.com/en-us/library/ms229605.aspx</a>

which is an MSDN article titled "Automatic Scaling in WindowsForms", and covers .NET 1.0, 1.1, 2.0 and 3.5..

It's all strings and ints isn't it?  Most programs just use these two basic values.  That's what makes .NET work so well, it does strings and ints just fine.

John