Re: some ntdll functions (2) - part 1: functions
thomas.mertes(a)gmx.at writes:
+ * _ultoa (NTDLL.@) + * + * Converts an unsigned long integer to a string. + * + * Assigns a '\0' terminated string to str and returns str. + * Does not check if radix is in the range of 2 to 36 (as native DLL). + * + * Difference: + * - Does not crash on str == NULL (as native DLL). + * Instead requests the needed memory with RtlAllocateHeap. + * When RtlAllocateHeap fails: return NULL.
Please don't invent extensions to the API. If a function doesn't allocate memory under Windows it shouldn't allocate memory under Wine either. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard <julliard(a)winehq.com> writes:
thomas.mertes(a)gmx.at writes:
+ * _ultoa (NTDLL.@) + * + * Converts an unsigned long integer to a string. + * + * Assigns a '\0' terminated string to str and returns str. + * Does not check if radix is in the range of 2 to 36 (as native DLL). + * + * Difference: + * - Does not crash on str == NULL (as native DLL). + * Instead requests the needed memory with RtlAllocateHeap. + * When RtlAllocateHeap fails: return NULL.
Please don't invent extensions to the API. If a function doesn't allocate memory under Windows it shouldn't allocate memory under Wine either.
The Reactos msvcrt functions have exactly this extension. So I implemented the Reactos API (which is a superset of the M$ API). And I did not make this decision without reason. This is exactly the same strategy M$ uses with standards: extend and embrace. IMHO this is the right place for "extend and embrace": The native function crashes in this case. So currently no application will call this functions with str == NULL. The extension makes sense. I can think of several good usages of this extension. Applications using the extended functionality will not run under native windows. Therefore I documented the extension as Difference. Summary: Using the "extend and embrace" strategy against M$. If an application wants to find out if it is running native or under wine there are always simpler possibilitys to find that out. Please reconsider your position. If you still do not like extensions (even under this conditions) I am willing to send a new patch. May be extended functionality (which can happen elsewhere as well) can depend on the "Windows" config entry ("Windows"="Reactos") or some other config option. Greetings Thomas Mertes -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
thomas.mertes(a)gmx.at writes:
The extension makes sense. I can think of several good usages of this extension. Applications using the extended functionality will not run under native windows. Therefore I documented the extension as Difference. Summary: Using the "extend and embrace" strategy against M$.
This is silly. It's just a gratuitous incompatibility that will break code for no good reason. Do you seriously think that people are going to give up running on Windows so that they can have _ultoa allocate memory for them? The whole point of coding to the Windows API is to run on Windows; if your app is not going to run on Windows there are dozens of much better APIs to choose from. If the ReactOS guys want to add incompatible extensions that's their choice; but it's a mistake IMO, and it's definitely not something we are going to do in Wine. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
<snip>
If the ReactOS guys want to add incompatible extensions that's their choice; but it's a mistake IMO, and it's definitely not something we are going to do in Wine.
The only incompatible extension we have discussed adding was for SVG graphics support. This idea was mainly only for applications that will ship with ReactOS that way it would make it easyer for us to handle/edit resources and such in our CVS. Still this is a VERY minor extention that doesnt break anything and would be easy to work around if someone wanted to ship a Windows and ReactOS version of the app. This was something I meant to about on wine-devel anyway as wrc resource format is not normal binary anyway. If there was a way we could get all of the resources in to SVG and maybe convert them to normal bitmaps at compile time it might make sharing resources easyer. I dont know that much about the format but from what I have seen it makes making changes to the image as easyer then if it was a XPM. Thanks Steven
Alexandre Julliard <julliard(a)winehq.com> writes:
This is silly. It's just a gratuitous incompatibility that will break code for no good reason.
The point is: It does not break existing code. Existing code which uses NULL as "string" parameter for _ultoa just does crash.
Do you seriously think that people are going to give up running on Windows so that they can have _ultoa allocate memory for them?
This is the decision of the people using the _ultoa function. All extensions (think of GNU extensions to programming languages and librarys) work this way. There is a long history of language / library extensions. The story is always the same: If you use an extension you lose portability (therefore it must be documented). The _ultoa function itself is an extension over the standard C library functions. If you use _ultoa it does not run under unix (surprise). In standard C you would use printf (and friends) for that functionality.
The whole point of coding to the Windows API is to run on Windows; if your app is not going to run on Windows there are dozens of much better APIs to choose from.
Yes
If the ReactOS guys want to add incompatible extensions that's their choice; but it's a mistake IMO, and it's definitely not something we are going to do in Wine.
In your opinion all the GNU people doing extensions are just making mistakes (BTW Linux is an extension over the Unix API). Ok, I can live with your decision (although I still have a different position). And I will send a new version of the patch. The borderline when an extension begins is not always simple to draw. Just 2 examples: The native _itow fuction does crash when the string is longer than 19 chars. The native _itoa function does not have this problem. I decided that our _itow function should not crash (like the native _itoa function) in this case. Instead it just works when the string is longer than 19 chars. The native RtlLargeIntegerToChar function does produce garbage or STATUS_BUFFER_OVERFLOW for base 2, 8 and 16 when the value is larger than 0xFFFFFFFF. Here I decided also against "bug for bug" compatibility. IMHO doing something senseful instead of crashing or producing garbage is "The right thing to do" ((C) Linus Torvalds). This decisions are not done lightly. I do a lot of testing and reasoning. My _ultoa extension is just one step more (and nobody is forced to use this extension). When you do extensions you tell the user: Our interface is better and more modern than the original. We do not crash and we have more functionality. I think (good) extensions would attract windows users. And some of them would help developing. But aggain: I can live with your decision (although I still have a different position). And I will send a new version of the patch. Greetings Thomas Mertes -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
thomas.mertes(a)gmx.at writes:
The native RtlLargeIntegerToChar function does produce garbage or STATUS_BUFFER_OVERFLOW for base 2, 8 and 16 when the value is larger than 0xFFFFFFFF. Here I decided also against "bug for bug" compatibility.
IMHO doing something senseful instead of crashing or producing garbage is "The right thing to do" ((C) Linus Torvalds).
In general yes, but not in the context of Wine. Of course it's more satisfying to make the function behave better, and it's OK to do it as long as it doesn't break anything, but we can't have anybody depend on that; because if we someday find an app that depends on the garbage results we will have to put the bug back in. And that's why it makes no sense to export extensions, since nobody can use them. -- Alexandre Julliard julliard(a)winehq.com
In general yes, but not in the context of Wine. Of course it's more satisfying to make the function behave better, and it's OK to do it as long as it doesn't break anything, but we can't have anybody depend on that; because if we someday find an app that depends on the garbage results we will have to put the bug back in. And that's why it makes no sense to export extensions, since nobody can use them.
Out of interest, might this apply to WineLib-specific extensions in future? As a trivial example, the KDE/GNOME system trays can hold icons have a larger size and bit depth to the one on Windows (so they look better). If you're trying to increase integration by using WineLib, would adding a new extension to allow better tray icons to be used allowed (because conditional compilation can always turn it off on windows). The alternative would be to say that you have to use the native APIs, but for instance if it was for special window hints that might not really be possible (because all your window handling code is via WineLib). Same I guess for wine-specific window styles and so on. Presumably if such things were introduced Microsoft could bork them by introducing their own styles with the same numbers, but I think there are schemes to work around that. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
participants (4)
-
Alexandre Julliard -
Mike Hearn -
Steven Edwards -
thomas.mertes＠gmx.at