December 2004 - Wine-Devel - list.winehq.org

Re: [OLE #16] Comment out an assert, as we don't yet implement IRemUnknown

by Mike Hearn

On Tue, 2004-12-28 at 13:28 -0500, Dimitrie O. Paun wrote: > It may look better in a comment, but it's easier to spot and grep for > if it's all uppercase. Also, if it's not often called, I think it's > better if we have it as a FIXME(); That's true, though it's not hard to find fixmes in this code. It's still a bit of building site. That function is called quite often, an average InstallShield spews out quite a lot of those errors. The fixme comments are there mostly for our (me and rob) benefit right now, most of them will be [re]moved as we work. thanks -mike

Dec. 28, 2004

Windows Admionistrator Rights

by Mark Knecht

Hi - Sorry for cross posting to both winde-devel and wine-users but I need to try and get an answer today on this. I'm at my dad's house and using Wine on his computer. How can I tell Wine to trick an install program into thinking the user has administrator rights under Windows XP? I've switched the windows type in the config file to winxp but the install program for Autocad 2005 tells me to log in again as an administrator. Thanks in advance, Mark

Dec. 28, 2004

Re: [OLE #16] Comment out an assert, as we don't yet implement IRemUnknown

by Dimitrie O. Paun

On Tue, Dec 28, 2004 at 06:21:30PM +0000, Mike Hearn wrote: > Hmm? I'm not sure what you're saying, sorry. The lowercase fixmes just > look better inside a comment, IMHO, and there are so many that spamming > the user with debug chatter is silly: we already know that we have to fix > it :) It may look better in a comment, but it's easier to spot and grep for if it's all uppercase. Also, if it's not often called, I think it's better if we have it as a FIXME(); -- Dimi.

Dec. 28, 2004

Re: [OLE #16] Comment out an assert, as we don't yet implement IRemUnknown

by Mike Hearn

On Tue, 28 Dec 2004 17:30:42 +0100, Andreas Mohr wrote: > $ find|xargs grep FIXME|wc -l > 11011 > $ find|xargs grep fixme|wc -l > 83 > > Might be good to keep it that way... Hmm? I'm not sure what you're saying, sorry. The lowercase fixmes just look better inside a comment, IMHO, and there are so many that spamming the user with debug chatter is silly: we already know that we have to fix it :) I guess the ERR could become a FIXME but it's not really a situation that should be fixed. It's an erroneous situation the code may sometimes get into because of problems elsewhere. So I think the ERR should stay. thanks -mike

Dec. 28, 2004

Re: [AppDB] Get rid of value fillers in appSubmit.php for a new version

by Chris Morgan

Ok, thanks Paul. Chris On Tuesday 28 December 2004 5:49 am, Paul van Schayck wrote: > Chris, > > On Mon, 27 Dec 2004 18:56:26 -0500, Chris Morgan <cmorgan(a)alum.wpi.edu> wrote: > > So is this patch good to go in? > > No disregard it. You applied the other appsubmit.php patch. The > changes in here were included. > Still we should rewrite the error handling to use those value fillers > again. > > Paul

Dec. 28, 2004

Re: [OLE #16] Comment out an assert, as we don't yet implement IRemUnknown

by Andreas Mohr

Hi, On Tue, Dec 28, 2004 at 03:37:17PM +0000, Mike Hearn wrote: > Mike Hearn <mh(a)codeweavers.com> > Comment out an assert, as we don't yet implement IRemUnknown > > --- dlls/ole32/stubmanager.c (revision 9) > +++ dlls/ole32/stubmanager.c (local) > @@ -171,8 +175,10 @@ int stub_manager_unref(struct stub_manag > EnterCriticalSection(&m->lock); > if (!list_empty(&m->ifstubs)) > { > - ERR("PANIC: Stub manager is being destroyed with outstanding interface stubs\n"); > - assert( FALSE ); > + ERR("PANIC: Stub manager %s is being destroyed with outstanding interface stubs\n", wine_dbgstr_longlong(m->oid)); > + > + /* assert( FALSE ); */ > + /* fixme: this will happen sometimes until we do proper lifecycle management via IRemUnknown */ > } > > /* fixme: the lifecycle of table-weak marshals is not $ find|xargs grep FIXME|wc -l 11011 $ find|xargs grep fixme|wc -l 83 Might be good to keep it that way... Andreas Mohr

Dec. 28, 2004

Re: UNICOWS: stub implementations

by Hans Leidekker

On Tuesday 28 December 2004 15:30, Stefan Leichter wrote: > you missed to send the implementations of the stubs! Well, yes and no. Our unicows doesn't have any implementations itself, it just links to the dlls that do have them by creating dummy references. For those dlls I sent patches earlier, so indirectly I did implement the stubs in unicows, see? -Hans

Dec. 28, 2004

Re: UNICOWS: stub implementations

by Stefan Leichter

Am Dienstag, 28. Dezember 2004 13:16 schrieb Hans Leidekker: > This one removes most remaining spec file stubs from unicows. It depends > on my previous patches to winspool, kernel, user, gdi, rasapi and shell. > > -Hans > > Changelog: > Stub implementations for AddMonitorW, AddPortW, AddPrintProcessorW, > AddPrintProvidorW, AdvancedDocumentPropertiesW, ConfigurePortW, > DeleteMonitorW, DeletePortW, DeletePrinterDriverW,DeletePrintProcessorW, > DeletePrintProvidorW, EnumDateFormatsExW, EnumPortsW, > EnumPrintProcessorDatatypesW, GetAltTabInfoW, GetICMProfileW, GetJobW, > GetLogColorSpaceW, GetPrintProcessorDirectoryW, > RasConnectionNotificationW, RasCreatePhonebookEntryW, RasDeleteSubEntryW, > RasDialW, RasEditPhonebookEntryW, RasGetConnectStatusW, > RasGetEntryDialParamsW RasGetEntryPropertiesW, RasGetErrorStringW, > RasGetProjectionInfoW, RasHangUpW, RasRenameEntryW, RasSetEntryDialParamsW, > RasSetSubEntryPropertiesW, SHGetNewLinkInfoW, SetICMProfileW, > UpdateICMRegKeyW. Hello Hans, you missed to send the implementations of the stubs! Bye Stefan

Dec. 28, 2004

another build problem on current cvs

by Joris Huizer

Hello, For the past week or so, building from cvs on a debian/stable system w/ alsa installed (using a custom kernel Linux debian 2.4.18.041216) breaks on alsa-specific code in wine; I attached the log; note that I did a `cvs update -dPA` and `make distclean` so this can't be any problem with the source I have Any ideas? Maybe you can point me to a place where I can read how to fix this properly (I never worked on alsa-specific code before...) or something like that regards, Joris

Dec. 28, 2004

wine: could not load kernel32.dll, status c000007b

by Serge S. Spiridonoff

Hi, I've compiled a Win32 GUI app under Linux using WineLib but it fails to start. Any ideas what's wrong with the program? [test]WINEDEBUG=+loaddll ./dlg1 trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\msvcrt.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\advapi32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\gdi32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\user32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\winspool.drv" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\comctl32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\iphlpapi.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\rpcrt4.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\ole32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shlwapi.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shell32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\comdlg32.dll" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "krnl386.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "system.drv" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "GDI.EXE" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "USER.EXE" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\x11drv.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\imm32.dll" : builtin wine: could not load kernel32.dll, status c000007b Thanks in advance, Serge

Dec. 28, 2004

Re: MSI: free allocated buffers

by Michael Stefaniuc

Joris Huizer wrote: > Mike McCormack wrote: > >> >> ChangeLog: >> <aric(a)codeweavers.com> >> * free allocated buffers >> >> > > The other daty I saw a lot of patches changing things like > if (buffer) > HeapFree(GetProcessHeap(),0,buffer); > To > HeapFree(GetProcessHeap(),0,buffer); > > Why are you adding new code with the if() statement in place again? Alexandre didn't accepted my patch for the msi dll. I think he is waiting for the finishing of the msi merging. I'll have to redo the patch then anyway because it already conflicts to actual cvs. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Dec. 28, 2004

Re: Unicodify System Metrics

by Mike Hearn

On Tue, 28 Dec 2004 00:26:36 -0500, jchevrier wrote: > --- sysparams.c.orig 2004-12-27 20:09:20.000000000 -0500 > +++ sysparams.c 2004-12-27 21:45:02.674627072 -0500 Hi, The patch looks OK at a first glance but in future please diff from the source root, preferably against CVS. thanks -mike

Dec. 28, 2004

Re: build problem on current cvs

by Stefan Leichter

Am Dienstag, 28. Dezember 2004 11:15 schrieb Jacek Caban: > Hi. > > Stefan Leichter wrote: > >Hello, > > > >i hope you all had nice Christmas. > > > >Now back to business :-) > > > >trying to build current cvs (~7:45 AM UTC) i get the error: > > > >make[1]: Entering directory `/usr/src/wine/wine-build/include' > >../tools/widl/widl -I../../wine/include -I. -I../../wine/include > > -I../include -h -H oaidl.h ../../wine/include/oaidl.idl > > > > > >../../wine/include/wtypes.idl:1: Oops, segment violation > >make[1]: *** [oaidl.h] Abgebrochen > >make[1]: *** Datei »oaidl.h« wird gelöscht > >make[1]: Leaving directory `/usr/src/wine/wine-build/include' > >make: *** [include] Fehler 2 > > > >My system is still SuSE 9.0. I am doing 'out of tree' builds. > > > >Bye Stefan > > Did you do make depend? > > Thanks, > Jacek this happens for me during make depend ;-) Thanks Stefan

Dec. 28, 2004

Re: [AppDB] naming convention

by Jonathan Ernst

What type of conversion do we need if we don't use strings and integer as booleans but rather use if(isset($variable)) instead ? The only implicit conversion I see is when we do: echo "There are $iSomeInteger maintainers"; but that's not a problem I think. Le mardi 28 décembre 2004 à 11:54 +0100, Paul van Schayck a écrit : > Hey, > > On Tue, 28 Dec 2004 00:42:11 +0100, Jonathan Ernst > <Jonathan(a)ernstfamily.ch> wrote: > > constants will still be uppercase without prefix. > > > > Do someone object this ? > > If we really have to. And if you both think it's a good idea I'll use > it. It's better than the original idea ($str_foo). And no one doing > if($sFoo) instead of if(isset($sFoo)) anymore. > > But what to do with conversions of types we often do. Do we have to > rename on the fly? > > Paul -- Jonathan Ernst <Jonathan(a)ErnstFamily.ch>

Dec. 28, 2004

Re: MSI: free allocated buffers

by Mike McCormack

Joris Huizer wrote: > The other daty I saw a lot of patches changing things like > if (buffer) > HeapFree(GetProcessHeap(),0,buffer); > To > HeapFree(GetProcessHeap(),0,buffer); > > Why are you adding new code with the if() statement in place again? Note all these patches were written by Aric, and I mostly didn't modify them before sending them. When they're all applied and synch'ed up with what we have internally (which is almost the case), I'll start fixing up the problems that merging them has caused... unless they're rejected first ;) Mike

Dec. 28, 2004

Re: [AppDB] naming convention

by Paul van Schayck

Hey, On Tue, 28 Dec 2004 00:42:11 +0100, Jonathan Ernst <Jonathan(a)ernstfamily.ch> wrote: > constants will still be uppercase without prefix. > > Do someone object this ? If we really have to. And if you both think it's a good idea I'll use it. It's better than the original idea ($str_foo). And no one doing if($sFoo) instead of if(isset($sFoo)) anymore. But what to do with conversions of types we often do. Do we have to rename on the fly? Paul

Dec. 28, 2004

Re: [AppDB] Get rid of value fillers in appSubmit.php for a new version

by Paul van Schayck

Chris, On Mon, 27 Dec 2004 18:56:26 -0500, Chris Morgan <cmorgan(a)alum.wpi.edu> wrote: > So is this patch good to go in? No disregard it. You applied the other appsubmit.php patch. The changes in here were included. Still we should rewrite the error handling to use those value fillers again. Paul

Dec. 28, 2004

Re: MSI: free allocated buffers

by Joris Huizer

Mike McCormack wrote: > > ChangeLog: > <aric(a)codeweavers.com> > * free allocated buffers > > The other daty I saw a lot of patches changing things like if (buffer) HeapFree(GetProcessHeap(),0,buffer); To HeapFree(GetProcessHeap(),0,buffer); Why are you adding new code with the if() statement in place again? Just curious regards, Joris

Dec. 28, 2004

Re: build problem on current cvs

by Jacek Caban

Hi. Stefan Leichter wrote: >Hello, > >i hope you all had nice Christmas. > >Now back to business :-) > >trying to build current cvs (~7:45 AM UTC) i get the error: > >make[1]: Entering directory `/usr/src/wine/wine-build/include' >../tools/widl/widl -I../../wine/include -I. -I../../wine/include -I../include >-h -H oaidl.h ../../wine/include/oaidl.idl > > >../../wine/include/wtypes.idl:1: Oops, segment violation >make[1]: *** [oaidl.h] Abgebrochen >make[1]: *** Datei »oaidl.h« wird gelöscht >make[1]: Leaving directory `/usr/src/wine/wine-build/include' >make: *** [include] Fehler 2 > >My system is still SuSE 9.0. I am doing 'out of tree' builds. > >Bye Stefan > > Did you do make depend? Thanks, Jacek

