wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: fixes for -Wmissing-declarations and -Wwrite-strings warnings
by Pouech Eric DMI AEI CAEN 02 Jun '05

02 Jun '05

looking at the patch, I saw something in the code that made me sick: char *audioAutoDetect(void) { [snip] char *driversFound[10]; [snip] return driversFound[0]; [snip] } can someone fix that broken code ? that would be another nice janitorial task to check whether this kind of error exists somewhere else (I'd bet it does) A+

2 1

Re: fixes for -Wmissing-declarations and -Wwrite-strings warnings
by Andreas Mohr 02 Jun '05

02 Jun '05

Hi, On Thu, Jun 02, 2005 at 08:31:36PM +0900, Mike McCormack wrote: > ChangeLog: > * fixes for -Wmissing-declarations and -Wwrite-strings warnings Argh, this is what I had done recently but didn't manage to submit yet. (I told in a mail that I had done programs/ and tools/) > -static char *ignored_fstypes[] = { > +static const char *ignored_fstypes[] = { > "devpts", > "tmpfs", > "proc", > @@ -61,7 +61,7 @@ static char *ignored_fstypes[] = { > NULL > }; Imperfect - it should be static const char * const ignored_fstypes[] since otherwise the ignored_fstypes pointer is still non-const (objdump -x) which it doesn't need to be (may mark more memory pages as read-write than necessary). Sure, your objective was to fix all strict compiler warnings which that patch probably did successfully, but why not go that extra mile... Andreas Mohr

2 1

Winelib MFC app crashes after printing
by Eugene Aksenov 02 Jun '05

02 Jun '05

Hello, I have a small MFC app ported to winelib which uses MFC compiled with winelib. Really, it is just an App-Wizard generated application. I always have a crash of the application after printing. The page is printed ok but after that the app crashes. I use LPD for printing and my command line from wine is 'lpr -P<myprinter>'. I also try to print without MFC support i.e creating the printer DC by hand etc - the crash is the same, it follows EndDoc() call. There is no crash like this at the same linux configuration using in a 'pure' Win32 simple application without MFC though the code for printing is the same. When i print to file, all is ok. So , my current workaround is printing to a temp file and then send the file to lpr. I use RH9.0, wine20050419. My [spooler] section in config is the default from the wine installation. Did anybody meet a problem like that ? Is it MFC that has some impact here ? Thanks a lot for any hints.

2 2

dlls/kernel/tests/locale.c warning regression
by Gerald Pfeifer 02 Jun '05

02 Jun '05

The following change to dlls/kernel/tests/locale.c revision 1.36 date: 2005/05/31 09:30:46; author: julliard; state: Exp; lines: +4 -4 Mike McCormack <mike(a)codeweavers.com> Some warning fixes for the regression tests. actually doesn't fix any warning on FreeBSD 4.x, but adds the following one: locale.c:763: warning: `test_EnumTimeFormats' defined but not used Would you mind looking into that? Thanks, Gerald

1 0

Weirdness in the makefile
by Scott Ritchie 02 Jun '05

02 Jun '05

Can someone explain the significance of these targets in the makefile: manpages: $(MKINSTALLDIRS) $(TOPOBJDIR)/documentation/man3w cd dlls && $(MAKE) man htmlpages: $(MKINSTALLDIRS) $(TOPOBJDIR)/documentation/html cd dlls && $(MAKE) doc-html sgmlpages: $(MKINSTALLDIRS) $(TOPOBJDIR)/documentation/api-guide cd dlls && $(MAKE) doc-sgml Do they do anything? Those don't seem to be valid directories anymore. Thanks, Scott Ritchie

1 0

Re: PATCH: Re: Wine does not build (preloader.c, line 863, a_ptr union)
by Andreas Mohr 02 Jun '05

02 Jun '05

Hi, On Thu, Jun 02, 2005 at 09:10:10AM +0200, Marcus Meissner wrote: > On Thu, Jun 02, 2005 at 03:22:01PM +0900, Mike McCormack wrote: > > > > Ivan Gyurdiev wrote: > > >I hate bothering the -devel list with compile errors, but > > >they don't seem to get fixed, so I start wondering > > >if anyone else besides me is using gcc4 at all.. > > > > > >preloader.c: In function ???is_in_preload_range???: > > >preloader.c:863: error: ???union <anonymous>??? has no member named > > >???a_ptr??? > > >preloader.c:864: error: ???union <anonymous>??? has no member named > > >???a_ptr??? > > > > This is more likely to be a problem with your headers than with gcc. > > No, this is the start of this years approach to break WINE from our friends at glibc. > > a_un.a_ptr no longer exists in the elf aux vector struct. Darn, can't they use a magic keyword or similar mechanisms to mark elements scheduled for clean removal right before the next major version?? (and not out of sudden within almost the same version number) OK, some changes in that area might be non-trivial, so they do it when they feel like doing it, but I really doubt that this is the majority. But OTOH projects have to do binary incompatible changes a bit before the release of the next major version, otherwise there won't be any testing. And perhaps glibc is in such a version change phase right now... Andreas Mohr

1 0

Re: Age of Empires 2 splash screen
by Jesse Allen 01 Jun '05

01 Jun '05

On 6/1/05, Ivan Leo Puoti <ivanleo(a)gmail.com> wrote: > I actually got this for the first time a few days ago, but I thought I > might as well share it as I think it's cool. AFAIK DMCA compliant code > has never got this far with safedisc 1. > http://www003.portalis.it/115/download/aoe.png > > Ivan. > > > Was this with the current wine tree?

2 1

DCOM and Google's Summer of Code
by Ivan Pechorin 01 Jun '05

01 Jun '05

Hello! I'm in trouble trying to estimate effort needed to implement marshalling interoperable with MS. Is it a right task for 2-2.5 months of Google's "Summer of Code"? Best regards, Ivan Pechorin.

5 8

Re: Add a window station server object
by Robert Shearman 01 Jun '05

01 Jun '05

Robert Shearman wrote: > Changelog: > Add a window station server object. Alexandre, Do you want me to flesh out the window station object and add some server calls before committing this work or is there something else? -- Rob Shearman

2 1

Re: dlls/gdi/dib.c GetDIBits
by Uwe Bonnes 01 Jun '05

01 Jun '05

>>>>> "Ulrich" == Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: Ulrich> This patch fixes a regression that happened quite sometime Ulrich> ago. We don't always fill in the BITMAPINFO struct fields on the Ulrich> way out and this broke my app because it uses these values to Ulrich> allocate enough memory to hold the bits. Ullrich, I see a lot of indentation change and only 2 or 3 lines of real code change. Can you perhaps resent with the real code change better visible? I have a problem with CopyImage, maybe it is affected by the regression you fix. Tagging the changes for debugging can help me to be sure about the change. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 2

Age of Empires 2 splash screen
by Ivan Leo Puoti 01 Jun '05

01 Jun '05

I actually got this for the first time a few days ago, but I thought I might as well share it as I think it's cool. AFAIK DMCA compliant code has never got this far with safedisc 1. http://www003.portalis.it/115/download/aoe.png Ivan.

1 0

Re: Borland C++ 4.5
by gslink 01 Jun '05

01 Jun '05

This started happening on FC3 with the 2.6.11 kernels in programs running under the Sun 1.42 jre. I was using the Nvidia driver supplied with the kernel. I changed to the driver posted on the Nvidia web site and have had no further trouble. I tried to duplicate the problem but it happened so infrequently that I could never quite find it. I am not sure that this problem is with Wine.

2 1

Print unicode strings in tests
by Paul Vriens 01 Jun '05

01 Jun '05

Hi, I'd like to print unicode-strings in some tests (for debugging purposes). The following however does not show nice output on wine (it does on windows): static const WCHAR dataW[] = {'S','o','m','e',' ','d','a','t','a',0}; UNICODE_STRING usdata = { sizeof(dataW)-sizeof(WCHAR), sizeof(dataW), (LPWSTR)dataW }; trace("Length is %d\n", usdata.Length); trace("Maximum Length is %d\n", usdata.MaximumLength); trace("The strings is %ls\n", usdata.Buffer); Our trace doesn't seem to be able to cope with %ls (or %S). Any ideas ? Cheers, Paul.

3 2

Re: Optionally map the unix filesystem instead of drive letters into the shell namespace
by Michael Jung 01 Jun '05

01 Jun '05

Hi Michael, On Friday 27 May 2005 03:03, Michael Lin wrote: > Just a few things with this approach. > As I mentioned before .. with a global flag in the registry. > User can't run a winelib application with unix path and a Windows > application on Wine with dos path at the same time. Please consider the configure based global flag only an option. That's actually what I said several times. It could be a per application option as well. And there is no problem in activating it via a wine-specific API, which would override the config on a per process basis. > Ok ... I know your approach is base everything on dos path and the > global flag is simply a display mode. > But what about the parsing of the file name editbox in the file dialog? > The user is browsing unix file system, but does the user enter unix or > dos path? > I believe I can modify your solution to accept unix file path, but it > have to accept dos path as well. Modifying shfldr_unixfs to parse unix path in addition to dos paths is trivial: Just remove the (pUnixFolder->m_dwPathMode == PATHMODE_UNIX) test in line 339. The real problem is the test for invalid chars in the filedialog, which '/' is one of. The solution is obvious: If wine is configured to display unix paths, then accept '/' as a valid char in paths in comdlg32. You will have to do this for your solution as well, don't you? > Then there is also the issue of having to have the unix root mapped to a > dos drive. That's true. Actually, we are tackling two slightly different problems here: I would like to have existend applications, for which I don't have the source, to display unix paths instead of dos paths in their file dialogs. So I want MS Office to display unix paths in it's file dialogs. IMHO there is not way to achieve this without the requirement to map one of the dos drives to '/'. At least not if the user should be able to access every file on his filesystem. This solution can also be applied to winelib applications. If you want to use the native posix file functions (which, frankly, I don't see a reason to do, because the user doesn't care how filenames look in the core dump, but only how they look on the screen) then just map the paths coming out of the file dialog to unix with the wine_nt_to_unix_path function. I do understand that there are some shortcomings of this approach for winelib applications, which can not possibly be addressed this way. But it seems equaly obvious to me that your approach can never achieve the goal I laid out above (To make native apps display the unix paths in file dialogs). So perhaps there might be demand for both solutions. Or perhaps I'm totaly off the point and the only person on the planet who likes to see unix paths in his native windows applications on wine. Which would mean your solution might be the only one people are interested in. What I meant to say is, please fell free to implement your solution the way you like it and let the wine community decide on it. But please don't modify shfldr_unixfs in a way that breaks my solution (Conceptually, that is. Bugs, of course, are unavoidable.) > Troy, Alexandre and I have been discussing other possible solutions to > this problem offline. I don't want to offend, but I think this just isn't fair. I have contributed a lot of my free time working on this stuff, and I think I would have deserved to be informed on discussions and decisions in this matter. Above that, this kind of discussion should take place on wine-devel, so that the community at large can take part in it. To me this gives the impression that you avoided discussing it on wine-devel, because you didn't want to be convinced. Sorry. Ok, nuff said, going back to the technological stuff. > One solution I have implemented and waiting on Alexandre's verdict is > the following. > > Create a new library called wineunixfs. All additional entry point > should be in that library. > All exported function call should be of the same signiture as one in the > core library such as GetOpenFileNameA(), GetOpenFileNameW() etc. > To use the library, simply let winelib application link it before all > the other core libraries. > > My Changes to the core libraries are contained within shell32. There is > only one extra exported functions SHUnixFSGetDesktopFolder() being > added. This function return the desktop folder in unix mode. > > Currenlt wineunixfs duplicates filedlg.c, filedlgbrowser.* and their > dependent files from commdlg. > I have attached the diff file for the rest of the changes that's on the > core libraries. I'm not the one to judge, but in my opinion this is pretty heavy weight. Ciao, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 3

Re: Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs
by Robert Shearman 01 Jun '05

01 Jun '05

Evan Deaubl wrote: >ChangeLog: > * Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs > > I cleaned up the patch a little. Does this still work for you? Changelog: Evan Deaubl <wine(a)warpedview.com> Robert Shearman <rob(a)codeweavers.com> - Implement RtlGetControlSecurityDescriptor - Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs -- Rob Shearman

2 1

Borland C++ 4.5
by Andrew Neil Ramage 31 May '05

31 May '05

When I tried to install BC++ 4.5, the installation proceeded normally. However, when I clicked "Finish", it trashed my X server, causing the system to stop responding to key presses and the mouse. I could not even kill the X server, and so had to pull the power cord out. Is this a known problem, and will I still be able to use my Development identity ? -- Andrew You can be the captain I will draw the chart Sailing into destiny Closer to the heart Closer to the Heart by Rush (A Farewell to Kings, 1977) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

7 9

Re: wine/dlls/setupapi parser.c
by Robert Shearman 31 May '05

31 May '05

Alexandre Julliard wrote: >Index: wine/dlls/setupapi/parser.c >diff -u -p wine/dlls/setupapi/parser.c:1.15 wine/dlls/setupapi/parser.c:1.16 >--- wine/dlls/setupapi/parser.c:1.15 Tue May 31 17:10:06 2005 >+++ wine/dlls/setupapi/parser.c Tue May 31 17:10:06 2005 >@@ -852,7 +852,9 @@ static DWORD parse_buffer( struct inf_fi > struct parser parser; > const WCHAR *pos = buffer; > >- parser.start = buffer; >+ if (*pos == 0xfeff) pos++; /* skip Unicode BOM signature */ >+ >+ parser.start = pos; > parser.end = end; > parser.file = file; > parser.line = NULL; > This shouldn't be necessary. The Unicode BOM (or Zero Width Non-Breaking Space) has CT_CTYPE1 of C1_SPACE | C1_BLANK so it should be skipped just like any other whitespace character. -- Rob Shearman

2 1

Re: Default setting for RelayExclude
by Mike Hearn 31 May '05

31 May '05

On Thu, 26 May 2005 01:15:45 +0100, Mike Hearn wrote: > Mike Hearn <mh(a)codeweavers.com> > Default setting for RelayExclude Alexandre, any reason this didn't get in? thanks -mike

2 2

Re: Fix implicit loading of 16bit GDI & USER
by Alexandre Julliard 31 May '05

31 May '05

Richard Cohen <richard(a)daijobu.co.uk> writes: > Changelog > Implicitly loaded 16bit GDI & USER need an EXE extension This is wrong, the EXE extension is present in the module filename, the loader shouldn't need to know about it. The problem is probably that GDI isn't pre-loaded, which is the case for 32-bit apps now that GDI no longer needs the local heap. What app is causing the problem? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [Fwd: Re: Extending File Dialog to include unix file paths]
by Michael Lin 31 May '05

31 May '05

Hi Alexandre, I haven't got a reply from you on this issue yet. Please let me know what you think of the patch. Thanks, Michael Michael Lin wrote: > Hi Alexandre, > > I have made the changes as you suggested to put all the entry point in > one single library. > > Basically, I have created a new library called wineunixfs. > It currently contain modified version of filedlg.c and > filedlgbrowser.* and all their dependent files from commdlg. > > I have attached the diff file for the rest of the changes that's on > the core libraries. > I didn't attach the files in wineunixfs as you seems ok with > duplicating code there and modify it there. > > Most of the changes are contained within shell32 libraries to make it > aware of whether it is in unix or dos path mode. > There is only one exported function been added and that is > SHUnixFSGetDesktopFolder() in shell32. > > Could you please take a look at the patch and let me know if this is > "clean" and acceptable. > > Thanks, > Michael >

2 1

Re: tab: Shift selected tab text up instead of down [RESEND]
by Mike McCormack 31 May '05

31 May '05

> + if (iItem == infoPtr->iSelected) > + center_offset_v = ((drawRect->bottom - drawRect->top) - (rcText.bottom - rcText.top) - infoPtr->uVItemPadding) / 2; > + else > + center_offset_v = ((drawRect->bottom - drawRect->top) - (rcText.bottom - rcText.top) + infoPtr->uVItemPadding) / 2; Wouldn't it be clearer as: center_offset_v = (drawRect->bottom - drawRect->top) + (rcText.bottom - rcText.top); if (iItem == infoPtr->iSelected) center_offset_v -= infoPtr->uVItemPadding; else center_offset_v += infoPtr->uVItemPadding; center_offset_v /= 2; That breaks up the long lines, and eliminates the common sub-expressions... Mike

1 0

generic.ppd isn't installed anymore
by Vincent Béron 31 May '05

31 May '05

Hi, wineps/generic.ppd isn't installed anymore since a couple weeks ago (didn't had time yet to pinpoint exact patch). I think it's because only __install-lib__ and __install-dev__ is done in dlls/ now, and not __install__, which is the target actually installing wineps/generic.ppd. A quick'n dirty way is to run make -C dlls/wineps install after make install but it should really be fixed properly I guess. Vincent

1 0

Re: wine/dlls/x11drv keyboard.c
by Francois Gouget 31 May '05

31 May '05

On Sun, 29 May 2005, Alexandre Julliard wrote: [...] > Log message: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Fix Estonian keyboard layout to better match the X11 one. I have noticed that we get a steady trickle of these. Shouldn't it be possible to get the definitions of all keyboards from the XFree sources and find some way to automatically import them? The other trickle we're seeing is with timezones. So in a similar way maybe we could get the data from the site below and import it all: http://www.timeanddate.com/library/abbreviations/timezones/ Would this make sense? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

3 2

Re: OLEAUT32 (resend) Floating point locale, no negative zero
by Alex Villacís Lasso 30 May '05

30 May '05

Alexandre Julliard wrote: > Alex Villacis Lasso <a_villacis(a)palosanto.com> writes: > > > >> Changelog: >> * Force Single|Double conversion to BSTR to use the decimal separator >> defined by the current locale, because that is what native oleaut32 >> does, and to be consistent with later parsing of floating-point >> numbers, which uses current locale. Failure to apply this patch causes >> vartype test to fail in non-US locales with a decimal separator other >> than a period. >> * The number form "-0" is *not* allowed to be returned in a >> Single|Double conversion to BSTR in case of numeric undeflow, use >> unsigned zero instead. Some applications depend on this. Test included. >> > > > That's ugly, I think we really want to do our own formatting instead > of using the system printf and hacking the string afterwards. > > > By "our own formatting", do you mean to reimplement the %f and %lf functionality of the system printf() in a Wine-specific function? It can be done, of course, but I thought there was a good reason for the original code to rely on the system printf() for the floating-point formatting. Then there is the question of whether the potential patch is still allowed to use GetNumberFormatW for the (dwFlags & LOCALE_USE_NLS) case. This function seems to relay on the decimal separator being a period (as built by sprintfW). A more recent patch I sent used GetNumberFormatW for the non-NLS case to achieve the substitution of the period for whatever the decimal separator was in the current locale. However, GetNumberFormatW() cannot do anything about the negative zero issue, so that was still handled in the VARIANT_BstrFromReal() function of vartype.c. How much formatting should the new formatting function do? Is it enough to handle the negative zero and the decimal separator, and use sprintfW() for the LOCALE_USE_NLS case (as the current code does), or does it have to reimplement the functionality currently delegated to GetNumberFormatW()? I will start making a patch assuming the first scenario (use new function just for non-NLS case). Please answer if anybody thinks it should be done otherwise. Alex Villacís Lasso

1 0

CryptUnprotectData undeclared - cannot compile
by Pavel Troller 30 May '05

30 May '05

Hi! For some time, about 10 - 14 days, I cannot compile wine from CVS anymore. The reason is as follows: make[3]: Entering directory `/usr/src/emul/wine/dlls/crypt32/tests' ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole protectdata.o testlist.o -o crypt32_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/crypt32 -L../../../libs -lcrypt32 -s -L/opt/ungif/lib protectdata.o(.text+0x3b5): In function `test_cryptunprotectdata': /usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:114: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x42f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:120: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x4b9):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:129: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x54f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:140: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x702):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:160: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x782):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:167: more undefined references to `CryptUnprotectData' follow collect2: ld returned 1 exit status The same reported another user on the user's list, but nobody noticed it. It would be nice to fix this problem to be able to compile wine again. With regards, Pavel Troller

4 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel