wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: Change some d3d9 RACE( "stub ") into FIXME ("stub")
by Lionel Ulmer 04 Jan '05

04 Jan '05

On Tue, Jan 04, 2005 at 05:21:41PM +0000, Mike Hearn wrote: > One thing to be aware of when doing this is that some of these calls may > be used very frequently, and the cost of outputting a fixme for each one > is high. Because TRACEs are not output by default making a stub a TRACE is > often used in this situation. Not to mention the users who will generate bug reports saying 'look it does not work because of this FIXME' whereas this FIXME is just for an obscure function which does not do anything important and can be let as a stub for ages. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: Native unix style paths in wine common dialogs
by Mike Hearn 04 Jan '05

04 Jan '05

On Tue, 04 Jan 2005 11:22:00 -0500, Dan Notestein wrote: > This patch allows winelib to be conditionally compiled with > USE_NATIVE_UNIX_PATHS macro. Enabling this will cause > the common dialogs to display using unix paths instead of drive > letters. Fantastic! What would rule even more is if this was not a conditional compilation flag, but something that could be toggled at runtime. That way you can have a single Wine installation that has both half-native winelib apps and regular win32 binaries run at once. As it is, this patch is only really useful for when you are distributing your own app-specific copy of Wine, no? > Btw, if anyone is interested we also have another module which > can be used to convert the windows-style drive letters returned > by the common dialogs into unix-style paths (if you want to use > these paths will "normal" file i/o functions such as C++ stream i/o). Isn't that what wine_get_unix_file_name does? thanks -mike

2 1

Re: keybd_event patch and default combobox height patch
by tony_lambregts＠telusplanet.net 04 Jan '05

04 Jan '05

Peter Hercek wrote: > server/queue.c > Fixes an error in keybd_event function. This function sends events even > between different processes on win32. This was not handled in wine. > > dlls/user/combo.c > The default size for comboxes was 2 pixels bigger in wine at the > standard dpi. > > The patches are against wine 20041019. > > Index: server/queue.c > =================================================================== > --- server/queue.c (revision 29655) > +++ server/queue.c (working copy) > @@ -1073,6 +1073,8 @@ > *msg_code = msg->msg; > if (is_keyboard_msg( msg )) > { > + if (!input || !(input->focus) || !(input->active)) > + input = foreground_input; > if (input && !(win = input->focus)) > { > win = input->active; > Index: dlls/user/combo.c > =================================================================== > --- dlls/user/combo.c (revision 29655) > +++ dlls/user/combo.c (working copy) > @@ -207,8 +207,10 @@ > * The height of the text area is set in two ways. > * It can be set explicitly through a combobox message or through a > * WM_MEASUREITEM callback. > - * If this is not the case, the height is set to 13 dialog units. > - * This height was determined through experimentation. > + * If this is not the case, the height is set to 12 dialog units. > + * This height was determined through experimentation. It was > + * set to 13 originally but this led to higher comboboxes than > + * in windows. > */ > static INT CBGetTextAreaHeight( > HWND hwnd, > @@ -239,7 +241,7 @@ > > ReleaseDC(hwnd, hDC); > > - iTextItemHeight = ((13 * baseUnitY) / 8); > + iTextItemHeight = ((12 * baseUnitY) / 8); > > /* > * This "formula" calculates the height of the complete control. > > These should have been sent as two separate patches. since they address two different issues. -- Tony Lambregts

1 0

Changed files to use interlocked functions
by Paul Vriens 04 Jan '05

04 Jan '05

Hi, the Janitorial page shows that the "Use Interlocked functions in AddRef and Release methods" project is finished. There are however several files (at least 135) that still use the non-interlocked method. Especially ddraw, d3*, dm*, avifil32 and some ole/oleaut32. Do they still need to be changed ? Cheers, Paul.

4 5

Re: gdi/tests/metafile.c NT 4 fix
by Dmitry Timoshkov 04 Jan '05

04 Jan '05

"Jakob Eriksson" <jakov(a)vmlinux.org> wrote: > --- dlls/gdi/tests/metafile.c 27 Dec 2004 17:46:36 -0000 1.4 > +++ dlls/gdi/tests/metafile.c 3 Jan 2005 14:27:55 -0000 > @@ -185,8 +185,6 @@ > ret = EnumEnhMetaFile(hdcDisplay, hMetafile, emf_enum_proc, dx, &rc); > ok( ret, "EnumEnhMetaFile error %ld\n", GetLastError()); > > - ok(emr_processed, "EnumEnhMetaFile couldn't find EMR_EXTTEXTOUTA or EMR_EXTTEXTOUTW record\n"); > - This defeats the whole purpose of the test, could you investigate what is going on? -- Dmitry.

2 1

Re: [LOSTWAGES] Add a short blurb about what Wine is on the About page
by Tom 04 Jan '05

04 Jan '05

Mike McCormack wrote: > > Index: templates/en/about.template > =================================================================== > RCS file: /home/wine/lostwages/templates/en/about.template,v > retrieving revision 1.15 > diff -u -r1.15 about.template > --- templates/en/about.template 1 Dec 2004 22:15:11 -0000 1.15 > +++ templates/en/about.template 4 Jan 2005 07:32:05 -0000 > @@ -4,6 +4,12 @@ > > <h1>About Wine</h1> > > +<p>Wine is a translation layer (a program loader) capable of running > +Windows applications on Linux and other POSIX compatible operating > +systems. Windows programs running in Wine act as native programs would, > +running without the performance or memory usage penalties of an emulator, > +with a similar look and feel as other your desktop.</p> What about: with a similar look and feel as other applications on your desktop. Tom

1 0

Re: build problem on current cvs [fixed]
by Dan Kegel 04 Jan '05

04 Jan '05

Jack wrote in http://www.winehq.org/hypermail/wine-devel/2004/12/0720.html : >>Program received signal SIGSEGV, Segmentation fault. >>0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 >>(gdb) bt >>#0 0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 >>#1 0x4009d06c in malloc () from /lib/i686/libc.so.6 >>#2 0x080525a0 in pp_xmalloc (size=11) at ../../../wine/libs/wpp/preproc.c:80 >>#3 0x0805264a in pp_xstrdup (str=0xbfffec68 "\"11:25:54\"") >> at ../../../wine/libs/wpp/preproc.c:108 >> >> > It is probably caused by overwritting the allocated memory. The last > changes of widl look well so I think it is > some old hidden problem. Lookng at code I found a potential bug, but I'm > not sure if it a bug. In parsers, > both widl's and wpp's, strings are not duplicated whie adding to > structures. If it helps, I'll see if it is correct at all. > This is included in diffs: wppppy.diff and widl.diff. Could you try it? > I also found another small bug in wpp, but > it's not what we're looking for. I included it with some code cleanup in > wpppreproc.diff. I swear I found this same error several months ago, but never submitted a patch (and can't find my old patch now). Your three patches solved the widl crash in current cvs for me. Alexandre, can you review / apply them? Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Should we get rid of the wine-license list?
by Scott Ritchie 03 Jan '05

03 Jan '05

Looking at the archives it appears that wine-license has had very little traffic, to the point where a lot of it is probably not being read when it comes up, since people like me are not subscribed to that list. It seems like a lot of the stuff being sent there should instead go to wine-devel. Thoughts? Scott Ritchie

7 7

Hyperthreading and SMP
by Kenneth Porter 03 Jan '05

03 Jan '05

Does WINE have any problem with either Hyperthreading or SMP? I've found that locking the Tribes Vengeance dedicated server to a single logical CPU seems to give me better performance as the server fills with players. CPU usage seems significantly lower (45% versus 65%). Is this likely to be a WINE issue or a TV issue? (TV is based on the Unreal Tournament engine, with the Havok physics engine integrated to handle vehicle. Alas, unlike UT2004, there's no native Linux server for TV.) More here: <http://lists.matureasskickers.net/pipermail/tvservers/2004-December/000186.…> I want to try disabling HT or setting affinity on my co-admin's Win2003 server to see if he sees the same boost.

2 4

spy.c in debug output
by Vitaly Lipatov 03 Jan '05

03 Jan '05

Can anyone tell me why we can't use functions from windows/spy.c for debugging purposes (in TRACE output) in any dlls/ modules? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

5 8

Re: USER32: result of ScrollBar functions review
by Dmitry Timoshkov 03 Jan '05

03 Jan '05

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > +/* New Scrollbar info since Windows 98, Windows NT 4.0 with SP6 */ > +typedef struct tagSCROLLBARINFO > +{ > + DWORD cbSize; /* Size of SCROLLBARINFO struct */ ... > +BOOL WINAPI GetScrollBarInfo(HWND hwnd, LONG idObject, LPSCROLLBARINFO psbi) > +{ > + RECT rect; > + INT arrowSize, thumbSize, thumbPos, nBar, vertical; > + FIXME("check me"); > + if (psbi->cbSize != sizeof(RECT)) > + return FALSE; Why are you testing psbi->cbSize for sizeof(RECT) here? -- Dmitry.

2 1

Lostwages updates
by Scott Ritchie 03 Jan '05

03 Jan '05

There have been a few patches submitted to lostwages over the past few weeks that are still uncommitted. Are you still on vacation Jeremy? Should we resend? Thanks, Scott Ritchie

3 2

Re: convert TCM_ messages (dec->hex)
by Dmitry Timoshkov 03 Jan '05

03 Jan '05

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > As we have debug printing of messages in hex format > and can't use SPY_GetMsgName for their human readable output > I replace decimal const by their hex values I'd suggest to make debug output look like (TCM_FIRST + decimal) instead of making Wine headers hard to read. -- Dmitry.

1 0

Re: Support for running Winelib apps directly
by Boaz Harrosh 03 Jan '05

03 Jan '05

Vincent Béron wrote: >Remove the loader script from Winelib apps. Winelib apps are still .so >files, but they can be launched directly now. > > > We did try to keep up with what wineapploader and wine did to load a fake-dll winelib app and all the spec.c magic that linked it all. Could you please elaborate a bit on what has changed and how it is all glued together? Is the embedded wineapploader Process reused for the main process for easier debugging? Currently when you debug a winelib app under GDB you cannot use wineapploader you need to use wine-kthread/pthread directly, and disable execshild and friends all together. Will that be at all possible now? Do you think it can be easier now for a: let's call it Unix app, to become a winelib application mid-flight. Lets say, when it wants to load a PE plug in DLL. (The way of mono and that Audio program can't recall the name). Could a UnixODBC (elf dynamic lib) force a load on a PE ODBC driver, therefor making the running app a winelib, Like PHP for example? If so could you make a little hello-world example of how it is done? Grate work Free Life Boaz

2 1

December 2004 - more patches than you can shake a stick at
by Mike Hearn 03 Jan '05

03 Jan '05

Happy new year everybody! Being the patch fetishist that I am, I couldn't help noticing that in December 2004 we cleared 8mb of patches: that's by far the largest since the current archives began in October 2000. The extra traffic came from a lot of places: - Huge improvements to the Application Database. - The number was also pushed higher by an MSI merge from CodeWeavers. - Some big janitorial patches went in from Michael Stefaniuc - Finally Rob and I were cranking out DCOM patches, and there are of course lots more in the pipeline. Now time for some crystal ball gazing. Here are some interesting patches we might be seeing in 2005: - Completion of the WM rewrite work. Alexandre seems to be making great progress on this, which will let us fix many of the odd visual corruption problems we've been plagued with for so long. It'll also let us remerge Alexs winedesktop patch, giving us a real desktop window that is used for all apps, at last. It should have many other benefits too: fixing the flickering in the Half Life menus and allowing us to support the NETWM fullscreen protocol. This should let us resolve many instances of the "my game starts but I can't type" problem. - Lots more DCOM code. Huw Davies is hacking on getting widl to produce a stdole32.tlb file, once that's in we can start really nailing InstallShield to the wall. We will hopefully get this and the thread-affinity patches in the next few months, which should mean for the first time we can run InstallShield 6 installers perfectly, out of the box. Support for newer InstallShields will come as time permits of course. - More MSI improvements! CodeWeavers are continuing to work on this so it should develop nicely even though the iTunes installer work has been completed. Office 2003 will also motivate this. It's being used by at least one commercial app porting project as well. - Support for running Winelib apps directly, so we can get rid of the .exe.so extensions/shell wrapper scripts, and produce "raw" ELF binaries. They'll still need the wine loader app to be present of course, but it should all be invisible and behind the scenes. Vincent Beron and I have been working on this in the last week or so, and we just need to finish it off and convince Alexandre the extra assembly is worth it! :) Who knows what the new year will bring? More apps working out of the box, that's for sure! Have fun! thanks -mike

4 5

Re: Support for running Winelib apps directly
by Boaz Harrosh 03 Jan '05

03 Jan '05

1 0

Approving of the WINEprobe initiative
by David Gümbel 02 Jan '05

02 Jan '05

Hello everybody, - as my colleague Stefan Munz has already pointed out recently[1] on this list, Wirtschaftsförderung Region Stutgart GmbH (WRS) and us (ITOMIG) are launching an initiative called WINEprobe[2]. Its goal is to make local software vendors aware of the potential bussiness opportunity in a WINE-based port or a WINE/Linux version of their software. WRS is quite committed as far as Open Source is concerned[3], and is pushing OSS in the region since quite a time. It has co-organized, among others, the KDE World Summit 2004 in Ludwigsburg near Stuttgart[4]. The Perlworkshop 6.0 , GUADEC6 (GNOME Conference) [5], ApacheCon Europe and more than 40 other Open Source Events in the Stuttgart Region are organized or supported by the WRS as well. (You can find a description of WRS at the bottom of this mail.) In order to make the WINEprobe initiative beneficial for the WINE project as much as possible, three things are in the making: 1) At the option of the respective software vendor whose product we'll be analyzing for WINE compatibility, Application Database Entries will be maintained by us once a software product has been analyzed for its compatibility with WINE. 2) Reports of successful porting or migration projects will be given back to the community as success stories. My colleage is already working on merging some success stories supplied by third parties (see [6]). 3) WRS has offered to help out in hosting the WINE developers conference Wineconf in 2005 in the Stuttgart area[7]. Mr. Schmid from WRS has asked me (please see the mail below) to provide some information about this initiative to the WINE community. He thinks (and I agree ;) that it would help us a great deal in making the campaign a success if the WINE community somehow "officially" (as official as a community can be :) approved of this initiative. So my question, on behalf of Mr. Schmid, is simply if there are objections against us saying that this initiative is approved of by the WINE community? As an important sidenote, I permit myself to emphasize that all of our above mentioned efforts (1-3) to support the WINE project and its community are fully independent of the answer of this question. Most particularily, the hosting offer stands, and the commitment there won't be lowered if the WINEprobe is not approved of by the community. However, I feel that a successful WINEprobe will be a benefit for the WINE project as well. If there are any questions open, please feel free to ask. Cheers, David ---------- Forwarded Message ---------- Subject: AW: Update on WRS offer & Stuttgart University Date: Montag 20 Dezember 2004 14:46 From: "Hans-Ulrich Schmid" <hans-ulrich.schmid(a)region-stuttgart.de> To: David Gümbel <david.guembel(a)itomig.de> Dear Mr. Gümbel, as you know, ITOMIG and Stuttgart Region is planning to start a new initiative for small and medium software companies called "WINEprobe". "WINEprobe" will help these companies to learn more about the WINE-compatibility of their software products. It would be very helpful, if you can ask the WINE-community to support this new initiative officially. The hosting offer of the Stuttgart Region will not be affected by any way of the decision of the community in the point of supporting the "WINEprobe" or not. Can you please forward this mail to the community and tell them some more about the background of "WINEprobe" Best regards Hans-Ulrich Schmid Wirtschaftsförderung Region Stuttgart GmbH Stuttgart Region Economic Development Corporation FIR_st - Forum IT-Region Stuttgart Friedrichstr. 10 70174 Stuttgart www.first.region-stuttgart.de www.opensource.region-stuttgart.de www.competenzatlas.de www.region-stuttgart.de Tel ++49.711.22835 - 27 Tel mobil ++49.172.7310463 Fax ++49.711.22835 - 55 ------------------------------------------------------- ------------------------------------------------------- WRS description: The Stuttgart Region Economic Development Corporation (WRS) is - founded to provide services to industry and communities in the field of economic development - a subsidiary of the administrative body of the larger Stuttgart Region - provides marketing for the Stuttgart Region - assists in cluster management of specific industries - advises and assists companies during the search for available sites and buildings In the context of our initiative "Open Source Region Stuttgart" http://opensource.region-stuttgart.de the WRS supports conferences and meetings of Open Source projects of various aspects when held in the Stuttgart Region. For example the WRS is co-organizer of the KDE Community World Summit 2004 in Ludwigsburg near Stuttgart http://conference2004.kde.org/ . The Perlworkshop 6.0 , GUADEC6 (GNOME Conference) http://2005.guadec.org/papers.html , ApacheCon Europe and more than 40 other Open Source Events in the Stuttgart Region are organized or supported by the WRS as well. ------------------------------------------------------- [1] http://www.mail-archive.com/wine-devel%40winehq.org/msg11549.html [2] WINEprobe means be something like WINEtasting in english an maybe "degustation de WINE" in french. [3] See http://opensource.region-stuttgart.de/ (.de only, sorry) [4] http://conference2004.kde.org/ [5] http://2005.guadec.org/papers.html [6] http://www.mail-archive.com/wine-devel%40winehq.org/msg11630.html [7] http://www.winehq.org/hypermail/wine-devel/2004/11/0647.html

8 14

`__ctype_b' .. `__ctype_toupper'
by Dietrich Teickner 02 Jan '05

02 Jan '05

Hi, I have updated to suse 9.1. After them I have this error. Where must be this definitions ? Dietrich ../../libs/libwpp.a(y.tab.o)(.text+0x2827): In function `combine_mtext': /home/sao2l02/Wine/wine/libs/wpp/./ppy.y:626: undefined reference to `__ctype_b' ... ../../libs/libwpp.a(lex.yy.o)(.text+0x3051):/home/sao2l02/Wine/wine/libs/wpp/./ppl.l:1078: undefined reference to `__ctype_b' ../../libs/libwpp.a(lex.yy.o)(.text+0x3bfe): In function `is_c_h_include': /home/sao2l02/Wine/wine/libs/wpp/./ppl.l:1411: undefined reference to `__ctype_toupper' collect2: ld returned 1 exit status make[2]: *** [widl] Fehler 1 make[1]: *** [widl] Fehler 2 make: *** [tools] Fehler 2

3 2

Re: oleaut.c small change to former patch an some more
by Marcus Meissner 02 Jan '05

02 Jan '05

On Sat, Jan 01, 2005 at 04:25:34PM +0100, Dietrich Teickner wrote: > Hi Alexandre, > > I have some problems with SysReAllocStringLen in Odin(wine for os/2) and > the win32 MySqlQueryBrowser.exe. And I thing wine will have some times > the same. I thing we can / need no memcpy, if str and old the same > before realloc. We can reset the source (str) to NULL in this case. This > should solve the problem for wine and odin. While we do not really need memcpy here, I think we should understand the real problem you see. Is there any problem? What exactly is not working? (explaining what you do in Mysqlquerybrowser is ok, I have it running here.) Your patch would not handle a potential truncation if the "len" parameter is changed, right? Can you provide a testcase snippet for dlls/oleaut32/tests/vartype.c::test_SysReAllocStringLen() that shows different behaviour between real Windows and WINE? Ciao, Marcus

1 0

loading native binaries
by Ivan Leo Puoti 01 Jan '05

01 Jan '05

Alexandre, your patch doesn't perform relocation, and this causes and access violation in secdrv.sys To perform relocation, we need to be able to write to memory, but there appears to be some sort of problem with this that causes wine to hang. I'm attaching your original patch, plus an updated one that Laurent Pinchar and I have come up with, it should work *in theory*, but it doesn't. Laurent has suggested that maybe it would if the image was aligned to a page boundary, but I'm to tired to look into it now. I'm cc'ing wine-devel, ideas/patches welcome. Ivan.

1 0

Re: Remove heap.h
by Jon Griffiths 01 Jan '05

01 Jan '05

Hi, >>+ docA.lpszDocName = WtoA( doc->lpszDocName ); >>+ docA.lpszOutput = WtoA( doc->lpszOutput ); >>+ docA.lpszDatatype = WtoA( doc->lpszDatatype; >> >Isn't there a missing parenthesis? There sure is, I must have deleted it while removing the cruft from the diff (since it compiles fine on my box at home :). I'll resubmit. (Dimitrie) >Because in 99.99% of cases you don't want to convert from W->A. >If all our functions are Unicode, a W->A conversion is a warning >sign, and for sure you wouldn't want to encourage people to do >so by making it any easier. winapi_check will allready tell us all cross-calls anyway, doesn't it? It may be years before all the a to w conversions are done and we are 100% internally unicode, why live with a non standard header that long? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

Jumbo Mail - fireworks
by puoti＠inwind.it 01 Jan '05

01 Jan '05

Ciao, questa è una Jumbo Mail, che puoti(a)inwind.it ti ha inviato per condividere con te * video.zip (119256515 byte) e questo messaggio: -------------------------------------------------------------------------------- Greetings and Happy New Year from the Sorrento Peninsular. I've just finished taking this film of the New Year firework celebrations still going on all around. I took this film from our terrace, I hope you enjoy it. The file is big, 113MBs, so I don't recommend downloading it if you don't have broadband. The download link will expire in 7 days. Happy New year to all, Ivan. -------------------------------------------------------------------------------- Per scaricare questi files fai click sul seguente link: http://webmail.inwind.it/r.php?d=inwind.it&wr=_unreg_4eh3943v&ws=3850nl9t&e… Ti ricordiamo che questo link sarà valido fino al 08.01.2005 alle 07:23. Jumbo Mail è il servizio di Libero Mail che permette di condividere file di grandi dimensioni fino a 1GB, senza problemi di superamento dei limiti delle caselle e-mail. Scopri come è semplice e veloce inviare una Jumbo Mail! Fai click su http://liberomail.libero.it/jumbomail.phtml Lo staff di Libero

1 0

Re: Remove heap.h
by Filip Navara 31 Dec '04

31 Dec '04

Jon Griffiths wrote: >+ docA.lpszDocName = WtoA( doc->lpszDocName ); >+ docA.lpszOutput = WtoA( doc->lpszOutput ); >+ docA.lpszDatatype = WtoA( doc->lpszDatatype; > Isn't there a missing parenthesis?

1 0

Re: ITSS: DllCanUnloadNow implementation
by Robert Shearman 31 Dec '04

31 Dec '04

Jacek Caban wrote: > Changelog: > Implemented DllCanUnloadNow > > BOOL WINAPI ITSS_DllCanUnloadNow(void) > { >- FIXME("\n"); >- >- return FALSE; >+ TRACE("dll_count = %lu\n", dll_count); >+ return !dll_count; > > This function should return an HRESULT, not a BOOL. This error would have been caught if it weren't for the silly ITSS_ prefix. Consequently, the return value should be either S_OK or S_FALSE depending on whether there are no or some remaining references respectively. Rob

1 0

Looking for Software which uses the MS Crypto API
by Michael Jung 30 Dec '04

30 Dec '04

Hello, In order to test rsaenh.dll, I'm looking for software, which applies the Microsoft Crypto-API. Any suggestions? It would be ideal, if the source is available. Ciao, Michael

3 3

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