Dec. 28, 2004

Re: free allocated buffers

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > Index: dlls/msi/action.c > =================================================================== > RCS file: /home/wine/wine/dlls/msi/action.c,v > retrieving revision 1.55 > diff -u -r1.55 action.c > --- dlls/msi/action.c 27 Dec 2004 19:12:35 -0000 1.55 > +++ dlls/msi/action.c 28 Dec 2004 06:47:04 -0000 > @@ -423,6 +423,59 @@ > } > } > > +/* Called when the package is being closed */ > +extern void ACTION_free_package_structures( MSIPACKAGE* package) > +{ > + INT i; The "extern" above should be removed. -- Dmitry.

Dec. 28, 2004

build problem on current cvs

by Stefan Leichter

Hello, i hope you all had nice Christmas. Now back to business :-) trying to build current cvs (~7:45 AM UTC) i get the error: make[1]: Entering directory `/usr/src/wine/wine-build/include' ../tools/widl/widl -I../../wine/include -I. -I../../wine/include -I../include -h -H oaidl.h ../../wine/include/oaidl.idl ../../wine/include/wtypes.idl:1: Oops, segment violation make[1]: *** [oaidl.h] Abgebrochen make[1]: *** Datei »oaidl.h« wird gelöscht make[1]: Leaving directory `/usr/src/wine/wine-build/include' make: *** [include] Fehler 2 My system is still SuSE 9.0. I am doing 'out of tree' builds. Bye Stefan

Dec. 28, 2004

Re: clean-up

by Chris Morgan

Can you post a new version with the fixes that people replied with? I think the rest of the patch looks good. Chris On Thursday 23 December 2004 4:38 am, Eric Blade wrote: > The attached patch includes a lot of cleaning up, > mostly to HTML, a bit to some PHP. > > > > > > __________________________________ > Do you Yahoo!? > Send a seasonal email greeting and help others. Do good. > http://celebrity.mail.yahoo.com

Dec. 27, 2004

Re: [AppDB] Get rid of value fillers in appSubmit.php for a new version

by Chris Morgan

So is this patch good to go in? Chris On Friday 24 December 2004 2:19 pm, tony_lambregts(a)telusplanet.net wrote: > Paul van Schayck wrote: > > Those value fillers are not used. We never send users back to the page > > when errors are found (maybe we should). > > We did, and we should. > > -- > > Tony Lambregts

Dec. 27, 2004

[AppDB] naming convention

by Jonathan Ernst

As discussed with Chris and others on IRC we'd like to use a new variable naming convention in AppDB code. The proposed scheme is the following ("hungarian notation"): handles: $hSomeHandle integer: $iSomeInteger objects: $oSomeObject arrays: $aSomeArray strings: $sSomeString and so on. constants will still be uppercase without prefix. Do someone object this ? Jonathan

Dec. 27, 2004

Re: clean-up

by Kuba Ober

On czwartek 23 grudzień 2004 05:44 pm, Jonathan Ernst wrote: > Le jeudi 23 décembre 2004 à 22:39 +0100, Paul van Schayck a écrit : > > Hey Eric, > > > > On Thu, 23 Dec 2004 01:38:02 -0800 (PST), Eric Blade <ekdikeo4(a)yahoo.com> wrote: > > > The attached patch includes a lot of cleaning up, > > > mostly to HTML, a bit to some PHP. > > > > What's this supposed to do: > > if(!$tempResult) > > { > > - echo "$query \n"; > > + echo "$query < >\n"; > > echo "An error occurred: ".mysql_error().""; > > exit; > > } > > @@ -68,7 +68,7 @@ > > if(debugging()) > > { > > echo $query; > > - echo " "; > > + echo "< >< >"; > > } > > Same question: what are those < > ??? The double brackets are wrong. But the slash is just to make it valid xhtml. So it should be: echo " "; Cheers, Kuba Ober

Dec. 27, 2004

public domain code from lkcl

by Brian Vincent

I'm not sure if this is useful to anyone, but I thought I remembered licensing being an issue with this once before: http://www.advogato.org/article/814.html "I really really AM relinquishing all copyright of all Samba-related source code that i have ever written, and am placing all that code into the Public Domain." "Specifically, but not limited to, that includes the code in samba which made its way into nmbd (dating right back to 1.9.15.p6 and before, and also including the nmbd_multiworkgroup version), all modifications of smbd that made their way into versions of 1.9.15 and up, all versions known as samba_ntdom _and_ Samba TNG, the code that i cut/paste over to FreeDCE to integrate a NamedPipe Interface plugin and also the FreeDCE NTLMSSP authentication plugin i worked on." -Brian

Dec. 27, 2004

WINEPS and AFM

by Vitaly Lipatov

There is a strange code in dlls/wineps/init.c file: if(!pi->Fonts) { MESSAGE("To use WINEPS you need to install some AFM files.\n"); return FALSE; } It returns FALSE if we have not any fonts described in PPD file (buildin printer). Will I remove this section at all? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 27, 2004

Re: Approving of the WINEprobe initiative

by Stefan Munz

Am Donnerstag, 23. Dezember 2004 12:01 schrieb Izak Burger: > Stefan Munz wrote: > > as my partner David Gümbel is travelling much these days and thus is > > badly online available, I thought I add a few lines here :-) > > Boy it is good to see someone struggle as much with English as I > struggle with German :-) Badly online? You either mean "hardly" online > (ie not many times, which I think would be wenig auf Deutsch) or that > his connection speed is low. I meant both and yes sometimes it's hard if your english teacher is a website called "leo" ;-) > > > As this is a german project, actually a swabian project ;-) it is > > important for us, that the name sounds good in german. And yes, there are > > some english alternatives that sound funny in german too or that people > > who only speak german would'nt even understand. > > I think I understand. Probe obviously means the same as "proef" in my > mother tongue which means "to test" or "to be tested". I don't think > there is an English word that will do justice, and "probing" makes sense > even in English, even if it does not generate excitement. ok, that's fine. > > Schönes Weinacht, Schöne Weihnachten ;-) und einen guten Rutsch Stefan > Izak

Dec. 26, 2004

safedisc update

by Ivan Leo Puoti

Hello geeks, I've got safedisc and ntoskrnl to load, unfortunately safedisc throws an exception as soon as it starts, so I'll be learning x86 assembly (cool!) soon to try and work this out. I've got ntoskrnl with all the correct prototypes for safedisc, and I've added some definitions to our include/winternl.h so ntoskrnl can build. Unfortunately quite a few structs are needed to compile one of the functions (IofCompleteRequest), so as I don't have time to add them right now it's commented out. These patches are strictly work in progress, but as I'll be away for a few days I'm posting them here just in case someone wants to play with them, I would also like to know if I'm adding the definitions to the winternl.h stuct correctly (For example, is it OK to have all the structs for ntoskrnl in the same place?). If anyone feels the temptation to fix the header so IofCompleteRequest compiles, please go ahead and do it. Comments/suggestions/whatever highly welcome. http://spazioinwind.libero.it/nonsolomicrosoft/header.diff http://spazioinwind.libero.it/nonsolomicrosoft/ntoskrnl.diff Ivan.

Dec. 26, 2004

Re: AppDB update (refactoring and new ideas)

by Paul van Schayck

Hey, On Sat, 18 Dec 2004 23:53:34 +0100, Jonathan Ernst <Jonathan(a)ernstfamily.ch> wrote: > I think we shouldn't have more than two images (one screenshot and one > thumbnail) per screenshot (having to click on a thumbnail to get a > medium sized screenshot and having an extra link to get an even bigger > screenshot is not user friendly). However you are right 1600x1400 shots > are maybe overkill so we should define two new constants in the config: It's done. It's doing exactly this. Running examples with source and the source of the class itself can be found here: http://meosource.com/firefox/wine Class is just doing image handeling and could be used right away in for example lostwages. If there are no comments I'll submit a patch and we can start using it. Paul

Dec. 26, 2004

Re: user32: stub implementations for WINNLS* functions

by Dmitry Timoshkov

"Diego 'Flameeyes' Pettenò" <flameeyes(a)users.berlios.de> wrote: > > Does your app uses GetProcAddress to link to that APIs dynamically? > I actually don't know. How can I test this? Enabling trace? As almost always with Wine - yes, by examining a relay log. -- Dmitry.

Dec. 26, 2004

Re: user32: stub implementations for WINNLS* functions

by Diego 'Flameeyes' Pettenò

On Sunday 26 December 2004 09:16, Dmitry Timoshkov wrote: > Does your app uses GetProcAddress to link to that APIs dynamically? I actually don't know. How can I test this? Enabling trace? > A common rule is to have exactly the same header structure and dependency > tree as in the microsoft headers. Ok I sent a new patch with winnls32.h header, but still only the WINNLS* functions, as the other IMEs functions seems to have had the same fate as these, I wasn't sure if should be stub-implemented or not. Regards, -- Diego "Flameeyes" Pettenò flameeyes(a)users.berlios.de - http://flameeyes.web.ctonet.it/

Dec. 26, 2004

Re: user32: stub implementations for WINNLS* functions

by Dmitry Timoshkov

"Diego 'Flameeyes' Pettenò" <flameeyes(a)users.berlios.de> wrote: > I wanted to add these because "Yu-Gi-Oh! Power of Chaos" failed to start > complaining about WINNLSEnableIME not present in user32.dll . Does your app uses GetProcAddress to link to that APIs dynamically? > What's the right way to add these? Adding winnls32.h, and stubs all the > functions in it, inside a ime.c file? A common rule is to have exactly the same header structure and dependency tree as in the microsoft headers. -- Dmitry.

Dec. 26, 2004

Re: user32: stub implementations for WINNLS* functions

by Diego 'Flameeyes' Pettenò

On Sunday 26 December 2004 01:57, Mike Hearn wrote: > They were commented out, which implies some software does a GetProcAddress > on them. Adding these sorts of stubs can break apps: have you found a > program or DLL that actually needs them? Yu Gi Oh Power of Chaos refuses to execute without them. It also seems not to call them, at least not before crash for other reasons. I thought that the spec-stubs was the ones which breaks things, for this I tried to have implementation-stubs. Regards, -- Diego "Flameeyes" Pettenò flameeyes(a)users.berlios.de - http://flameeyes.web.ctonet.it/

Dec. 26, 2004

Determining the color depth of X?

by d13f00l

Hey. I've been trying to iron out a couple bugs running some programs in wine. Running ZSNES reports that ZSNES cannot run in 24 bit depth mode. I'm also running an old game that uses dibs, I took a profiler to wine. We repeatedly call convert_888_to_0888_asis on a surface per blit. The game determines the color depth by what depth you're running windows at. Basicaly, where/how does wine determine your bit depth? Isn't 24 actually 3 significacant bytes + a worthless one in X? XRGB. I didn't see any code determining the bit depth trying to follow what happens when you CreateCompatibleDC(0). Anyone have any ideas? This could be potential for a nice speedup. Thanks. -Dylan

Dec. 25, 2004

Re: user32: stub implementations for WINNLS* functions

by Diego 'Flameeyes' Pettenò

On Saturday 25 December 2004 17:20, Dmitry Timoshkov wrote: > Since these APIs are IME related it would be more natural to name > the file ime.c. In fact I was quite unsure how to call the file, and if they should go in an already existant one. > Platform SDK has these APIs in winnls32.h file and marks them as old > NT 3.x compatible. Same as above, I wasn't sure if they should have their own file or what :/ I wanted to add these because "Yu-Gi-Oh! Power of Chaos" failed to start complaining about WINNLSEnableIME not present in user32.dll . What's the right way to add these? Adding winnls32.h, and stubs all the functions in it, inside a ime.c file? Thanks, -- Diego "Flameeyes" Pettenò flameeyes(a)users.berlios.de - http://flameeyes.web.ctonet.it/

Dec. 25, 2004

Re: user32: stub implementations for WINNLS* functions

by Dmitry Timoshkov

"Diego 'Flameeyes' PettenР" <flameeyes(a)users.berlios.de> wrote: > diff -Npaur wine-orig/dlls/user/winnls.c wine/dlls/user/winnls.c > --- wine-orig/dlls/user/winnls.c 1970-01-01 01:00:00.000000000 +0100 > +++ wine/dlls/user/winnls.c 2004-12-24 17:21:24.566402048 +0100 ... > +UINT WINAPI WINNLSGetIMEHotkey(HWND hUnknown1) ... > +BOOL WINAPI WINNLSEnableIME(HWND hUnknown1, BOOL bUnknown2) ... > +BOOL WINAPI WINNLSGetEnableStatus(HWND hUnknown1) Since these APIs are IME related it would be more natural to name the file ime.c. > diff -Npaur wine-orig/include/winnls.h wine/include/winnls.h > --- wine-orig/include/winnls.h 2004-12-24 16:11:18.499482264 +0100 > +++ wine/include/winnls.h 2004-12-24 15:49:59.905643096 +0100 > @@ -757,6 +757,11 @@ BOOL WINAPI SetThreadLocale(LCID) > BOOL WINAPI SetUserGeoID(GEOID); > INT WINAPI WideCharToMultiByte(UINT,DWORD,LPCWSTR,INT,LPSTR,INT,LPCSTR,LPBOOL); > > +UINT WINAPI WINNLSGetIMEHotkey(HWND); > +BOOL WINAPI WINNLSEnableIME(HWND, BOOL); > +BOOL WINAPI WINNLSGetEnableStatus(HWND); Platform SDK has these APIs in winnls32.h file and marks them as old NT 3.x compatible. -- Dmitry.

Dec. 25, 2004

Re: is WIDL a sutable replacement for microsoft MIDL?

by Steven Edwards

--- Jonathan Wilson <jonwil(a)tpgi.com.au> wrote: > Could WIDL be used alongside MingW to generate IDL files on windows? > What changes, if any, would be needed to WIDL to get it working on win32 > and compiling IDL files in a way that MingW can use? > Does MingW have enough of the OLE header files for WIDL to work? Yes I think so. We are going to be using it in ReactOS. > Having an IDL compiler for MingW would be a very usefull thing for those > doing COM development IMO. I agree but the license may be a issue(LGPL). Typelib generation support would be nice as well. Thanks Steven __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com

Dec. 24, 2004

is WIDL a sutable replacement for microsoft MIDL?

by Jonathan Wilson

Could WIDL be used alongside MingW to generate IDL files on windows? What changes, if any, would be needed to WIDL to get it working on win32 and compiling IDL files in a way that MingW can use? Does MingW have enough of the OLE header files for WIDL to work? Having an IDL compiler for MingW would be a very usefull thing for those doing COM development IMO.

Dec. 24, 2004

Re: [AppDB] Get rid of value fillers in appSubmit.php for a new version

by tony_lambregts＠telusplanet.net

Paul van Schayck wrote: > Those value fillers are not used. We never send users back to the page > when errors are found (maybe we should). We did, and we should. -- Tony Lambregts

Dec. 24, 2004

Re: Wine Bug Busters @ 7pm GMT

by Brad DeMorrow

Mike Hearn wrote: > On Mon, 06 Dec 2004 13:56:30 +0200, Shachar Shemesh wrote: > >>Damn, had to miss it. Any impressions from the event? IRC logs? > > > It was pretty good, a lot of people showed up which was fantastic. I was a > bit disappointed that those people were mostly already experienced Wine > developers, I was hoping to recruit some new people :) Still it was only 3 > days after the announcement in WWN so I suspect if one was organised a > longer time in advance more newbies would appear. > > > I would have loved to have been there, I've been following the wine project for a couple of years now, but I haven't quite dug into the code as of yet. Unfortunately, I wasn't able to make it for the scheduled time, but hopefully next time. I really appreciate the effort that everyone has put into this project to make it what it is today, and I would really like to contribute some of my own time and effort when I get the chance. I'm not as well versed on the internals of windows or linux as many of the people here, however, I do believe I could still prove to be of some use. I have a pretty decent background on programming with C/C++, so that's probably my best opportunity to help. Well, Thanks again to everyone who has contributed to wine, I really do appreciate it, and I hope to talk with many of you at some point. Oh, and everyone have a Merry Christmas everyone if I don't get a chance to say it later!

Dec. 24, 2004

Re: [QUARTZ] Some fixes

by Christian Costa

Alexandre Julliard wrote: >Christian Costa <titan.costa(a)wanadoo.fr> writes: > > > >>Well, it's what I usually do when the patch is related to a single >>component and Alexandre never complains about that. >>If it makes Alexandre's life easier, I can do it. It is not my >>intention to undermine his Christmas. ;-) >> >> > >As long as it includes the full path in the "RCS file" header, patch >knows how to deal with it so it's OK for me. Still, including the full >path would probably make it easier to read. > > > Since it takes no more effort, I will do the diff from the root for all next patches. Bye, Christian

Dec. 24, 2004

Re: [QUARTZ] Some fixes

by Christian Costa

Robert Shearman wrote: > Christian Costa wrote: > >> Robert Shearman wrote: >> >>> Christian Costa wrote: >>> >>>> Index: pin.c >>>> =================================================================== >>>> RCS file: /home/wine/wine/dlls/quartz/pin.c,v >>>> retrieving revision 1.9 >>>> diff -u -r1.9 pin.c >>>> --- pin.c 16 Dec 2004 14:25:15 -0000 1.9 >>>> +++ pin.c 24 Dec 2004 13:31:52 -0000 >>>> @@ -1134,6 +1134,8 @@ >>>> REFERENCE_TIME rtCurrent; >>>> ALLOCATOR_PROPERTIES allocProps; >>>> >>>> + CoInitialize(NULL); >>>> + SetEvent(This->hEventStateChanged); >>>> >>>> hr = IMemAllocator_GetProperties(This->pAlloc, &allocProps); >>>> >>>> >>> >>> Good catch, but it would probably be better to use >>> CoInitializeEx(NULL, COINIT_MULTITHREADED). This seems to be what >>> Microsoft uses for the pull thread. >> >> >> >> I was wondering about that but since I'm not very confident with this >> apartment stuff... >> I will try and see if it's still work. > > > > The problem with using COINIT_APARTMENTHREADED (which is what you > effectively are using when you use the non-Ex version of the function) > is that it depends on using window messages when marshaling. The pull > thread does not have a message queue and does not dispatch messages, > therefore marshaled objects could hang when called. It is an unlikely > case (who would want to use marshaled objects in a performance > sensitive component), but you never know with these crazy Windows > applications. > > Rob > > > Thanks for the explanation, Rob. I've just try and it still works fine with the change. Bye, Christian

Dec. 24, 2004

Re: [QUARTZ] Some fixes

by Christian Costa

Robert Shearman wrote: > Christian Costa wrote: > >> Hi, >> >> With this patch, the indeo codec feels a little better. >> >> Changelog: >> Initialize the COM libraries for the newly created worker thread in >> the AVI splitter. >> Fixed some returned error codes. >> Show refcount in the AddRef/Release traces in filter. >> Added 24 bits source in the video renderer. >> >> Christian Costa titan.costa(a)wanadoo.fr >> >> ------------------------------------------------------------------------ >> >> Index: avidec.c >> =================================================================== >> RCS file: /home/wine/wine/dlls/quartz/avidec.c,v >> retrieving revision 1.11 >> diff -u -r1.11 avidec.c >> --- avidec.c 20 Dec 2004 17:07:17 -0000 1.11 >> +++ avidec.c 24 Dec 2004 13:31:39 -0000 >> >> > > Why make things difficult for Alexandre? It is Christmas after all. > Provide a diff relative to the root of the wine tree. > > ... Well, it's what I usually do when the patch is related to a single component and Alexandre never complains about that. If it makes Alexandre's life easier, I can do it. It is not my intention to undermine his Christmas. ;-) > > >> Index: pin.c >> =================================================================== >> RCS file: /home/wine/wine/dlls/quartz/pin.c,v >> retrieving revision 1.9 >> diff -u -r1.9 pin.c >> --- pin.c 16 Dec 2004 14:25:15 -0000 1.9 >> +++ pin.c 24 Dec 2004 13:31:52 -0000 >> @@ -1134,6 +1134,8 @@ >> REFERENCE_TIME rtCurrent; >> ALLOCATOR_PROPERTIES allocProps; >> >> + CoInitialize(NULL); >> + SetEvent(This->hEventStateChanged); >> >> hr = IMemAllocator_GetProperties(This->pAlloc, &allocProps); >> >> > > Good catch, but it would probably be better to use > CoInitializeEx(NULL, COINIT_MULTITHREADED). This seems to be what > Microsoft uses for the pull thread. I was wondering about that but since I'm not very confident with this apartment stuff... I will try and see if it's still work. Bye, Christian

Dec. 24, 2004

Re: [MSVCRT] Fix get/set pos (fixes Supreme Snowboarding demo).

by Lionel Ulmer

On Fri, Dec 24, 2004 at 11:31:23PM +0800, Dmitry Timoshkov wrote: > The situation with fpos_t is even worse. Both VC++ (Win32) and Platform SDK > (Win64 part) define it as follows (stdio.h): > > #ifndef _FPOS_T_DEFINED > #undef _FPOSOFF > > #if defined (_POSIX_) > typedef long fpos_t; > #define _FPOSOFF(fp) ((long)(fp)) > #else /* _POSIX_ */ > > #if !__STDC__ && _INTEGRAL_MAX_BITS >= 64 > typedef __int64 fpos_t; > #define _FPOSOFF(fp) ((long)(fp)) > #else > typedef struct fpos_t { > unsigned int lopart; > int hipart; > } fpos_t; > #define _FPOSOFF(fp) ((long)(fp).lopart) > #endif > #endif /* _POSIX_ */ > > #define _FPOS_T_DEFINED > #endif Oh joy... The question now is what does the 'default' MSVCRT.DLL expect as type for the 'fpos_t' type ? I suppose I will do some tests for that. As I need anyway to send a new patch (this one make the 'test' directory not compile as my patch to 'stdio.h' does not compile), what should I do for this type ? The chicken way out would be to just change the internal type to be aligned with what we think the native MSVCRT.DLL does and not change the external type but that would not be the best for Winelib applications using MSVCRT (does that exist or do they use the C library) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 24, 2004

Re: [QUARTZ] Some fixes

by Alexandre Julliard

Christian Costa <titan.costa(a)wanadoo.fr> writes: > Well, it's what I usually do when the patch is related to a single > component and Alexandre never complains about that. > If it makes Alexandre's life easier, I can do it. It is not my > intention to undermine his Christmas. ;-) As long as it includes the full path in the "RCS file" header, patch knows how to deal with it so it's OK for me. Still, including the full path would probably make it easier to read. -- Alexandre Julliard julliard(a)winehq.org

