Re: Three year sever outstanding bug requiring minor fix
Is it a legal requirement that everyone working on WINE must be a complete arsehole, or just a project requirement? Nye
Re: fixing all the not-properly-displaying characters that have suddenly appeared in the appdb
On Wed, Dec 17, 2008 at 2:48 PM, Rosanne DiMesio wrote: > On Wed, 17 Dec 2008 14:13:31 +0100 > Alexander Nicolaysen Sørnes wrote: > >> On Tuesday 16 December 2008 20:52:04 Rosanne DiMesio wrote: >> > Since the change to the new design, AppDB entries have been displaying >> > either a ? (Firefox, Konqueror, Opera) or a blank rectangle (IE in Windows) >> > in place of a variety of special characters, including anything with an >> > umlaut (bug 16514). I've played around with it a bit, and the entries can >> > be fixed by manually editing them, but before I undertake the task, I >> > figured I'd better ask if this is something that could be fixed more easily >> > (e.g., changing a setting on the server). >> >> Could you provide a link to a page where this problem is shown? >> > > http://appdb.winehq.org/objectManager.php?sClass=application&iId=5651 > http://appdb.winehq.org/objectManager.php?sClass=application&iId=6764 > > It would appear that the new template says: , but those pages actually contain text encoded in ISO-8859-1. Possibly some kind of bulk conversion would be in order? -Nye
Re: To K&R or not
EA Durbin wrote: One could just write a perl script to parse the code upon submission that would convert it from K & R style to a uniform standard that it easy to read, and fix things like the amount of spaces in an indent. And thus the discussion comes full circle.
Re: To K&R or not
That said, I don't care what people do, I can read both... In my perfect world though, my SCM client would convert source code to my preferred format on checkout, and to whatever universal format the repository uses on checkin. Ho hum... (Personally I hate K&R because I want to be able to see the braces line up vertically, else I find it hard to read. Of course, that's an aside since, not being a Wine developer, it's a little pointless saying my opinion; I just happen to like doing so anyway :P) Anyway, the point: How about setting a standard that will be used in the repository, and providing the indent commands to set it that way, then indenting *every file* in the repository to that standard. Then every developer can use indent or whatever equivalent they prefer when they checkout, if they don't like the chosen style. By specifying a standard used by the repository it means that submitters can reformat their patches at submission time to avoid vast amounts of no-op changes caused by different formatting styles. This could be done automatically via an aliased `cvs diff` command, or whatever. Alternatively each patch could be considered by a script (which really wouldn't have to be at all complex) which tries applying it, reformats it appropriately, generates a more appropriate patch, then unapplies it. This would make the process transparent to most developers, with the cost of more processing needing to be done at submission time - perhaps that would be unacceptable; I've no idea what kind of resources are available compared to what it would take. Okay, I don't really expect this suggestion to be taken seriously since it involves modifying every file in the repository once, and potentially every patch, but I seriously think that it's an issue worth considering. Does anybody else think that it would be a feature that might really be used if it were implemented in ?
Re: License question
Kai Blin wrote: Actually going that way is not really problematic. Linking to LGPL code from GPL code is fine. To expand upon that, I'd like to quote a passage from the text of the LGPL: "3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices." So basically, if you're trying to derive GPL software from LGPL software, the official word appears to be 'feel free'. The only problem is that you can't contribute *directly* back, as the conversion from GPL back to LGPL is impossible - though you could dual-license your code, and still comply with the existing license. Hope that helps :P. Aneurin Price
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Con Kolivas wrote: Is it kernel dependant? Does 2.6.11 for example exhibit the problem or only recent kernels? Or has noone tried an older kernel like that? Cheers, Con Just to reiterate since everybody seems to forget this part: The problem does *not* occur when using a 2.4 kernel. Additionally, I seem to recall that when I tried compiling a 2.6 kernel without ALSA support (so OSS is native and not emulated), the problem went away even with the 2.6 kernel (this was back around 2.6.11ish time), though I may have misremembered that.
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Mike Hearn wrote: I'm not convinced this is true. At least some (maybe most or all) of the games showing this problem work just fine if true OSS (ie. not ALSA-emulated OSS) is used as the sound driver. WoW and StarCraft spring to mind immediately. Plus apparently they work in Cedega without needing to be root, though I have no first-hand experience of this. Maybe for you, but this problem seems to be related to all kinds of things ... system speed, kernel scheduler, driver combinations, what Wine is doing at the time etc. All I know is that this works great for me, and no, rebuilding my kernel and going back to OSS is not really an option :) Cedega, IIRC, either has some awful hacks or has the wineserver acquire the privs, I don't remember which it'd be nice to find out. IMHO the best way would be for wineserver to be suid root and then drop privs. It works everywhere and is simple. I really ought to remember to use reply-all for wine-devel. I've quoted my first post since I meant to send it to the list. Anyway, surely the `best' way would be for the kernel to support user-level `real-time' priorities like the ck kernels. Anybody know why they don't like the idea of that kind of thing? More on topic, does this simply change Wine's priority or does it act on a per-thread level? Most of the issues I've seen have been caused by the audio thread being starved by the others, and is often semi-solved by running Wine at nice 19, which seems counter-intuitive but appears to get around some sheduling problems (priority inversions spring to mind). This has the side effect of course that you have to make sure no other process is going to steal the cpu time from under you. Am I talking about the same issue as everyone else or have I got the wrong end of the stick?
Re: What would most aid WINE development?
Juan Lang wrote: The Windows API is of course public, so my guess is that isn't a huge bar to creating WINE. Unfortunately, you guess incorrectly. While the API may legally be public (the interface can't be protected, as far as we know,) it isn't always documented. MS uses undocumented APIs very, very frequently in its own products, and I don't just mean in its applications: parts of its API depend on other, hidden parts of its API. Even the parts that are documented are not documented completely. For example, many APIs take 32-bit flags parameters, some of whose meanings are documented. But the behavior for all possible values is not well-specified, nor are the return values. I continue this thread next: And on that note: does anybody know of any documentation anywhere for msvcrt sopen? Particularly, what the different pmode flags mean (I'm getting 0x01b6)...
Re: wine overstepping the mark?
[EMAIL PROTECTED] wrote: On Fri, 28 Oct 2005 01:11:21 +0200, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: Thursday, October 27, 2005, 5:04:05 PM, [EMAIL PROTECTED] wrote: Thanks for the explaination but that's just my point. That is windows mentality, but this is not windows. If I install gimp it does not try to reconfigure my system and take over control of any image file types it can handle. That is windows mentality. I wander what else can you use to open exe files with? And not just open, but run? Vitaliy crossover, win4lin btw, I thought open and run was the same thing. LOL No, because you may wish to open the file in a disassembler, a hex editor, a resource viewer, etc. In these cases, you certainly wouldn't want to *run* it. I think that's a part of the point :P.
Re: pf_vsnprintf implementatnion of 'I', 'I32' and 'I64' prefixes for type specifiers
David Laight wrote: On Tue, Aug 02, 2005 at 10:35:59PM +0900, Mike McCormack wrote: It's a little more complicated than you think, after you start handling all the width modifiers, various floating point formats, etc. Not to mention coding in the 'brokenness'! On windows: _snprintf(buff, 3, "ab" ) returns 2, buff = "ab<0>" _snprintf(buff, 3, "abcd" ) returns -1, buff = "ab<0>" but: _snprintf(buff, 3, "abc" ) returns 3, buff = "abc" without NUL terminating the string. Do you replicate that? David I believe my attempt at this was entirely compatible with Windows' behaviour (modulo some potential undiscovered bugs), including deviations from MSDN. Unfortunately, it wasn't very well written, and I can never seem to find the time to get the experience necessary to become competent. If anyone wants to look at it though, try the archive for wine-devel and wine-patches. If anyone has a *particular* interest, I might even have a look at it again with the benefit of at least *some* additional coding practice :). At least I could reduce the number of HeapAllocs, though I imagine there are more fundamental problems... Aneurin Price
Re: SetThreadPriority??
Andreas Mohr wrote: Hi guys, has ANYONE done any testing with my experimental SetThreadPriority patch which I mailed on May 15? So far I haven't received any replies, despite this probably being rather interesting, given that it is implemented by many of our winmm threads... Or should this remain untested until I will have a sizeable amount of time for testing myself during LinuxTag? Andreas Mohr I've just tried this out. First I had to define SCHED_BATCH and SCHED_ISO, just to get anywhere, but ultimately it fails because it relies on getting the value of thread->unix_tid and/or thread->unix_pid. Unfortunately, these never seem to be set after being initialised to -1 (in fact, in a very quick grep of Wine I could only find one or two assignments involving either of them, and that was just copying the value from another thread). To be honest I have no idea where to go from here.
Re: MSVCRT: Re-implement *printf
Jesse Allen wrote: Sorry for being late at responding. I took a look at it finally like a week ago. You can definately break up the patch. Erm, nevermind on breaking it up yet. I started to myself, but I think it's more trouble than it's worth right now. We can have that done later if that is what is wanted to have it accepted. I had another idea to help testing. I added a comparison test in _vsnprintf to go ahead and see if there is any difference between libc and wine by calling libc's version. If there is a difference, it will print a warning. Here's an obvious example in action while running War3: Cool, that's a good idea. I was holding off on responding to the other 2 posts until I'd come up with a meaningful response, but it's probably better to acknowledge them :). In response to Juan's comments then: 1. Already done :). I had several test cases (including one for the example you give) committed some time ago. 2. Well I can certainly give it some thought, though I'm not sure yet how I'd want to do it. This is the part that made me want to wait before responding, since I don't have anything actually useful to add yet. Anyway, I'm not ignoring you, and will respond decently when I've found the time to play with this a bit :). Thanks for the input.
Re: MSVCRT: Re-implement *printf
Changelog: Re-implement all *printf functions in msvcrt.dll, according to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_format_specification_fields_.2d_.printf_and_wprintf_functions.asp and descriptions of appropriate functions. This should fix, among other things, bugs 321 and 2075. Nobody has any comments about this?
Re: MSVCRT: Re-implement *printf
Juan Lang wrote: Style point: (*pointer).whatever is written a bit more easily as pointer->whatever. That'd make your new patch a good bit more readable. --Juan __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail D'oh. Can't believe that slipped my mind. Thanks.
MSVCRT printf functions
I've gone over this patch again, fixed any bugs I could find, and tried
to address the points made regarding readability. Hopefully the coding
style should now be much improved, so could anyone who knows about such
things give it a look over? If there's not too much of a problem there
I'll fix up any points made and submit to wine-patches with the
appropriate notes.
I am still a little unsure about a couple of points; ones I can remember
off the top of my head: probably insufficient attribution for code
derived from file.c, since I have no idea who wrote the functions I used
(these are specified in the copyright notice for printf.c, BTW). It's
also pretty big; I presume it's okay to have this much in one file, but
maybe not. Either way it can't be broken down into smaller patches since
it's one big change.
Thanks,
Aneurin Price
Index: dlls/msvcrt/Makefile.in
===
RCS file: /home/wine/wine/dlls/msvcrt/Makefile.in,v
retrieving revision 1.17
diff -u -u -r1.17 Makefile.in
--- dlls/msvcrt/Makefile.in 8 Nov 2004 22:10:43 - 1.17
+++ dlls/msvcrt/Makefile.in 6 Jan 2005 15:59:55 -
@@ -27,6 +27,7 @@
math.c \
mbcs.c \
misc.c \
+ printf.c \
process.c \
scanf.c \
string.c \
Index: dlls/msvcrt/file.c
===
RCS file: /home/wine/wine/dlls/msvcrt/file.c,v
retrieving revision 1.79
diff -u -u -r1.79 file.c
--- dlls/msvcrt/file.c 4 Jan 2005 20:37:54 - 1.79
+++ dlls/msvcrt/file.c 6 Jan 2005 15:59:59 -
@@ -2831,113 +2831,6 @@
return file;
}
-/*
- * vfprintf (MSVCRT.@)
- */
-int MSVCRT_vfprintf(MSVCRT_FILE* file, const char *format, va_list valist)
-{
- char buf[2048], *mem = buf;
- int written, resize = sizeof(buf), retval;
- /* There are two conventions for vsnprintf failing:
- * Return -1 if we truncated, or
- * Return the number of bytes that would have been written
- * The code below handles both cases
- */
- while ((written = vsnprintf(mem, resize, format, valist)) == -1 ||
- written > resize)
- {
-resize = (written == -1 ? resize * 2 : written + 1);
-if (mem != buf)
- MSVCRT_free (mem);
-if (!(mem = (char *)MSVCRT_malloc(resize)))
- return MSVCRT_EOF;
- }
- retval = MSVCRT_fwrite(mem, sizeof(*mem), written, file);
- if (mem != buf)
-MSVCRT_free (mem);
- return retval;
-}
-
-/*
- * vfwprintf (MSVCRT.@)
- * FIXME:
- * Is final char included in written (then resize is too big) or not
- * (then we must test for equality too)?
- */
-int MSVCRT_vfwprintf(MSVCRT_FILE* file, const MSVCRT_wchar_t *format, va_list valist)
-{
- MSVCRT_wchar_t buf[2048], *mem = buf;
- int written, resize = sizeof(buf) / sizeof(MSVCRT_wchar_t), retval;
- /* See vfprintf comments */
- while ((written = _vsnwprintf(mem, resize, format, valist)) == -1 ||
- written > resize)
- {
-resize = (written == -1 ? resize * 2 : written + sizeof(MSVCRT_wchar_t));
-if (mem != buf)
- MSVCRT_free (mem);
-if (!(mem = (MSVCRT_wchar_t *)MSVCRT_malloc(resize*sizeof(*mem
- return MSVCRT_EOF;
- }
- retval = MSVCRT_fwrite(mem, sizeof(*mem), written, file);
- if (mem != buf)
-MSVCRT_free (mem);
- return retval;
-}
-
-/*
- * vprintf (MSVCRT.@)
- */
-int MSVCRT_vprintf(const char *format, va_list valist)
-{
- return MSVCRT_vfprintf(MSVCRT_stdout,format,valist);
-}
-
-/*
- * vwprintf (MSVCRT.@)
- */
-int MSVCRT_vwprintf(const MSVCRT_wchar_t *format, va_list valist)
-{
- return MSVCRT_vfwprintf(MSVCRT_stdout,format,valist);
-}
-
-/*
- * fprintf (MSVCRT.@)
- */
-int MSVCRT_fprintf(MSVCRT_FILE* file, const char *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vfprintf(file, format, valist);
-va_end(valist);
-return res;
-}
-
-/*
- * fwprintf (MSVCRT.@)
- */
-int MSVCRT_fwprintf(MSVCRT_FILE* file, const MSVCRT_wchar_t *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vfwprintf(file, format, valist);
-va_end(valist);
-return res;
-}
-
-/*
- * printf (MSVCRT.@)
- */
-int MSVCRT_printf(const char *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vfprintf(MSVCRT_stdout, format, valist);
-va_end(valist);
-return res;
-}
/*
* ungetc (MSVCRT.@)
@@ -2971,6 +2864,
Re: Resend: Re-implement MSVCRT *printf functions
Mike Hearn wrote: On Sat, 27 Nov 2004 20:37:21 +, Aneurin Price wrote: Thanks for that; it's just the kind of comment I was looking for. It wasn't a full patch as I wasn't planning to get it applied, and a number of points were where I copied code from what was there already :), but you even caught a couple of places where I said to myself things like "I'll remeber to remove that commented block". I'll get to work on this today with any luck.
Re: Resend: Re-implement MSVCRT *printf functions
Well I recently got re-motivated, by forgetting I was using an unpatched
version of Wine, and getting my WC3 campaign file nuked :(.
So, I've had a go over this all, and here is a new version. Is it a step
in the right direction? I still don't really know what I should be doing
to improve this.
Aneurin Price
Index: dlls/msvcrt/Makefile.in
===
RCS file: /home/wine/wine/dlls/msvcrt/Makefile.in,v
retrieving revision 1.17
diff -u -u -r1.17 Makefile.in
--- dlls/msvcrt/Makefile.in 8 Nov 2004 22:10:43 - 1.17
+++ dlls/msvcrt/Makefile.in 27 Nov 2004 21:27:58 -
@@ -27,6 +27,7 @@
math.c \
mbcs.c \
misc.c \
+ printf.c \
process.c \
scanf.c \
string.c \
Index: dlls/msvcrt/file.c
===
RCS file: /home/wine/wine/dlls/msvcrt/file.c,v
retrieving revision 1.73
diff -u -u -r1.73 file.c
--- dlls/msvcrt/file.c 3 Nov 2004 22:17:05 - 1.73
+++ dlls/msvcrt/file.c 27 Nov 2004 21:28:00 -
@@ -2614,113 +2614,6 @@
return file;
}
-/*
- * vfprintf (MSVCRT.@)
- */
-int MSVCRT_vfprintf(MSVCRT_FILE* file, const char *format, va_list valist)
-{
- char buf[2048], *mem = buf;
- int written, resize = sizeof(buf), retval;
- /* There are two conventions for vsnprintf failing:
- * Return -1 if we truncated, or
- * Return the number of bytes that would have been written
- * The code below handles both cases
- */
- while ((written = vsnprintf(mem, resize, format, valist)) == -1 ||
- written > resize)
- {
-resize = (written == -1 ? resize * 2 : written + 1);
-if (mem != buf)
- MSVCRT_free (mem);
-if (!(mem = (char *)MSVCRT_malloc(resize)))
- return MSVCRT_EOF;
- }
- retval = MSVCRT_fwrite(mem, sizeof(*mem), written, file);
- if (mem != buf)
-MSVCRT_free (mem);
- return retval;
-}
-
-/*
- * vfwprintf (MSVCRT.@)
- * FIXME:
- * Is final char included in written (then resize is too big) or not
- * (then we must test for equality too)?
- */
-int MSVCRT_vfwprintf(MSVCRT_FILE* file, const MSVCRT_wchar_t *format, va_list
valist)
-{
- MSVCRT_wchar_t buf[2048], *mem = buf;
- int written, resize = sizeof(buf) / sizeof(MSVCRT_wchar_t), retval;
- /* See vfprintf comments */
- while ((written = _vsnwprintf(mem, resize, format, valist)) == -1 ||
- written > resize)
- {
-resize = (written == -1 ? resize * 2 : written + sizeof(MSVCRT_wchar_t));
-if (mem != buf)
- MSVCRT_free (mem);
-if (!(mem = (MSVCRT_wchar_t *)MSVCRT_malloc(resize*sizeof(*mem
- return MSVCRT_EOF;
- }
- retval = MSVCRT_fwrite(mem, sizeof(*mem), written, file);
- if (mem != buf)
-MSVCRT_free (mem);
- return retval;
-}
-
-/*
- * vprintf (MSVCRT.@)
- */
-int MSVCRT_vprintf(const char *format, va_list valist)
-{
- return MSVCRT_vfprintf(MSVCRT_stdout,format,valist);
-}
-
-/*
- * vwprintf (MSVCRT.@)
- */
-int MSVCRT_vwprintf(const MSVCRT_wchar_t *format, va_list valist)
-{
- return MSVCRT_vfwprintf(MSVCRT_stdout,format,valist);
-}
-
-/*
- * fprintf (MSVCRT.@)
- */
-int MSVCRT_fprintf(MSVCRT_FILE* file, const char *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vfprintf(file, format, valist);
-va_end(valist);
-return res;
-}
-
-/*
- * fwprintf (MSVCRT.@)
- */
-int MSVCRT_fwprintf(MSVCRT_FILE* file, const MSVCRT_wchar_t *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vfwprintf(file, format, valist);
-va_end(valist);
-return res;
-}
-
-/*
- * printf (MSVCRT.@)
- */
-int MSVCRT_printf(const char *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vfprintf(MSVCRT_stdout, format, valist);
-va_end(valist);
-return res;
-}
/*
* ungetc (MSVCRT.@)
@@ -2753,17 +2646,4 @@
return MSVCRT_WEOF;
}
return mwc;
-}
-
-/*
- * wprintf (MSVCRT.@)
- */
-int MSVCRT_wprintf(const MSVCRT_wchar_t *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vwprintf(format, valist);
-va_end(valist);
-return res;
}
In
Re: Resend: Re-implement MSVCRT *printf functions
Alexandre Julliard wrote: Aneurin Price <[EMAIL PROTECTED]> writes: Any further comments on this? Hard to say, that code is really painful to read. Please try to better follow the coding conventions used in the rest of the code. Apologies for long delay; I've been playing World of Warcraft for the duration of the open beta :-). I don't really understand what it is you want, but I think I'm going to have to give up on this for the moment, until I get enough time to get more coding practice. Aneurin Price
Re: Resend: Re-implement MSVCRT *printf functions
Any further comments on this?
Re: Some conformance tests for msvcrt printf functions
Is there any particular reason this patch hasn't been committed? Something wrong or just overlooked?
Re: Re-implement MSVCRT *printf
Mike McCormack wrote:
Aneurin Price wrote:
Comments, anyone?
Looks like you've put quite a bit of effort into that. I think it's a
worthwhile effort, however, please consider:
* using a style more consistent with the rest of the Wine codebase
Could you elaborate on this point? I'm not sure to what exactly it is
you're referring.
* not abusing the preprocessor in printf.h,
* not writing C code in the header in printf.h
Actually I don't really know why I even called it that, since it was
never really a header, just by analogy with scanf.h I suppose :-), but
see below...
* preventing code duplication by implementing the A functions using the
W functions
The attached patch addresses these points, does it look any better?
I haven't tested it too rigorously yet, since I wanted some feedback
without first spending ages checking it extensively, but it seems to be
fine - just have to make sure I haven't forgotten some corner cases.
* writing some regression tests to show your code is correct
I still don't really know what I might test here. Maybe try examples of
cases where the current code does not act like Windows; there are also
some cases where neither acts like windows (but they seem to have the
same problems). The problem is I probably wouldn't think of cases where
my code causes regressions (otherwise it wouldn't do so:-)), and this
isn't really something in which you can enumerate all the different
combinations of options (at least without infinite time and patience).
Thanks for your comments,
Aneurin Price
Index: dlls/msvcrt/Makefile.in
===
RCS file: /home/wine/wine/dlls/msvcrt/Makefile.in,v
retrieving revision 1.16
diff -u -u -r1.16 Makefile.in
--- dlls/msvcrt/Makefile.in 25 Jun 2004 01:19:15 - 1.16
+++ dlls/msvcrt/Makefile.in 27 Oct 2004 21:55:24 -
@@ -27,6 +27,7 @@
math.c \
mbcs.c \
misc.c \
+ printf.c \
process.c \
scanf.c \
string.c \
Index: dlls/msvcrt/file.c
===
RCS file: /home/wine/wine/dlls/msvcrt/file.c,v
retrieving revision 1.72
diff -u -u -r1.72 file.c
--- dlls/msvcrt/file.c 14 Oct 2004 00:26:39 - 1.72
+++ dlls/msvcrt/file.c 27 Oct 2004 21:55:24 -
@@ -2614,113 +2614,6 @@
return file;
}
-/*
- * vfprintf (MSVCRT.@)
- */
-int MSVCRT_vfprintf(MSVCRT_FILE* file, const char *format, va_list valist)
-{
- char buf[2048], *mem = buf;
- int written, resize = sizeof(buf), retval;
- /* There are two conventions for vsnprintf failing:
- * Return -1 if we truncated, or
- * Return the number of bytes that would have been written
- * The code below handles both cases
- */
- while ((written = vsnprintf(mem, resize, format, valist)) == -1 ||
- written > resize)
- {
-resize = (written == -1 ? resize * 2 : written + 1);
-if (mem != buf)
- MSVCRT_free (mem);
-if (!(mem = (char *)MSVCRT_malloc(resize)))
- return MSVCRT_EOF;
- }
- retval = MSVCRT_fwrite(mem, sizeof(*mem), written, file);
- if (mem != buf)
-MSVCRT_free (mem);
- return retval;
-}
-
-/*
- * vfwprintf (MSVCRT.@)
- * FIXME:
- * Is final char included in written (then resize is too big) or not
- * (then we must test for equality too)?
- */
-int MSVCRT_vfwprintf(MSVCRT_FILE* file, const MSVCRT_wchar_t *format, va_list valist)
-{
- MSVCRT_wchar_t buf[2048], *mem = buf;
- int written, resize = sizeof(buf) / sizeof(MSVCRT_wchar_t), retval;
- /* See vfprintf comments */
- while ((written = _vsnwprintf(mem, resize, format, valist)) == -1 ||
- written > resize)
- {
-resize = (written == -1 ? resize * 2 : written + sizeof(MSVCRT_wchar_t));
-if (mem != buf)
- MSVCRT_free (mem);
-if (!(mem = (MSVCRT_wchar_t *)MSVCRT_malloc(resize*sizeof(*mem
- return MSVCRT_EOF;
- }
- retval = MSVCRT_fwrite(mem, sizeof(*mem), written, file);
- if (mem != buf)
-MSVCRT_free (mem);
- return retval;
-}
-
-/*
- * vprintf (MSVCRT.@)
- */
-int MSVCRT_vprintf(const char *format, va_list valist)
-{
- return MSVCRT_vfprintf(MSVCRT_stdout,format,valist);
-}
-
-/*
- * vwprintf (MSVCRT.@)
- */
-int MSVCRT_vwprintf(const MSVCRT_wchar_t *format, va_list valist)
-{
- return MSVCRT_vfwprintf(MSVCRT_stdout,format,valist);
-}
-
-/*
- * fprintf (MSVCRT.@)
- */
-int MSVCRT_fprintf(MSVCRT_FILE* file, const char *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vfprintf(file, format, valist);
-va_end(valist);
-return res;
-}
-
-/***
Re: Warcraft 3 Copy Protection (regression?)
Brian Gunlogson wrote: Warcraft 3 will not run without a crack after the following commit: http://www.winehq.org/hypermail/wine-cvs/2004/03/0093.html If no one wants to tackle this immediately I'd like to fix it. Any ideas? Brian G. I don't know whether the difference was something about the version of WC3, or because I'd just upgraded to a 2.6 kernel, or because of the Wine version (20040309), but having upgraded Wine to 20040505 it no longer works. Some work was done to load the copy protection drivers, it would be very nice to get this working again. Can you try wine-20040408 to see if it works with that version? You can then pinpoint the regression by running CVS regression testing, instructions are at http://www.winehq.com/site/docs/wine-devel/cvs-regression Ivan. I think this is a message I posted some time ago, which turned out to be user error(sheepish grin) - although in figuring that out I did find another bug which was since fixed:-). Anyway, as far as I'm aware it's currently fine (though copy protection only works if winver is set to one of the NT line). Aneurin Price
Re: Bugzilla Bug 2075: *printf incompatibilities
Mike Hearn wrote:
Aneurin Price wrote:
I've been looking at Warcraft III today, and had the problem of single
player campaigns not showing up. The reason behind this is explained at
http://bugs.winehq.org/show_bug.cgi?id=2075, and sure enough adding the
special case described for the I64 argument type specification solves
the problem in W3. Now I'm wondering how the problem should really be
solved. Currently most (possibly all) of the *printf functions in msvcrt
call MSVCRT_vsnprintfW. Should the same be done for vsnprintf, or should
there be an independent MSVCRT_vsnprintfA? Either way I don't really
know how the implementation would work.
What I'd recommend is submitting a patch which converts the MSVCRT
format string specifiers into glibc style specifiers, and see what
Alexandre says. It should be a small patch.
Well, for that particular function something like the attached
modification should do[0], but obviously it's a bit silly to convert
like that for every function.
Currently all the wide printf functions in mscvrt ultimately call
vsnprintfW (which itself uses native sprintf), though sometimes through
multiple levels of indirection - eg. fwprintf -> vwprintf -> vfwprintf
-> _vsnwprintf -> vsnprintfW or _snwprintf -> ntdll._snwprintf ->
vsnprintfW. Are there reasons for this, or is it just cruft? It looks to
me like it would be a good idea to start by making them all call
vsnprintfW and have that convert the I, I32 and I64 arguments, before
calling sprintf[1].
The non-unicode printf functions seem to call each other arbitrarily
(?), but the native functions used are vsnprintf, snprintf, vsprintf,
and sprintf. It might be worth then making all the functions directly
analogous to their wide counterparts for simplicity.
Finally, I'd like some clarification on what the %S and %C type
specifiers[2] are used for. My understanding is that the
string/character should just be converted to/from unicode as
appropriate, not caring about data loss in the latter case, since that
would only happen when you're using non-unicode functions anyway.
If he isn't happy, find a printf implementation somewhere of a suitable
license, munge it to act in the right way (with test cases ideally) and
submit. That was the way Alexandre seemed to prefer last time this came up.
Maybe I should start looking into how to use register_printf_function [3].
Phew, I hope that made sense :).
Thanks for your help,
Aneurin Price
[0] Though only on 32-bit platforms, since long and long long needn't
always be 32/64 bit? How would one ensure a particular size regardless
of platform?
[1] I don't actually see why vsnprintfW has been made the main printf
function rather than (say) sprintfW, since natively swprintf is used
anyway. This is all assuming that sprintf can be made to act like the
other *printf functions with appropriate arguments, since I haven't
looked into that yet. I'm making this assumption for the moment as
that's what's currently being done:).
[2]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt_printf_type_field_characters.asp
[3]
http://www.gnu.org/software/libc/manual/html_node/Registering-New-Conversions.html#Registering%20New%20Conversions
int _vsnprintf(char *str, size_t len, const char *format, va_list valist)
{
if ((strlen(format) > 5)||(*format!='%')) return vsnprintf (str, len, format, valist);
else
{
char newformat[6];
char *temp=newformat;
while (*format != '\0')
{
if (*format=='I') {*temp++='l'; format++;}
if (*format=='3') format+=2;
if (*format=='6') {*temp++='l'; format+=2;}
*temp++=*format++;
}
*temp='\0';
return vsnprintf (str, len, newformat, valist);
}
}
Bugzilla Bug 2075: *printf incompatibilities
I've been looking at Warcraft III today, and had the problem of single player campaigns not showing up. The reason behind this is explained at http://bugs.winehq.org/show_bug.cgi?id=2075, and sure enough adding the special case described for the I64 argument type specification solves the problem in W3. Now I'm wondering how the problem should really be solved. Currently most (possibly all) of the *printf functions in msvcrt call MSVCRT_vsnprintfW. Should the same be done for vsnprintf, or should there be an independent MSVCRT_vsnprintfA? Either way I don't really know how the implementation would work. I was kind of hoping that this might be an okay place to start learning about WINE development, so if this in fact hinges on something far more complicated than I've been able to grasp, somebody please point this out to me :). Any pointers? Thanks, Aneurin Price
Regression with Blizzard patching software
I recently discovered that the software used by Blizzard to patch Diablo 2 and Warcraft 3 (and possibly the same version used with other games), has stopped working. It starts do do something, but before actually applying the patch it crashes out, with the final error message being: Unhandled exception: page fault on write access to 0x in 32-bit code (0x408ba2e0). In 32-bit mode. 0x408ba2e0 (DIALOG_CreateIndirect+0x300 [dialog.c:636] in USER32.DLL): movl$0x0,0x0(%eax) 139 return TRUE; Wine-dbg>WineDbg terminated on pid a The whole of the scrollback buffer is filled with the usual messages about loading debug information. I could run it with script to see what's happening before that, but I don't think it's really necessary: Since this *used* to work, I've gone through some CVS regression testing and determined that it stopped working sometime between 2004-04-19 22:00:00 and 2004-04-19 22:03:00 CST, so I'm willing to bet that this is what changed: http://www.winehq.org/hypermail/wine-cvs/2004/04/0272.html Since I have no understanding of what's going on here I really coudn't suggest a fix, but I'm happy to provide any further information I can and thought this would be worth pointing out. Aneurin Price