Dec. 24, 2004

Re: [QUARTZ] Some fixes

by Robert Shearman

Christian Costa wrote: > Robert Shearman wrote: > >> Christian Costa wrote: >> >>> Index: pin.c >>> =================================================================== >>> RCS file: /home/wine/wine/dlls/quartz/pin.c,v >>> retrieving revision 1.9 >>> diff -u -r1.9 pin.c >>> --- pin.c 16 Dec 2004 14:25:15 -0000 1.9 >>> +++ pin.c 24 Dec 2004 13:31:52 -0000 >>> @@ -1134,6 +1134,8 @@ >>> REFERENCE_TIME rtCurrent; >>> ALLOCATOR_PROPERTIES allocProps; >>> >>> + CoInitialize(NULL); >>> + SetEvent(This->hEventStateChanged); >>> >>> hr = IMemAllocator_GetProperties(This->pAlloc, &allocProps); >>> >>> >> >> Good catch, but it would probably be better to use >> CoInitializeEx(NULL, COINIT_MULTITHREADED). This seems to be what >> Microsoft uses for the pull thread. > > > I was wondering about that but since I'm not very confident with this > apartment stuff... > I will try and see if it's still work. The problem with using COINIT_APARTMENTHREADED (which is what you effectively are using when you use the non-Ex version of the function) is that it depends on using window messages when marshaling. The pull thread does not have a message queue and does not dispatch messages, therefore marshaled objects could hang when called. It is an unlikely case (who would want to use marshaled objects in a performance sensitive component), but you never know with these crazy Windows applications. Rob

Dec. 24, 2004

Re: [MSVCRT] Fix get/set pos (fixes Supreme Snowboarding demo).

by Dmitry Timoshkov

"Lionel Ulmer" <lionel.ulmer(a)free.fr> wrote: > Basically, there was two issues: the first is that the 'fpos_t' is 64 bits > in Windows (Mike M. checked on VC++ and I checked on MinGW and both > confirmed this). The situation with fpos_t is even worse. Both VC++ (Win32) and Platform SDK (Win64 part) define it as follows (stdio.h): #ifndef _FPOS_T_DEFINED #undef _FPOSOFF #if defined (_POSIX_) typedef long fpos_t; #define _FPOSOFF(fp) ((long)(fp)) #else /* _POSIX_ */ #if !__STDC__ && _INTEGRAL_MAX_BITS >= 64 typedef __int64 fpos_t; #define _FPOSOFF(fp) ((long)(fp)) #else typedef struct fpos_t { unsigned int lopart; int hipart; } fpos_t; #define _FPOSOFF(fp) ((long)(fp).lopart) #endif #endif /* _POSIX_ */ #define _FPOS_T_DEFINED #endif -- Dmitry.

Dec. 24, 2004

Re: [MSVCRT] Fix get/set pos (fixes Supreme Snowboarding demo).

by Mike Hearn

On Fri, 24 Dec 2004 15:42:30 +0100, Lionel Ulmer wrote: > With the help of Mike (M.) on IRC to point me to the right direction, I > finally managed to nail down the problem that was plaguing TD's snowboarding > game demo (oh well, it's better doing it in real life but well, if you are > blocked in England it's better than nothing :-) ). YAY! Great work guys, wonderful Christmas present :) Now I suppose I should fix the launcher creation problem. Then the only one left is the black sky bug but like you said, it's likely to be a driver issue. thanks -mike

Dec. 24, 2004

Re: [QUARTZ] Some fixes

by Robert Shearman

Christian Costa wrote: > Hi, > > With this patch, the indeo codec feels a little better. > > Changelog: > Initialize the COM libraries for the newly created worker thread in > the AVI splitter. > Fixed some returned error codes. > Show refcount in the AddRef/Release traces in filter. > Added 24 bits source in the video renderer. > > Christian Costa titan.costa(a)wanadoo.fr > >------------------------------------------------------------------------ > >Index: avidec.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/avidec.c,v >retrieving revision 1.11 >diff -u -r1.11 avidec.c >--- avidec.c 20 Dec 2004 17:07:17 -0000 1.11 >+++ avidec.c 24 Dec 2004 13:31:39 -0000 > > Why make things difficult for Alexandre? It is Christmas after all. Provide a diff relative to the root of the wine tree. ... >Index: pin.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/pin.c,v >retrieving revision 1.9 >diff -u -r1.9 pin.c >--- pin.c 16 Dec 2004 14:25:15 -0000 1.9 >+++ pin.c 24 Dec 2004 13:31:52 -0000 >@@ -1134,6 +1134,8 @@ > REFERENCE_TIME rtCurrent; > ALLOCATOR_PROPERTIES allocProps; > >+ CoInitialize(NULL); >+ > SetEvent(This->hEventStateChanged); > > hr = IMemAllocator_GetProperties(This->pAlloc, &allocProps); > > Good catch, but it would probably be better to use CoInitializeEx(NULL, COINIT_MULTITHREADED). This seems to be what Microsoft uses for the pull thread. Rob

Dec. 24, 2004