- wine-devel - winehq.org

make html not working
by Frank.Schruefer＠t-online.de 24 Jan '04

24 Jan '04

Hy, Looks like 'make html' in documentation is using 'db2hml -u' which is not working on my system. If I remove the '-u' from the Makefile it works ok. Don't know what the '-u' option is for though. ERROR IS: merlin@Merlin:/usr/tmp/work/bld/wine/wine/documentation> make html db2html -u wine-devel.sgml Try 'db2html --help' for more information. make: *** [wine-devel.html] Fehler 1 MY DB2HML VERSION: merlin@Merlin:/usr/tmp/work/bld/wine/wine/documentation> db2html --version db2html - docbook-toys 1.51.0 PROBLEMATIC LINE IN Makefile: $(DB2HTML) -u $<

2 1

Re: PATCH: Fix DLL constructors on OpenBSD
by Todd T. Fries 24 Jan '04

24 Jan '04

.. I was wondering if there was anything to test yet? We're stuck otherwise at: eclipse$ $pd/wine sol.exe /usr/obj/ports/wine-20040121/wine-20040121/loader/wine:/usr/obj/ports/wine-20040121/wine-20040121/dlls/ntdll.dll.so: undefined symbol 'DllMain' /usr/obj/ports/wine-20040121/wine-20040121/loader/wine: /usr/obj/ports/wine-20040121/wine-20040121/dlls/ntdll.dll.so: can't resolve reference 'DllMain' assertion "view->next->flags & VFLAG_SYSTEM" failed: file "virtual.c", line 333 Killed eclipse$ $pd/wine /usr/obj/ports/wine-20040121/wine-20040121/loader/wine:/usr/obj/ports/wine-20040121/wine-20040121/dlls/ntdll.dll.so: undefined symbol 'DllMain' /usr/obj/ports/wine-20040121/wine-20040121/loader/wine: /usr/obj/ports/wine-20040121/wine-20040121/dlls/ntdll.dll.so: can't resolve reference 'DllMain' Wine 20040121 Usage: wine [options] [--] program_name [arguments] The -- has to be used if you specify arguments (of the program) Options: --debugmsg name Turn debugging-messages on or off --dll name This option is no longer supported --help,-h Show this help message --version,-v Display the Wine version eclipse$ built from http://todd.fries.net/ports/wine-20040121.tgz .. -- Todd Fries .. todd(a)fries.net Free Daemon Consulting, LLC VOIP: 1.636.410.0632 http://FreeDaemonConsulting.com Land: 1.405.810.2918 "..in support of free software solutions." Mobile: 1.405.203.6124 Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A Key: http://todd.fries.net/pgp.txt

1 0

Sorry for the duplicate messages
by Robert Shearman 24 Jan '04

24 Jan '04

Sorry for the duplicate messages. I've just been debugging a problem with Outlook and every time it started up, it sent the message and then crashed, not registering that it had sent it. Rob

1 0

Re: warning to "wine on cygwin" experimenters
by Sylvain Petreolle 24 Jan '04

24 Jan '04

I wont believe any word that comes from an anonymous mail. Alexandre, shouldnt we close this subject ? ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "You believe it's the year 1984, when in fact, its closer to 2184"1984 / Matrix _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Lotus Notes broken in recent CVS
by Paul R Streitman 24 Jan '04

24 Jan '04

Through iterative CVS pulls, I have established that the problem I see with Lotus Notes not working occurred between 01/02/2004 and 01/03/2004. I had thought that the problem came up only in the last week, but I must have been mistaken. The 01/03 CVS snapshot gives the symptoms that I mentioned before (appended below), and I was able to send this note with the 01/02 snapshot. I did try copying my Notes directory to a linux drive (ext3) and reconfiguring my configuration file to use it, but saw the same problem (except of course for the path name in the error messages). Paul z/OS core components development Internet: prs(a)us.ibm.com [paul: ~]wine nlnotes Warning: could not find wine config [Drive x] entry for current working directory /home/paul; starting in windows directory. fixme:reg:_nt_dump_lf unknown Win XP node id 0x686c: do we need to add support for it ? fixme:reg:_nt_dump_lf unknown Win XP node id 0x686c: do we need to add support for it ? fixme:reg:_nt_dump_lf unknown Win XP node id 0x686c: do we need to add support for it ? err:module:map_image Could not map section .rdata, file probably truncated err:module:import_dll Loading module (file) LTOUIN22.dll (which is needed by L"C:\\Lotus\\notes\\nnotesws.dll") failed (error c000007b). err:module:import_dll No implementation for LTOUIN22.dll.130 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.141 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.123 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.60 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.77 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.127 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.136 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.72 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.101 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.94 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.135 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.131 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.74 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.61 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.76 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.58 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.67 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.68 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.71 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll Module (file) nnotesws.dll (which is needed by L"C:\\Lotus\\notes\\nlnotes.exe") not found err:module:import_dll No implementation for nnotesws.dll.1 imported from L"C:\\Lotus\\notes\\nlnotes.exe", setting to 0xdeadbeef err:module:LdrInitializeThunk Main exe initialization for L"C:\\Lotus\\notes\\nlnotes.exe" failed, status c0000135

2 1

segmentation fault when using kernel32.dll.so and oleaut32.dll.so
by Anil Akurathi 23 Jan '04

23 Jan '04

Hi, I need functions like 'MultiByteToWideChar', 'SysAllocStringLen', etc which are in kernel32.dll.so and oleaut32.dll.so libraries. I have some of questions regarding using them. - How can I link these libraries with my program. Using option -lkernel32.dll looks for libkernel32.dll.so file. - I tried renaming the files and also creating soft links using libkernel32.dll.so to kernel32.dll.so. - If I link like that, my program is giving a 'segmentation fault' error. - I tried using libraries produced by compiling on my uptodate RH8.0 machine and also the libraries from the RH8.0 rpm available on sourceforge.net. - I implement an XPCOM class using these libraries and when I try to create an object, it gives the 'Segmentation Fault'. - I tried using libwine.so but it doesn't contain the above functions I need. If anybody knows how to use these libraries, please mail back. Thanks in advance. Regards, Anil

2 1

Re: Systray integration patch
by Martin Garton 23 Jan '04

23 Jan '04

> I maintain that patch - does it no longer apply? I noted a single merge > conflict when I recently updated CVS but it's trivial to fix. Is this > the issue? I got: 1 out of 10 hunks FAILED -- saving rejects to file dlls/shell32/systray.c.rej 5 out of 16 hunks FAILED -- saving rejects to file dlls/x11drv/window.c.rej The systray.c problem is just in comments. The others are not (don't appear to be from my inexperienced perspective) trivial. Maybe I'm using an old version of the patch. Is there somewhere where the latest version lives? Regards, Martin.

2 1

warning to "wine on cygwin" experimenters
by Anonymous 23 Jan '04

23 Jan '04

I got cygwin to compile wine to the point where wine-install tried to run regedit on winedefault.reg. I should have been paying closer attention. The good news is that the wine regedit.exe works like a charm. The bad news is that it overwrote my actual windows registry with the bunk values in winedefault.reg. Not gonna be very easy to roll back. So... WATCH OUT! That last step's a doozy.

2 1

Re: WWN#206
by Rein Klazes 23 Jan '04

23 Jan '04

Hi, > Mike wondered why the end of 1998 seemed so productive. > Rein felt two factors might have had a hand it: in October > CVS mistakenly reported the same commit more than once, > however at time Corel was actively working on Wine and > there geniunely were a lot of commits. > > Note - this graph does not reflect the size of the Wine > source code. It's only the commits. Anyone want to produce > a graph of how much has been added? I think it would be > interesting to see the trend. You can find it here: http://home.wanadoo.nl/~wijn/wine/cvssize.png Notes: - All files in the cvs wine tree are included, not just the sources. - I excluded the (libs/)unicode directory. That is almost 5 MByte of mostly generated source files creating an ugly step in an otherwise smooth curve. - The trend quite accurately represents the growth in the first 3 years. The last 2 years the rate of growth is clearly increasing. - The number of cvs commits in October '98 was corrected to 258 commits. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

RE: shlwapi prototype fixes
by Ge van Geldorp 23 Jan '04

23 Jan '04

> From: Robert Shearman > > > MLLoadLibrary was recently documented by Microsoft. > > My changes makes it conform to the now-documented prototype > > so I don't see what's wrong with it? > > Either it is different on Windows XP (my system is Windows > 2000 SP4 with IE6 SP1), or they just got it wrong. The fact > remains that I have seen an application working perfectly > well on Wine whilst using this function as it stands. Yes, you're right. Ordinals 377 and 378 (MLLoadLibraryA/MLLoadLibraryW) in both the Win2k and WinXP shlwapi.dll pop 12 bytes from the stack on return. I'll resubmit my patch for the other prototypes. Gé van Geldorp.

1 0

RE: comctl32 resources / shlwapi prototype fixes
by Robert Shearman 23 Jan '04

23 Jan '04

> Changelog: > Sync with ReactOS 0.2 > Fix various function prototypes to conform to PSDK > > Index: dlls/shlwapi/ordinal.c > =================================================================== > RCS file: /home/wine/wine/dlls/shlwapi/ordinal.c,v > retrieving revision 1.75 > diff -u -r1.75 ordinal.c > --- dlls/shlwapi/ordinal.c 1 Oct 2003 03:10:42 -0000 1.75 > +++ dlls/shlwapi/ordinal.c 22 Jan 2004 23:41:41 -0000 > @@ -3414,7 +3414,8 @@ > * Success: A handle to the loaded module > * Failure: A NULL handle. > */ > -HMODULE WINAPI MLLoadLibraryA(LPCSTR new_mod, HMODULE inst_hwnd, > DWORD dwFlags) > +HMODULE WINAPI MLLoadLibraryA(LPCSTR new_mod, HANDLE inst_hwnd, > DWORD dwFlags, > + LPCSTR component, BOOL cross_code_page) This is wrong. Please resubmit without this change until we can discover why the prototype has 5 parameters, yet on my system the implementation only takes 3. > { > /* FIXME: Native appears to do DPA_Create and a DPA_InsertPtr for > * each call here. > @@ -3453,7 +3454,8 @@ > * > * Unicode version of MLLoadLibraryA. > */ > -HMODULE WINAPI MLLoadLibraryW(LPCWSTR new_mod, HMODULE > inst_hwnd, DWORD dwFlags) > +HMODULE WINAPI MLLoadLibraryW(LPCWSTR new_mod, HANDLE inst_hwnd, > DWORD dwFlags, > + LPCWSTR component, BOOL cross_code_page) Same again > { > WCHAR mod_path[2*MAX_PATH]; > LPWSTR ptr;

1 0

RFC on our new initiative
by Jeremy Newman 23 Jan '04

23 Jan '04

>From the desk of Jeremy White (who is at LinuxWorld ATM). Hey folks, We've just launched a major new initiative, the CodeWeavers CrossOver Compatibility Center. You can check it out at http://www.codeweavers.com/site/compatibility/ but I think it's fair to describe it as the appdb on steroids. I wanted to announce it here to give folks a sense of what we're up to, and to apologize a bit in advance for stepping on the toes of folks that have been doing good work within the appdb. However, the #1 problem we have had over the past year or so is how to handle all the many, many requests we get for applications not on our 'supported' list. We've basically ended up sending people away, which has been pretty unsatisfying. Further, we haven't had any good way of determining what our priorities should be; we follow major paying clients, but beyond that, we mostly just follow our gut hunches in establishing priorities. We hope to end that; this new center lets our customers vote for apps, and lets non customers make pledges. We can hopefully follow those pledges to get apps running (and we'd probably be open to having wine hackers committing to support apps in exchange for a piece of the pledges, but we haven't gotten there yet). We've also, we hope, set the stage for a major new Wine related initiative - we hope to encourage lots of ISVs to certify their apps against Wine. The rationale for this is pretty simple - apps won't run on Wine as well as they do on Windows until developers start testing against Wine. They've got to start somewhere - we're trying to give them that beginning. We're obviously also hoping that this will help us to continue funding the work we've been able to do on Wine so far. As much of a struggle as it's been at times, we really feel lucky that we've been able to do so much. We hope that these initiatives will give us an extra little boost so we can help push Wine over the hump. I sincerely believe that the day when we can honestly tell people "It will most likely work nicely on Wine" is not long off. I also believe in the tooth fairy and Santa Claus, so make what you will of that <grin>. At any rate, this is a brand new initiative for us; call it an 0.1.7 release. We're very open to comments and thoughts and suggestions, so I would greatly appreciate any public or private comments you have to make. Cheers, Jeremy -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

9 18

Re: Add support for MDICREATESTRUCT conversion for 16-bit windows
by Alexandre Julliard 23 Jan '04

23 Jan '04

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > I've got a bug report that after my MDI rewrite some 16-bit MDI app > stopped to work. That's not a surprise at all. The surprise is that > STRUCT32_xxx conversion helpers didn't cope correctly with 16-bit > hInstance and actually that caused a 16-bit app to misbehave in > the first place. I had to use GetExePtr() because MapHModuleSL checks > for NE_FFLAGS_WIN32 (why?) and bails out. Using GetExePtr is going to return the wrong instance once we get back to 16-bit code. The instance handles are actually not supposed to be converted at all, we just expand the 16-bit ones to 32-bit. What was the problem with your 16-bit app? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Implement binary relocatability
by Alexandre Julliard 23 Jan '04

23 Jan '04

Mike Hearn <mike(a)theoretic.com> writes: > Before Wine would not be able to find libwine nor ntdll.so, now it can. > > I hope this patch is OK, as I think this is a useful feature that far more > free software should support. The list of use cases is big. As dicussed a couple of weeks ago, this needs to be optional; you don't necessarily always want that behavior, and it conflicts with the --prefix option. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: GetCommandLine issue with Dungeon Keeper
by Frank.Schruefer＠t-online.de 23 Jan '04

23 Jan '04

( REPOST, again: I was told that my massages need long time to appear because I'm not subscribed as frank.schruefer(a)t-online.de, ok, but my postings as wine(a)man-made.de (which I'm subscribed as) never come through. Maybe that is because mozilla only allows configuration for one outgoing mailserver which is the t-online one? Anything I could do about the situation? ) > > I'll soon come up with a win98 winnt comparison for the functions in > question. > I just have some trouble setting up *real* windows, believe it or not, > asrock > with SIS is nothing (old) windows' like! > Setting up wine is much easier LOL! > Hy, Ok, I made a simple test programm reading argv, GetCommandLineA and GetModuleFileNameA. I failed with NtCurrentTeb, even after installing microsoft sdk ... it didn't get linked. Well, I actually have very little experience if it comes to the C language but the test results I already have answer most of our questions already I think. I'd say the bottom line of the test results below is that wine almost perfectly simulates win32s behaviour but has no support for win9x be- haviour (regarding GetCommandLine* and argv). Changing the 'Windows' config parameter of wine in the [Version] sec- tion didn't make any difference to the test results from wine. That's what needs to be changed. Some of you suggested to always deliver full path but as some others said I also think that might break more programs than it'll make work so I'd oppose that idea. I think the solution is something like: if(GetVersion() & 0x80000000) /* not win32s */ { behave_as_win9x_and_modify_actual_command_line(); } else { behave_as_now(); } Basically: make the 'Windows' param in [Version] affect whether the command line is altered or not. So in my eyes it should come down to this: if(keeper_started_with_full_path() || wine_behaves_as_win9x_set_in_config()) { keeper_working = TRUE; } // woohoo! That I call programming ;-) To introduce a totally new config param to set wines behaviour here is neither necessary nor desireable. I see only one question remaining: at which place in wine should the commandline be modified if_win9x is 'set'? In GetCommandLineA? Guess no. Somewhere before CreateProces I think. But as I already menitioned c is not my mother tongue so I hope somebody else here might come up with the final solution ... Appendet here you'll find the source of a little test prog, a batch and the output the prog produced on: Windows 98, Windows NT 4.0 and Wine (on SuSE Linux 9.0). As I read it simulation of win9x behaviour needs to replace slashs by backslashs (which win32s has no probles with but 9x does) and relative paths by full paths and also the return of GetModuleFileNameA should be made to all uppercase - just to be on the safe side. ===================== TEST PROGRAM ==================== #include <windows.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char** argv) { int i; char buffer[1024]; printf("+++ GetCommandLineA +++\n"); printf("%s\n", GetCommandLineA()); printf("+++ GetModuleFileNameA +++\n"); GetModuleFileNameA(0, buffer, sizeof(buffer)); printf("mfna: %s\n", buffer); printf("+++ argc & argv +++\n"); printf("argc: %i\n", argc); for(i = 0; i<argc; i++) printf("argv #%i: %s\n", i, argv[i]); getch(); } ======================================================= ===================== TEST BATCH ====================== echo %0 cmdline ======================================================= ================= WIN98: FROM EXPLORER ================ +++ GetCommandLineA +++ "C:\Eigene Dateien\WineCommandLine\CMDLINE.exe" +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe ======================================================= ================= WINE: FROM EXPLORER ================= (not applicable) ======================================================= =============== WINNT4.0: FROM EXPLORER =============== +++ GetCommandLineA +++ "C:\Eigene Dateien\WineCommandLine\CMDLINE.exe" +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe ======================================================= ============ WIN98: FROM SHELL, IN .exe DIR =========== C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ C:\EIGENE~1\WINECO~1\CMDLINE.EXE +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\EIGENE~1\WINECO~1\CMDLINE.EXE ======================================================= ============ WINE: FROM SHELL, IN .exe DIR ============ merlin@Merlin:~/.wine/fake_windows/Eigene Dateien/WineCommandLine> wine cmdline +++ GetCommandLineA +++ cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: cmdline ======================================================= ========== WINNT4.0: FROM SHELL, IN .exe DIR ========== C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: cmdline ======================================================= ========== WIN98: FROM SHELL, NOT IN .exe DIR ========= C:\Eigene Dateien>winecommandline\cmdline +++ GetCommandLineA +++ C:\EIGENE~1\WINECO~1\CMDLINE.EXE +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\EIGENE~1\WINECO~1\CMDLINE.EXE ======================================================= =========== WINE: FROM SHELL, NOT IN .exe DIR ========= merlin@Merlin:~/.wine/fake_windows/Eigene Dateien> wine winecommandline/cmdline +++ GetCommandLineA +++ winecommandline/cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: winecommandline/cmdline ======================================================= ========= WINNT4.0: FROM SHELL, NOT IN .exe DIR ======= C:\Eigene Dateien>winecommandline\cmdline +++ GetCommandLineA +++ winecommandline\cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\winecommandline\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: winecommandline\cmdline ======================================================= ============= WIN98: FROM SHELL, FULL PATH ============ C:\Eigene Dateien>"c:\eigene dateien\winecommandline\cmdline" +++ GetCommandLineA +++ C:\EIGENE~1\WINECO~1\CMDLINE.EXE +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\EIGENE~1\WINECO~1\CMDLINE.EXE C:\Eigene Dateien>"c:/eigene dateien/winecommandline/cmdline" Befehl oder Dateiname nicht gefunden C:\Eigene Dateien> ======================================================= ============== WINE: FROM SHELL, FULL PATH ============ merlin@Merlin:~/.wine/fake_windows/Eigene Dateien> wine "c:\\eigene dateien\\winecommandline\\cmdline" +++ GetCommandLineA +++ "c:\eigene dateien\winecommandline\cmdline" +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: c:\eigene dateien\winecommandline\cmdline merlin@Merlin:~/.wine/fake_windows/Eigene Dateien/WineCommandLine> wine "c:/eigene dateien/winecommandline/cmdline" +++ GetCommandLineA +++ "c:/eigene dateien/winecommandline/cmdline" +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: c:/eigene dateien/winecommandline/cmdline ======================================================= ============ WINNT4.0: FROM SHELL, FULL PATH ========== C:\Eigene Dateien>"c:\eigene dateien\winecommandline\cmdline" +++ GetCommandLineA +++ "c:\eigene dateien\winecommandline\cmdline" +++ GetModuleFileNameA +++ mfna: c:\eigene dateien\winecommandline\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: c:\eigene dateien\winecommandline\cmdline C:\Eigene Dateien>"c:/eigene dateien/winecommandline/cmdline" +++ GetCommandLineA +++ "c:/eigene dateien/winecommandline/cmdline" +++ GetModuleFileNameA +++ mfna: c:\eigene dateien\winecommandline\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: c:/eigene dateien/winecommandline/cmdline ======================================================= ============ WIN98: FROM BATCH, IN .exe DIR =========== C:\Eigene Dateien\WineCommandLine>batch C:\Eigene Dateien\WineCommandLine>echo batch batch C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ C:\EIGENE~1\WINECO~1\CMDLINE.EXE +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\EIGENE~1\WINECO~1\CMDLINE.EXE ======================================================= ============= WINE: FROM BATCH, IN .exe DIR =========== merlin@Merlin:~/.wine/fake_windows/Eigene Dateien/WineCommandLine> wine batch wine: cannot find 'batch' merlin@Merlin:~/.wine/fake_windows/Eigene Dateien/WineCommandLine> wine batch.bat wine: cannot determine executable type for L"C:\\Eigene Dateien\\WineCommandLine\\batch.bat" ======================================================= =========== WINNT4.0: FROM BATCH, IN .exe DIR ========= C:\Eigene Dateien\WineCommandLine>batch C:\Eigene Dateien\WineCommandLine>echo batch batch C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: cmdline ======================================================= ========== WIN98: FROM BATCH, NOT IN .exe DIR ========= C:\Eigene Dateien>winecommandline\batch C:\Eigene Dateien>echo winecommandline\batch winecommandline\batch C:\Eigene Dateien>cmdline Befehl oder Dateiname nicht gefunden. ======================================================= =========== WINE: FROM BATCH, NOT IN .exe DIR ========= merlin@Merlin:~/.wine/fake_windows/Eigene Dateien> wine WineCommandLine/batch wine: cannot find 'WineCommandLine/batch' merlin@Merlin:~/.wine/fake_windows/Eigene Dateien> wine winecommandline/batch.bat wine: cannot determine executable type for L"C:\\Eigene Dateien\\WineCommandLine\\batch.bat" ======================================================= ========= WINNT4.0: FROM BATCH, NOT IN .exe DIR ======= C:\Eigene Dateien>winecommandline\batch C:\Eigene Dateien>echo winecommandline\batch winecommandline\batch C:\Eigene Dateien>cmdline Der Befehl ist entweder falsch geschrieben oder konnte nicht gefunden werden. Bitte überprüfen Sie die Schreibweise und die Umgebungsvariable 'PATH'. ======================================================= ============ WIN98: FROM BATCH, BY EXPLORER =========== C:\Eigene Dateien\WineCommandLine>echo C:\EIGENE~1\WINECO~1\BATCH.BAT C:\EIGENE~1\WINECO~1\BATCH.BAT C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ C:\EIGENE~1\WINECO~1\CMDLINE.EXE +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\EIGENE~1\WINECO~1\CMDLINE.EXE ======================================================= ============= WINE: FROM BATCH, BY EXPLORER =========== (not applicable) ======================================================= =========== WINNT4.0: FROM BATCH, BY EXPLORER ========= C:\Eigene Dateien\WineCommandLine>echo "C:\Eigene Dateien\WineCommandLine\batch. bat" "C:\Eigene Dateien\WineCommandLine\batch.bat" C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: cmdline =======================================================

2 3

Re: PATCH: install more programs
by Alexandre Julliard 23 Jan '04

23 Jan '04

Marcus Meissner <meissner(a)suse.de> writes: > I think we can install those safely. > > Ciao, Marcus > > Changelog: > Install rundll32,winemenubuilder and winevdm into the system. Why do you need these? They are not really supposed to be started directly by the user. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Wine release 20040121
by Boaz Harrosh 23 Jan '04

23 Jan '04

Alexandre Julliard wrote: > - Better support for constructors in C++ Winelib apps. > > I follow the wine mailing list every work day. I even went back on these messages I did not read. I cannot find that patch. Alexandre Please? Elaborate a little about that fix. What do we do now? Just remove the wrapper and run? nothing to do in the Makefiles? Please also explain in a few words the technology behind it. (GCC that is). Free Life Boaz

3 3

Systray integration patch
by Martin Garton 22 Jan '04

22 Jan '04

Hi, I realise that the systray patches as they currently stand will not be integrated and need making into a seperate program. However, in the meantime the existing systray patch Works For Me so does anyone have an updated version that applies against Wine-20040121? Regards, Martin Garton.

2 1

debugstr buffer overflow
by Stefan Leichter 22 Jan '04

22 Jan '04

Hello, attached is a piece of a logfile that shows a buffer overflow of the debugstr. For my understanding the function should have only two parameters! is this right? What may cause this problem? Any ideas? Hints to trace the problem? Thanks Stefan For the record: logfile generated by installing mdac_type.exe (2.8) with current wine (cvs) on SuSE 9.0, "setupapi" = "native"

1 0

WineDbg didn't stop
by Fabian Cenedese 22 Jan '04

22 Jan '04

Hi I tried to debug a program. I set a breakpoint but winedbg didn't stop though it said the breakpoint was set. Here's the output: Wine-dbg>b CIncoExpCtrl::OnCreate Unable to add breakpoint, will check again when a new DLL is loaded Wine-dbg>c ... (0x42a20000) Loaded debug information from 32bit DLL 'C:\WINDOWS\SYSTEM\INCOEXP.OCX' (0x10000000) Breakpoint 2 at 0x1001a910 (CIncoExpCtrl::OnCreate [C:\IncoExp\Src\IncoExpCtl.cpp:382] in INCOEXP.OCX) (yep, right file and right line) First chance exception: e06d7363 in 32-bit code (0x404b96f3). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0000 EIP:404b96f3 ESP:408ce044 EBP:408ce0a0 EFLAGS:00000216( - 00 I -A-P1 ) EAX:408ce044 EBX:40574c78 ECX:00000000 EDX:0000000c ESI:408ce0e0 EDI:408ce064 Stack dump: 0x408ce044 (KERNEL32.DLL.VerSetConditionMask+0x36e206): e06d7363 00000001 00000000 404b9660 0x408ce054 (KERNEL32.DLL.VerSetConditionMask+0x36e216): 00000003 19930520 408ce10c 5f4bb5d8 0x408ce064 (KERNEL32.DLL.VerSetConditionMask+0x36e226): 00000000 42a50000 42a50000 780012b3 0x408ce074 (KERNEL32.DLL.VerSetConditionMask+0x36e236): ffffffff 408ce1fa 408ce0b8 78001385 0x408ce084 (KERNEL32.DLL.VerSetConditionMask+0x36e246): 42a50000 00000002 00000010 408ce1fa 0x408ce094 (KERNEL32.DLL.VerSetConditionMask+0x36e256): 00000000 7802ee08 408ce0e0 408ce0e0 0x408ce0a4 (KERNEL32.DLL.VerSetConditionMask+0x36e266): 0200: sel=1007 base=40018000 limit=00001f83 32-bit rw- Backtrace: =>0 0x404b96f3 (KERNEL32.DLL.RaiseException+0x93 in KERNEL32.DLL) (ebp=408ce0a0) 1 0x7800ac4e (MSVCRT.DLL._CxxThrowException+0x34 in MSVCRT.DLL) (ebp=408ce0e0) 2 0x5f47d5b1 (MFC42.DLL.1269+0x4d in MFC42.DLL) (ebp=408ce104) 3 0x5f48ceab (MFC42.DLL.2464+0x11c in MFC42.DLL) (ebp=408ce19c) 4 0x5f423445 (MFC42.DLL.4035+0x51 in MFC42.DLL) (ebp=408ce1c4) 5 0x5f42348d (MFC42.DLL.6095+0x43 in MFC42.DLL) (ebp=408ce1ec) 6 0x5f423520 (MFC42.DLL.5719+0x28 in MFC42.DLL) (ebp=408ce220) 7 0x5f42375d (MFC42.DLL.6198+0x14 in MFC42.DLL) (ebp=408ce288) 8 0x5f421996 (MFC42.DLL.6621+0x86 in MFC42.DLL) (ebp=408ce2e0) 9 0x5f42168b (MFC42.DLL.6623+0x3f in MFC42.DLL) (ebp=408ce31c) 10 0x5f421647 (MFC42.DLL.2135+0x59 in MFC42.DLL) (ebp=408ce370) 11 0x1001a9d5 (CIncoExpCtrl::OnCreate+0xc5(lpCreateStruct=0x5f401aff, cPath=0x1) [C:\IncoExp\Src\IncoExpCtl.cpp:401] in INCOEXP.OCX) (ebp=408ce470) ... What? We already passed the breakpoint? Why didn't it stop? Did I do something wrong? Thanks bye Fabi

2 1

Re: Print warning when drives of type cdrom do not contain a device field
by Mike Hearn 22 Jan '04

22 Jan '04

OK, so I forgot the changelog entry. Apart from that, any reason this patch bounced? On Tue, 13 Jan 2004 19:11:17 +0000, Mike Hearn wrote: > I wasted half and hour tracing through the cdrom subsystem to find out why > halflife wasn't playing any music, only to find it was a config file > problem. Maybe this message can stop other people from making the same > mistake. > > Index: files/drive.c > =================================================================== > RCS file: /home/wine/wine/files/drive.c,v > retrieving revision 1.104 > diff -u -r1.104 drive.c > --- files/drive.c 25 Nov 2003 01:51:07 -0000 1.104 > +++ files/drive.c 13 Jan 2004 19:01:13 -0000 > @@ -338,7 +338,9 @@ > close(cd_fd); > } > } > - } > + } else if (drive->type == DRIVE_CDROM) { > + MESSAGE("\n* You have a CD-ROM drive defined in your configuration, but it is missing the Device key.\n* Playing CD audio and direct access will not work.\n\n"); > + } > > /* Get the FailReadOnly flag */ > RtlInitUnicodeString( &nameW, FailReadOnlyW );

3 3

Lotus Notes broken in recent CVS
by Paul R Streitman 22 Jan '04

22 Jan '04

Hello, For the last couple days, Lotus Notes (5.0.11) has been broken under CVS Wine. Since Wine was released as a snapshot, I thought that I had better speak up because it is still broken and no one else seems to have noticed a problem with whatever recently changed.. Here is what I see: [paul: ~]wine nlnotes Warning: could not find wine config [Drive x] entry for current working directory /home/paul; starting in windows directory. fixme:reg:_nt_dump_lf unknown Win XP node id 0x686c: do we need to add support for it ? fixme:reg:_nt_dump_lf unknown Win XP node id 0x686c: do we need to add support for it ? fixme:reg:_nt_dump_lf unknown Win XP node id 0x686c: do we need to add support for it ? err:module:map_image Could not map section .rdata, file probably truncated err:module:import_dll Loading module (file) LTOUIN22.dll (which is needed by L"C:\\Lotus\\notes\\nnotesws.dll") failed (error c000007b). err:module:import_dll No implementation for LTOUIN22.dll.130 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.141 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.123 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.60 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.77 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.127 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.136 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.72 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.101 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.94 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.135 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.131 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.74 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.61 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.76 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.58 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.67 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.68 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.71 imported from L"C:\\Lotus\\notes\\nnotesws.dll", setting to 0xdeadbeef err:module:import_dll Module (file) nnotesws.dll (which is needed by L"C:\\Lotus\\notes\\nlnotes.exe") not found err:module:import_dll No implementation for nnotesws.dll.1 imported from L"C:\\Lotus\\notes\\nlnotes.exe", setting to 0xdeadbeef err:module:LdrInitializeThunk Main exe initialization for L"C:\\Lotus\\notes\\nlnotes.exe" failed, status c0000135 I do not know how to debug this, but am willing to run things if it would help (I am fairly knowledgable but not about C/C++ programming/debugging). Its a little awkward - I have to re-install an older level of Wine (I am currently running the December 12th snapshot) to send any e-mail and then install the current level to see the problem... My system is Mandrake cooker (current), with GCC 3.3.2 and the current kernel (currently 2.6.2-rc1-mm1). Notes is installed on an XP partition (FAT32), and run from there under Wine. I grab CVS every few days, and have not had any serious problems with this configuration since NPTL support was added, so I am reasonably sure that I do not have a configuration problem. Thanks, Paul z/OS core components development Internet: prs(a)us.ibm.com

3 2

SetupCreateDiskSpaceListA/W ?
by Stefan Leichter 22 Jan '04

22 Jan '04

Hello, i am looking for informations / documents about the function SetupCreateDiskSpaceList of the SETUPAPI.DLL. I found nothing useful so far to get idea how to implement it. I used also the native dll to see the API call during the runtime of the function, but i found nothing useful. So any hints about the function are welcome Bye Stefan

1 0

cvs broken?
by Tom 22 Jan '04

22 Jan '04

If I try to download a file from cvs I get this error. Error Error: Unexpected output from cvs co: cvs [checkout aborted]: Absolute module reference invalid: `/wine/dlls/msdmo/msdmo_main.c' Check, whether there exists a directory /home/wine/CVSROOT and the script has write-Access to the CVSROOT/history if it exists. It needs to place lock-files in the directory the file is in as well. Jer ? Tom

2 4

[leadership/opensource] invitation to online survey
by Gianluca Bosco 22 Jan '04

22 Jan '04

Dear all, I have just put online a survey addressing the topic "good leadership in the open-source environment". Basically, my objective is to identify the personal conceptions of good leadership that reside in the minds of the contributors, in terms of leaders' _behaviors_ and _characteristics_. What is a good open-source project leader, from the contributor's point of view? To what extent, those personal believes are shared among developers? Can the contributor's national cultural belonging and level of experience in contributing to open-source projects explain such differences in their idea of what a good leader is? I would really appreciate your participation to the survey! Contribution (completely anonymous) consists in rating a list of statements that may be used to describe the behaviors of an open-source leader. It will take around ten minutes - there aren't any "time-consuming" open ended questions;) Following, the link to the survey: http://freeonlinesurveys.com/rendersurvey.asp?id=49776 If you are interested, I will not miss to email you a link to the final report, when ready ;) (approx, a couple of months from now) Thank you in advance, and don't hesitate to contact me if you have any questions or comments :) Gianluca Bosco g.bosco(a)GETRIDOFTHISinwind.it Denmark Technical University Department of manufacturing engineering and management

1 0

Still SSTab, OleAut32.dll
by Fabian Cenedese 22 Jan '04

22 Jan '04

Hi I'm still trying to get some VB programs to run on wine (actual cvs). But I always get the error that it can't load the SSTab control from TabCtl32.ocx as described here: http://www.winehq.org/hypermail/wine-devel/2003/12/0157.html I now tried setting some dlls to native and found that it works (well, further) if I set OleAut32.dll to native, the others are still builtin. What is missing? Has this to do with the typelib or anything else? Testcase is simple: Create a new VB(6)-Project and place the tab control (from TabCtl32.ocx which has to activated first) on the empty dialog. Run the exe on wine. Any pointers? Thanks bye Fabi

1 0

Re: WM_CTLCOLOR.. will be sent to parent window. [?? Probable Spam]
by Dmitry Timoshkov 22 Jan '04

22 Jan '04

<taro-x(a)justsystem.co.jp> wrote: > @@ -2665,12 +2665,27 @@ > static LRESULT > TREEVIEW_EraseBackground(TREEVIEW_INFO *infoPtr, HDC hDC) > { > - HBRUSH hBrush = CreateSolidBrush(infoPtr->clrBk); > - RECT rect; > + HBRUSH hBrushLocal = NULL; > + HWND hwnd = infoPtr->hwnd; > + HBRUSH hBrush = (HBRUSH)SendMessageW(GetParent(hwnd), > + IsWindowEnabled(hwnd) ? WM_CTLCOLOREDIT : WM_CTLCOLORSTATIC, > + (WPARAM)hDC, (LPARAM)hwnd); > + if (!hBrush) > + { > + hBrushLocal = CreateSolidBrush(GetBkColor(hDC)); > + hBrush = hBrushLocal; > + } 1. treeview has hwndNotify for sending notification messages, WM_CTLxxx messages can be sent to it as well. 2. In the case SendMessage(WM_CTLxxx) returns 0 (i.e. an app doesn't call DefWindowProc) you have to call DefWindowProc(WM_CTLxxx) yourself and not create an arbitrary brush. 3. Do not use C++ style comments. -- Dmitry.

1 0

Re: wine cvs notes and proposed keyboard detection fix.
by Dmitry Timoshkov 22 Jan '04

22 Jan '04

"Shane Shields" <locutusenterprises(a)softhome.net> wrote: > "The patch is wrong, since it cures just a symptom not the problem itself. > There are two problems with current x11drv keyboard code: > 1. Very likely that Turkish keyboard layout there is incorrect. > 2. As stated before the keyboard code should be fixed to take into account > the real keyboard layout while building the keyc2vkey map, not the hardcoded > one." > > I have verified that (No. 1) the Turkish keyboard layout is correct so I am > now trying to work on No. 2. I'd expect that a correct keyboard layout should produce 0 (zero) number of mismatches... -- Dmitry.

1 0

Re: wine cvs notes and proposed keyboard detection fix.
by Dmitry Timoshkov 21 Jan '04

21 Jan '04

"Shane Shields" <locutusenterprises(a)softhome.net> wrote: > > X11 team tends to remove more than 2 characters per keysym. See > > /etc/X11/xkb/symbols/tr. Turkish keyboard layout in Wine has more > > than 2 for some of them. Just do 'setxkbmap tr' and run Wine with > > +key,keyboard,+x11drv and look for mismatches. > > I have done that and piped the output to a logfile. Attached is an abbreviated > version with just the icelandic and turkish detection included. It seems to > be mismatching on detecting the third keysym where the key is defined > in /etc/X11/xkb/symbols/tr this could be a clue :) 15 mismatches per layout is too much. Isn't it? > TRACE_(key)("mismatch for keysym 0x%04lX, keycode %d, > > in function X11DRV_KEYBOARD_DetectLayout where it should be > > TRACE_(key)("mismatch for keysym 0x%08lX, keycode %d, 0x%04lX doesn't mean a truncation to 4 characters in format. > or my version of X11 is returning a larger value than it should. I suspect > this because of the large amount of calls to the function > KEYBOARD_MapDeadKeysym. Maybe the X11 guys have changed a short to a long > somewhere in my version of X11 (cvs 2003-11-24) or my gcc (3.2.2) has defined > them differently. If that is the case then the line > > ckey[i] = keysym & 0xFF; This piece of code gets executed only if XKB is disabled or couldn't translate keysym to a character. -- Dmitry.

2 1

Re: revised dsound mmap mapping patch
by Alexandre Julliard 21 Jan '04

21 Jan '04

Robert Reif <reif(a)earthlink.net> writes: > Moves dsound mmap mapping info into dsound objects. This is causing a test failure for me: dsound.c:340: Test failed: SetFormat failed: 0x8878000a -- Alexandre Julliard julliard(a)winehq.com

1 0

Stack limit error in newest release (not in olders)
by Anssi Hannula 21 Jan '04

21 Jan '04

When I run mircstats.exe, I get the following error: err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. This didn't happen on older releases. What does this error message mean? The newest release also segfaulted, before I turned overcommit on. -- Anssi

1 0

control/numeric pad/alt keys
by Vik 21 Jan '04

21 Jan '04

Hi, Just noticed that control + whatever keycombination stopped working in head. Numeric Pad and Alt key combinations seems to be dead as well. Wondering if it's just me with my jp106 keyboard, or if anybody else has the same problem... Cheers Vik Here's the trace of --debugmsg +key notepad.exe when I pressed "ctrl + o". Instead of opening the file open dialog, it just outputs 'o' in the notepad window. trace:key:X11DRV_KeyEvent type 2, window 3400006, state 0x0004, keycode 0x0020 trace:key:X11DRV_KeyEvent state = 4 nbyte = 1, status 0x4 trace:key:X11DRV_KeyEvent KeyPress : keysym=6F (o), # of chars=1 / 0x0f / '^O' trace:key:EVENT_event_to_vkey e->keycode = 20 trace:key:X11DRV_KeyEvent keycode 0x20 converted to vkey 0x4f trace:key:X11DRV_KeyEvent bScan = 0x18. trace:key:queue_kbd_event wParam=004f, lParam=00180001, InputKeyState=81 trace:key:TranslateMessage (WM_KEYDOWN, 004F, 00180001) trace:key:TranslateMessage Translating key VK_O (004f), scancode 18 trace:key:X11DRV_ToUnicodeEx (004F, 0018) : faked state = 0x0000 trace:key:EVENT_event_to_vkey e->keycode = 20 trace:key:X11DRV_ToUnicodeEx type 2, window 3400006, state 0x0000, keycode 0x0020 trace:key:X11DRV_ToUnicodeEx Translating char 0x6f to unicode trace:key:X11DRV_ToUnicodeEx ToUnicode about to return 1 with char 6f trace:key:TranslateMessage 1 -> PostMessageW(0x10022,WM_CHAR,006f,00180001) trace:key:TranslateMessage (WM_CHAR, 006F, 00180001) trace:key:X11DRV_KeyEvent type 3, window 3400006, state 0x0004, keycode 0x0020 trace:key:X11DRV_KeyEvent state = 4 nbyte = 0, status 0x1 trace:key:X11DRV_KeyEvent KeyRelease : keysym=0 (No Name), # of chars=0 / 0x00 / '' trace:key:EVENT_event_to_vkey e->keycode = 20 trace:key:X11DRV_KeyEvent keycode 0x20 converted to vkey 0x4f trace:key:X11DRV_KeyEvent bScan = 0x18. trace:key:queue_kbd_event wParam=004f, lParam=c0180001, InputKeyState=1 trace:key:TranslateMessage (WM_KEYUP, 004F, C0180001) trace:key:X11DRV_KeyEvent type 3, window 3400006, state 0x0004, keycode 0x0042 trace:key:X11DRV_KeyEvent state = 4 nbyte = 0, status 0x1 trace:key:X11DRV_KeyEvent KeyRelease : keysym=0 (No Name), # of chars=0 / 0x00 / '' trace:key:EVENT_event_to_vkey e->keycode = 42 trace:key:X11DRV_KeyEvent keycode 0x42 converted to vkey 0x11 trace:key:X11DRV_KeyEvent bScan = 0x1d. trace:key:queue_kbd_event wParam=0011, lParam=c01d0001, InputKeyState=0 trace:key:TranslateMessage (WM_KEYUP, 0011, C01D0001) -- ------------ Vikram Kumar vik(a)zone81.com "Let the dogs bark, Sancho, it's a sign we're going in the right direction." -- Don Quixote

1 1

charset related compilation errors in authors.c
by Mike Hearn 21 Jan '04

21 Jan '04

Hi, I've carbon copied this to wine-devel. This looks like some charset/toolchain issue, but I'm not sure how to diagnose it. This is on Fedora Core 1 yes? What is the output of echo $LANG at the command prompt? Maybe one of our charset experts (hi dmitry! :) knows what's up. thanks -mike On Tue, 2004-01-20 at 20:17, jds wrote: > Hi Mike: > > Iam try the compile source the wine20031212, both have the problems in compiled. > > try with manual and ./tools/wineinstall, recive is the same errors: > > make[2]: Leaving directory `/home/jds/wine-20031212/dlls/setupapi' > make[2]: Entering directory `/home/jds/wine-20031212/dlls/shell32' > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_SHELL32_ > -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 > -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o authors.o authors.c > authors.c:19: error: stray '\366' in program > authors.c:20: error: `m' undeclared here (not in a function) > authors.c:20: error: initializer element is not constant > authors.c:20: error: (near initialization for `SHELL_Authors[18]') > authors.c:20: error: syntax error before string constant > authors.c:37: error: stray '\351' in program > authors.c:46: error: stray '\366' in program > authors.c:47: error: `rklund' undeclared here (not in a function) > authors.c:47: error: initializer element is not constant > authors.c:47: error: (near initialization for `SHELL_Authors[45]') > authors.c:47: error: syntax error before string constant > authors.c:53: error: stray '\370' in program > authors.c:71: error: stray '\351' in program > authors.c:72: error: `ron' undeclared here (not in a function) > authors.c:72: error: initializer element is not constant > authors.c:72: error: (near initialization for `SHELL_Authors[70]') > authors.c:72: error: syntax error before string constant > authors.c:73: error: stray '\363' in program > authors.c:73: error: `pez' undeclared here (not in a function) > authors.c:73: error: initializer element is not constant > authors.c:73: error: (near initialization for `SHELL_Authors[72]') > authors.c:73: error: syntax error before "Caravaca" > authors.c:172: error: stray '\347' in program > authors.c:172: error: `ois' undeclared here (not in a function) > authors.c:172: error: initializer element is not constant > authors.c:172: error: (near initialization for `SHELL_Authors[171]') > authors.c:172: error: syntax error before "Gouget" > authors.c:183: error: stray '\374' in program > authors.c:184: error: `nnewig' undeclared here (not in a function) > authors.c:184: error: initializer element is not constant > authors.c:184: error: (near initialization for `SHELL_Authors[182]') > authors.c:184: error: syntax error before string constant > authors.c:240: error: stray '\366' in program > authors.c:240:13: warning: multi-character character constant > authors.c:240: error: `rgy' undeclared here (not in a function) > authors.c:240: error: initializer element is not constant > authors.c:240: error: (near initialization for `SHELL_Authors[239]') > authors.c:240: error: syntax error before '\x4e6f67' > authors.c:245: error: stray '\351' in program > authors.c:246: error: `nez' undeclared here (not in a function) > authors.c:246: error: initializer element is not constant > authors.c:246: error: (near initialization for `SHELL_Authors[244]') > authors.c:246: error: syntax error before string constant > authors.c:248: error: stray '\351' in program > authors.c:249: error: `Johansen' undeclared here (not in a function) > authors.c:249: error: initializer element is not constant > authors.c:249: error: (near initialization for `SHELL_Authors[247]') > authors.c:249: error: syntax error before string constant > authors.c:288: error: stray '\345' in program > authors.c:289: error: `ven' undeclared here (not in a function) > authors.c:289: error: initializer element is not constant > authors.c:289: error: (near initialization for `SHELL_Authors[287]') > authors.c:289: error: syntax error before string constant > authors.c:315: error: stray '\366' in program > authors.c:316: error: `m' undeclared here (not in a function) > authors.c:316: error: initializer element is not constant > authors.c:316: error: (near initialization for `SHELL_Authors[314]') > authors.c:316: error: syntax error before string constant > authors.c:323: error: stray '\374' in program > authors.c:324: error: `hl' undeclared here (not in a function) > authors.c:324: error: initializer element is not constant > authors.c:324: error: (near initialization for `SHELL_Authors[322]') > authors.c:324: error: syntax error before string constant > authors.c:330: error: stray '\351' in program > authors.c:330: error: `Marcos' undeclared here (not in a function) > authors.c:330: error: initializer element is not constant > authors.c:330: error: (near initialization for `SHELL_Authors[329]') > authors.c:330: error: syntax error before "L" > authors.c:330: error: stray '\363' in program > authors.c:402: error: stray '\345' in program > authors.c:403: error: `rd' undeclared here (not in a function) > authors.c:403: error: initializer element is not constant > authors.c:403: error: (near initialization for `SHELL_Authors[401]') > authors.c:403: error: syntax error before string constant > authors.c:408: error: stray '\351' in program > authors.c:408: error: `Manuel' undeclared here (not in a function) > authors.c:408: error: initializer element is not constant > authors.c:408: error: (near initialization for `SHELL_Authors[407]') > authors.c:408: error: syntax error before "Ferrer" > authors.c:482: error: stray '\374' in program > authors.c:483: error: `ter' undeclared here (not in a function) > authors.c:483: error: initializer element is not constant > authors.c:483: error: (near initialization for `SHELL_Authors[481]') > authors.c:483: error: syntax error before string constant > authors.c:613: error: stray '\305' in program > authors.c:613: error: stray '\366' in program > authors.c:613: error: `ngstr' undeclared here (not in a function) > authors.c:613: error: initializer element is not constant > authors.c:613: error: (near initialization for `SHELL_Authors[612]') > authors.c:613: error: syntax error before "m" > make[2]: *** [authors.o] Error 1 > make[2]: Leaving directory `/home/jds/wine-20031212/dlls/shell32' > make[1]: *** [shell32] Error 2 > make[1]: Leaving directory `/home/jds/wine-20031212/dlls' > make: *** [dlls] Error 2 > > Compilation failed, aborting install. > > Helpme please. > > Regards > > > > ---------- Original Message ----------- > From: Mike Hearn <mike(a)theoretic.com> > To: jds <jds(a)soltis.cc> > Sent: Mon, 19 Jan 2004 09:05:11 +0000 > Subject: Re: install problems IE with fresh winehq > wine-20031212-1fc1winehq.i686.rpm > > > On Sun, 2004-01-18 at 17:35, jds wrote: > > > Hi Mike: > > > I try the intall IE with you script install-ie6.sh in Fedora 1, fresh > intall > > > wine-20031212-1fc1winehq.i686, kernel 2.4.22-1.2149 > > > > > > The process no finish, pause in 72% in recive this errors: > > > > This is a known problem. For now please install Wine from WineHQ > > sources. I'm working on fixing this but the problem is a subtle one. > > > > thanks -mike > ------- End of Original Message ------- >

3 4

UXTHEME regression [was Re: install problems IE with fresh winehq wine-20031212-1fc1winehq.i686.rpm]
by Mike Hearn 21 Jan '04

21 Jan '04

On Wed, 2004-01-21 at 06:57, jds wrote: > 0x40fc2453 (UXTHEME.DLL.GetThemeSysString+0x4e3 in UXTHEME.DLL): incl 0x0(%esi) > Wine-dbg>quit A large UXTHEME update was committed in the last few days. It appears this causes the IE installer to crash. I'm currently bogged down with exams, it'll go on my list of regressions to track down and nail, but may take a few days or weeks, depending on how things go here. For now I'd suggest using 20031212, CVS is highly unstable and iesetup regresses all the time at the moment. I've copied this one to wine-devel as well so Kevin can see the crash. thanks -mike

1 0

Re: Variant tests
by Sylvain Petreolle 21 Jan '04

21 Jan '04

Jon, > Sylvain, can you apply the attached patch and send me the full output of > running the 2 tests? I can't duplicate the failures you are seeing with any > oleaut32 version here, but testing with a really really old version lead to > some changes that may help. These failures were given by the current oleaut32 CVS. (not by a real Windows box!) Now with this patch applied (updating CVS), I get : - no failure for vartest - 24 failures for vartype. (logs attached) ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "You believe it's the year 1984, when in fact, its closer to 2184"1984 / Matrix _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Variant tests
by Dmitry Timoshkov 21 Jan '04

21 Jan '04

"Jon Griffiths" <jon_p_griffiths(a)yahoo.com> wrote: > Dmitry, this should fix the test failing on your Win2K box also. If > it doesn't please let me know. A failure I reported is fixed now. Thanks! -- Dmitry.

1 0

winapi_test chokes on TITLEBARINFO
by Francois Gouget 21 Jan '04

21 Jan '04

When I run ./tools/winapi/winapi_test it chokes on the TITLEBARINFO declaration in winuser.h: typedef struct tagTITLEBARINFO { DWORD cbSize; RECT rcTitleBar; DWORD rgstate[CCHILDREN_TITLEBAR+1]; } TITLEBARINFO, *PTITLEBARINFO, *LPTITLEBARINFO; include/winuser.h: DWORD[CCHILDREN_TITLEBAR+1]: can't parse type ('DWORD') ('CCHILDREN_TITLEBAR+1') Can't use string ("4") as a SCALAR ref while "strict refs" in use at tools/winapi/c_type.pm line 283. I believe this is because it does not know how to compute the value of 'CCHILDREN_TITLEBAR+1'. Though I'm not sure the second error is really related to the first one. I had a look but I'm pretty lost in the winapi code. Does anyone know how to fix this problem? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

2 4

Re: Fix dashed/solid line in Postscript output
by Alexandre Julliard 21 Jan '04

21 Jan '04

Blake Leverett <bleverett(a)att.net> writes: > Index: dlls/wineps/ps.c > =================================================================== > RCS file: /home/wine/wine/dlls/wineps/ps.c,v > retrieving revision 1.23 > diff -u -r1.23 ps.c > --- dlls/wineps/ps.c 8 Dec 2003 21:40:27 -0000 1.23 > +++ dlls/wineps/ps.c 16 Jan 2004 05:26:55 -0000 > @@ -508,6 +508,7 @@ > BOOL PSDRV_WriteSetPen(PSDRV_PDEVICE *physDev) > { > char buf[256]; > + static char *last_dash = NULL; You can't use a static variable here, this would need to be stored in the device structure. But it's probably easier to always set the dash style unconditionally. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine cvs notes and proposed keyboard detection fix.
by Dmitry Timoshkov 20 Jan '04

20 Jan '04

"Shane Shields" <locutusenterprises(a)softhome.net> wrote: > > There are two problems with current x11drv keyboard code: > > 1. Very likely that Turkish keyboard layout there is incorrect. > > AFAICT The Turkish keyboard layout is correct. X11 team tends to remove more than 2 characters per keysym. See /etc/X11/xkb/symbols/tr. Turkish keyboard layout in Wine has more than 2 for some of them. Just do 'setxkbmap tr' and run Wine with +key,keyboard,+x11drv and look for mismatches. > The original code doesnt get as > far as looking at the turkish definition. From what I could determine it > stopped searching when it got a wrong keysymb and if that combination > satisfied the selection that keyboard was chosen. That shouldn't happen. Keyboard detection code always does a full round of comparisons with every keyboard table in x11drv. > It didnt matter if it was > the right keyboard or not. This was not completely verified through testing > as I only have one keyboard :) > > 2. As stated before the keyboard code should be fixed to take into account > > the real keyboard layout while building the keyc2vkey map, not the > > hardcoded one. > > That would be a more elegant and portable fix. How do the other programs do it > (read window managers)? Other programs have no constrains implied by implementing Win32 APIs on the top of X11. -- Dmitry.

3 3

shell32 patch 10
by Martin Fuchs 20 Jan '04

20 Jan '04

Changelog: - implemented SHGetRealIDL() Index: pidl.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/pidl.c,v retrieving revision 1.96 diff -u -p -d -r1.96 pidl.c --- pidl.c 18 Jan 2004 22:08:46 -0000 1.96 +++ pidl.c 20 Jan 2004 21:32:24 -0000 @@ -688,6 +688,7 @@ LPITEMIDLIST WINAPI ILCombine(LPCITEMIDL /* TRACE(pidl,"--new pidl=%p\n",pidlNew);*/ return pidlNew; } + /************************************************************************* * SHGetRealIDL [SHELL32.98] * @@ -695,10 +696,37 @@ LPITEMIDLIST WINAPI ILCombine(LPCITEMIDL */ HRESULT WINAPI SHGetRealIDL(LPSHELLFOLDER lpsf, LPCITEMIDLIST pidlSimple, LPITEMIDLIST *pidlReal) { - FIXME("sf=%p pidlSimple=%p pidlReal=%p\n", lpsf, pidlSimple, pidlReal); + UINT cfShellIDList = RegisterClipboardFormatA(CFSTR_SHELLIDLIST); - pdump (pidlSimple); - return 0; + STGMEDIUM medium = {0, {0}, 0}; + FORMATETC fmt = {cfShellIDList, 0, DVASPECT_CONTENT, -1, TYMED_HGLOBAL}; + + IDataObject* pDataObj; + HRESULT hr = IShellFolder_GetUIObjectOf(lpsf, 0, 1, &pidlSimple, &IID_IDataObject, 0, (LPVOID*)&pDataObj); + + if (SUCCEEDED(hr)) { + hr = IDataObject_GetData(pDataObj, &fmt, &medium); + + IDataObject_Release(pDataObj); + + if (SUCCEEDED(hr)) { + /*assert(pida->cidl==1);*/ + LPIDA pida = (LPIDA)GlobalLock(medium.hGlobal); + + LPCITEMIDLIST pidl_folder = (LPCITEMIDLIST) ((LPBYTE)pida+pida->aoffset[0]); + LPCITEMIDLIST pidl_child = (LPCITEMIDLIST) ((LPBYTE)pida+pida->aoffset[1]); + + *pidlReal = ILCombine(pidl_folder, pidl_child); + + if (!*pidlReal) + hr = E_OUTOFMEMORY; + + GlobalUnlock(medium.hGlobal); + GlobalFree(medium.hGlobal); + } + } + + return hr; } /*************************************************************************

1 0

Re: DPA_Create/Search may be missing
by Alexandre Julliard 20 Jan '04

20 Jan '04

Francois Gouget <fgouget(a)free.fr> writes: > On NT4 (or is that on Internet Explorer <=5?), comctl32 is missing entry > points for DPA_Create and DPA_Search. So we need to link them > dynamically if we want the rest of the tests to run. What version of comctl32 is that? -- Alexandre Julliard julliard(a)winehq.com

7 18

Re: Oleaut32 tests fail
by Jon Griffiths 20 Jan '04

20 Jan '04

Hi, >Running the oleaut32 tests shows that vartype and vartest are >failing. >Has someone an idea about these ? Your (presumably early) version of oleaut32.dll doesn't support the VT_DECIMAL type. I'll update the tests shortly. 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!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 2

Unicode and CP_SYMBOL question.
by Rein Klazes 20 Jan '04

20 Jan '04

Hi, Trying to fix a problem with Win2K's charmap.exe, I have a question for the unicode experts. If I convert character code's 32 to 255 using codepage SYMBOL on a Win2K system, like in this snippet: char c;WCHAR w; for( c = 32; c; c++) MultiByteToWideChar(CP_SYMBOL,0,&c,1,&w,1); I get that w == c + 0xf000 ( codes 0-31 are unchanged, any flag setting makes the function fail). Wine's implementation of MultiByteToWideChar() does something quite complicated based on standard unicode tables and returns Unicode characters in all kind of ranges. The loop above is basically what Win2K's charmap.exe does. Of course it does not properly display symbol fonts like "Symbol". Is there any reason why in this case MultiByteToWideChar should not do w = c + 0xf000 ? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 5

Re: Need help debugging ... Ddraw issue
by Jason Edmeades 19 Jan '04

19 Jan '04

Andreas Rosenberg: >If somebody could provide me the problematic exe of DK and the address >where the crash occurs I will put it through IDA pro. This might help lifting the >mystery. If IDA pro detects which compiler suite has been used to link the EXE, >it should be "easy" to detect where the string came from http://ftp.sunet.se/pub/pc/games/pcgameworld/demos/dkdemo.zip Unzip it, run KDDATA -d, and keeper95 is the executable From my notes (I dont have Linux to hand just now): Trap occurs ar 0x43d4e2 At this point in time the path/exe is in 0x552150 On windows: This was copied from 0x12fe20 (Was already filled in at a breakpoint at 0x43d4ba) which in turn came from 0x141ee0 when the pgm is very first loaded (windbg or msdev prior to executing any code). Jason

3 2

Re: Typo fix in type names
by Peter Hunnisett 19 Jan '04

19 Jan '04

They are correct as is and yes MS makes spelling mistakes. Francois Gouget wrote: >In dlls/dplayx/lobbysp.h I found types and a field with a typo: > SPDATA_BUILDPARENTALHEIRARCHY > LPSPDATA_BUILDPARENTALHEIRARCHY > LPSP_BUILDPARENTALHEIRARCHY > BuildParentalHeirarchy > >I checked in the latest Microsoft SDK and in the DirectX 9.0a SDK and >couldn't find any type with a spelling of 'HEIRARCHY'. I also searched >on Google and could not find them here either. However I did not find >these types with the correct spelling either. > >That may be because these are internal types (they are defined in an >internal header after all), or because they are badly documented. > > This is the case. They're from a not really often distributed SDK. Ciao, Peter

3 2

Re: Fix dplayx initialisation
by Alexandre Julliard 19 Jan '04

19 Jan '04

Sylvain Petreolle <spetreolle(a)yahoo.fr> writes: > Trying to load dplayx returns error 487 (ERROR_INVALID_ADDRESS) for > now. > > The following change lets wine determine a memory space by itself. This won't work, the code needs the address to be the same in all processes. This has to be fixed first. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: readme 2
by Alexandre Julliard 19 Jan '04

19 Jan '04

"Ivan Leo Murray-Smith" <puoti(a)inwind.it> writes: > OK, it uses winehq.org this time, and hopefully doesn't mess up the readme.fr There's no reason to change these URLs at all, the existing ones work just fine. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Hi (virus alert)
by Rolf Kalbermatter 19 Jan '04

19 Jan '04

Joshua Walker <halkun2002(a)yahoo.com> wrote: >3) If Microsoft just removed the ability to run >executables from Outlook, and made it so the user >would have to "activate" it via a executable >permission (Chmod 755 wsmktvxhew.exe) 99% of these >things won't even propgate. They actually did!! I seem not to be able to even extraxt an exe or other executable file attachment from any mail in Outlook 2000 at all. Even if I know for sure it is safe I can't get at it and had to ask the sender to resend it in ZIP format in the past. Didn't try to hard to find a config option 15 levels deep in some configuration settings though, but just decided they had overdone themselves ;-) Rolf Kalbermatter

1 0

Re: wine cvs notes and proposed keyboard detection fix.
by Dmitry Timoshkov 19 Jan '04

19 Jan '04

"Sylvain Petreolle" <spetreolle(a)yahoo.fr> wrote: > Forwarded fom wine-users. > The keyboard detection when starting wine does not detect my turkish keyboard > and choses a scandinavion keyboard instead. I had a look at the keyboard.c > and there is a turkish keyboard defined. I found in the > X11DRV_KEYBOARD_DetectLayout function that the keysym detection loop exited > at the first wrong match which resulted in an incorrect match for the > keyboard. Attached is a patch that appears (for me) to solve this problem. > This problem has been evident since before cvs 2003-12-13. Wine still states > that it is unable to find the correct keyboard but it at least loads and uses > the correct definition although some keys don't work correctly. The patch is wrong, since it cures just a symptom not the problem itself. There are two problems with current x11drv keyboard code: 1. Very likely that Turkish keyboard layout there is incorrect. 2. As stated before the keyboard code should be fixed to take into account the real keyboard layout while building the keyc2vkey map, not the hardcoded one. Regarging Office 97 and Quicken problems: it's better to start with simple +relay trace and search for MessageBox and the first occurence of the wrongly formatted date respectively. Or just find a patch which caused a regression for Office97. -- Dmitry.

2 1

/dlls/gdi/freetype.c breakage
by Gerald Pfeifer 19 Jan '04

19 Jan '04

The following patch to dlls/gdi/freetype.c revision 1.52 date: 2004/01/18 23:35:13; author: julliard; state: Exp; lines: +3 -4 Use the exported FONTENUMPROCW as parameter in the EnumDeviceFonts driver function instead of defining a private function type. breaks compilation freetype.c:2521: error: syntax error before "DEVICEFONTENUMPROC" freetype.c: In function `WineEngEnumFonts': freetype.c:2522: error: number of arguments doesn't match prototype gdi_private.h:220: error: prototype declaration on a system with FreeType 2.1.4 and XFree86 4.3.0. The problem seems that DEVICEFONTENUMPROC is not defined, though on some of my other test boxes with slightly different versions of FreeType, I did not see this problem. http://www.rtp.freebsd.org/~gerald/config.h contains the config.h file from autoconf. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

2 1

Re: Re: cvs documentation not in sync with website?
by chmorgan＠charter.net 19 Jan '04

19 Jan '04

Well documentation/documentation.sgml 1.12->1.13 was when the change was made in cvs, and that looks like it was 3+ months ago. Chris > > From: Jeremy Newman <jnewman(a)codeweavers.com> > Date: 2004/01/19 Mon AM 10:52:47 EST > To: Chris Morgan <cmorgan(a)alum.WPI.EDU> > CC: wine-devel(a)winehq.com > Subject: Re: cvs documentation not in sync with website? > > The docs build when Alexandre runs the wine_release script in the tools > cvs. http://cvs.winehq.org/cvsweb/tools/wine_release > > wine_release calls make_winehq also found in the tools cvs. If the docs > are out of date, it would be an error found in one of these two scripts. > > > On Sun, 2004-01-18 at 21:54, Chris Morgan wrote: > > I noticed this snippet from the online docs in the documentation section: > > http://winehq.com/site/docs/wine-devel/wine-docbook > > > > Run ./configure (or make distclean && ./configure) > > Switch to the documentation/ directory > > run ./make_winehq <----------- This line has changed > > View wine-doc/index.html in your favorite browser > > > > make_winehq has apparently been obsoleted, replaced by 'make html'. I was > > wondering why the web documentation wasn't in sync with the html docs. > > Shouldn't we be pulling the web documentation pages directly from the cvs > > pages at some scheduled interval? > > > > Thanks, > > Chris > -- > Jeremy Newman <jnewman(a)codeweavers.com> > CodeWeavers, Inc. > > >

1 0

cvs documentation not in sync with website?
by Chris Morgan 19 Jan '04

19 Jan '04

I noticed this snippet from the online docs in the documentation section: http://winehq.com/site/docs/wine-devel/wine-docbook Run ./configure (or make distclean && ./configure) Switch to the documentation/ directory run ./make_winehq <----------- This line has changed View wine-doc/index.html in your favorite browser make_winehq has apparently been obsoleted, replaced by 'make html'. I was wondering why the web documentation wasn't in sync with the html docs. Shouldn't we be pulling the web documentation pages directly from the cvs pages at some scheduled interval? Thanks, Chris

2 1

Hi
by jsheets＠codeweavers.com 19 Jan '04

19 Jan '04

Test =) jxbvitmuqfjiwe -- Test, yep.

6 5

Re: Re: [winecfg] - audio tab w/autodetection, misc
by chmorgan＠charter.net 19 Jan '04

19 Jan '04

If other people think it makes sense then yes, I think we should probably move the autodetection code to run at wine startup. The code thus far is very much non-portable so while it should work under linux I'm not sure about other os's. I've considered also trying to dynamically load the sound libraries and use their library calls to detect the sound libraries. Any improvments or suggestions are more than welcome. The autodetection works well for me though so I'd imagine it would work for most linux end-users. Chris > > From: Mike Hearn <mike(a)theoretic.com> > Date: 2004/01/19 Mon AM 09:00:48 EST > To: wine-devel(a)winehq.com > Subject: Re: [winecfg] - audio tab w/autodetection, misc > > On Sun, 18 Jan 2004 18:08:30 -0500, Chris Morgan wrote: > > err:winecfg:setConfigValue Unable to set configuration key Drivers in section > > Winmm to winejack.drv, res=1021 > > > > Is this expected as changing this option would require the registry functions > > to modify the config file, something they can't do? > > Yes, that's normal. The config file is loaded as a read-only branch. To > fully test patches change the constant in the winecfg.h file so it points > to a new branch (ie a writable one). > > > Chris Morgan <cmorgan(a)alum.wpi.edu> > > Add audio tab with first pass at autodetection of audio driver. Double > > clicking a drive entry brings up drive edit window. > > One thing I'd ask is should the autodetection code be in Wine itself, > rather than the config utility? > > The patch looks good! :) > > thanks -mike > > > >

1 0

Re: [winecfg] - audio tab w/autodetection, misc
by Mike Hearn 19 Jan '04

19 Jan '04

On Sun, 18 Jan 2004 18:08:30 -0500, Chris Morgan wrote: > err:winecfg:setConfigValue Unable to set configuration key Drivers in section > Winmm to winejack.drv, res=1021 > > Is this expected as changing this option would require the registry functions > to modify the config file, something they can't do? Yes, that's normal. The config file is loaded as a read-only branch. To fully test patches change the constant in the winecfg.h file so it points to a new branch (ie a writable one). > Chris Morgan <cmorgan(a)alum.wpi.edu> > Add audio tab with first pass at autodetection of audio driver. Double > clicking a drive entry brings up drive edit window. One thing I'd ask is should the autodetection code be in Wine itself, rather than the config utility? The patch looks good! :) thanks -mike

1 0

shell32: Implement PathGetShortPathA/W
by Rolf Kalbermatter 19 Jan '04

19 Jan '04

Changelog - include/shlobj.h Add declaration for PathGetShortPath - dlls/shell32/undocshell.h Change prototype of PathGetShortPathAW to match MSDN - dlls/shell32/shellpath.c Implement PathGetShortPathA/W and change it's prototype to match the documentation on MSDN. Tests show that at least under W2K SP4 the return value actually seems to be the buffer pointer on success or NULL otherwise, but that might be rather a side effect of the function than intended behaviour. One thing I'm not entirely sure is how to declare the prototype in shlobj.h correctly. This is one of those functions shell32 exports as Unicode/ANSI depending on the Windows version, without the normal A and W exports as well. So shlobj.h needs to declare a function name without the A or W ending. The normal WINELIB_AW macros won't work here as the decision about A/W is not made on compile time of the application but instead on compile time of the library. What I don't like about this approach is the fact that there are basically two declarations for the same exported function in two different places GetShortPathAW in dlls/shell32/undocshell.h and GetShortPath in include/shlobj.h. License: X11/LGPL Rolf Kalbermatter Index: include/shlobj.h =================================================================== RCS file: /home/wine/wine/include/shlobj.h,v retrieving revision 1.80 diff -u -r1.80 shlobj.h --- include/shlobj.h 8 Jan 2004 00:39:21 -0000 1.80 +++ include/shlobj.h 19 Jan 2004 11:21:45 -0000 @@ -841,6 +841,11 @@ DECL_WINELIB_TYPE_AW(FILEGROUPDESCRIPTOR) DECL_WINELIB_TYPE_AW(LPFILEGROUPDESCRIPTOR) +/**************************************************************************** + * Path Manipulation Routines + */ +VOID WINAPI PathGetShortPath(LPVOID pszPath); + #include <poppack.h> /***************************************************************************** Index: dlls/shell32/undocshell.h =================================================================== RCS file: /home/wine/wine/dlls/shell32/undocshell.h,v retrieving revision 1.19 diff -u -r1.19 undocshell.h --- dlls/shell32/undocshell.h 16 Jan 2004 23:04:41 -0000 1.19 +++ dlls/shell32/undocshell.h 19 Jan 2004 11:51:43 -0000 @@ -544,7 +544,7 @@ BOOL WINAPI PathRemoveFileSpecAW(LPVOID lpszPath); -LPVOID WINAPI PathGetShortPathAW(LPVOID lpszPath); +VOID WINAPI PathGetShortPathAW(LPVOID lpszPath); void WINAPI PathRemoveBlanksAW(LPVOID lpszPath); Index: dlls/shell32/shellpath.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shellpath.c,v retrieving revision 1.77 diff -u -r1.77 shellpath.c --- dlls/shell32/shellpath.c 16 Jan 2004 23:04:41 -0000 1.77 +++ dlls/shell32/shellpath.c 19 Jan 2004 11:25:29 -0000 @@ -22,7 +22,6 @@ * Many of these functions are in SHLWAPI.DLL also * */ - #include "config.h" #include "wine/port.h" @@ -236,29 +235,41 @@ /************************************************************************* * PathGetShortPathA [internal] */ -LPSTR WINAPI PathGetShortPathA(LPSTR lpszPath) +VOID WINAPI PathGetShortPathA(LPSTR pszPath) { - FIXME("%s stub\n", lpszPath); - return NULL; + CHAR path[MAX_PATH]; + + TRACE("%s\n", pszPath); + + if (GetShortPathNameA(pszPath, path, MAX_PATH)) + { + lstrcpyA(pszPath, path); + } } /************************************************************************* * PathGetShortPathW [internal] */ -LPWSTR WINAPI PathGetShortPathW(LPWSTR lpszPath) +VOID WINAPI PathGetShortPathW(LPWSTR pszPath) { - FIXME("%s stub\n", debugstr_w(lpszPath)); - return NULL; + WCHAR path[MAX_PATH]; + + TRACE("%s\n", debugstr_w(pszPath)); + + if (GetShortPathNameW(pszPath, path, MAX_PATH)) + { + lstrcpyW(pszPath, path); + } } /************************************************************************* * PathGetShortPath [SHELL32.92] */ -LPVOID WINAPI PathGetShortPathAW(LPVOID lpszPath) +VOID WINAPI PathGetShortPathAW(LPVOID pszPath) { if(SHELL_OsIsUnicode()) - return PathGetShortPathW(lpszPath); - return PathGetShortPathA(lpszPath); + PathGetShortPathW(pszPath); + PathGetShortPathA(pszPath); } /*************************************************************************

1 0

Re: shlwapi: Implement PathFileExistsAndAttributesA/W
by Dmitry Timoshkov 19 Jan '04

19 Jan '04

"Rolf Kalbermatter" <rolf.kalbermatter(a)citeng.com> wrote: > + iPrevErrMode = SetErrorMode(1); Please use a symbolic name (SEM_FAILCRITICALERRORS in this case), not just an arbitrary constant. Same for both A and W APIs. -- Dmitry.

1 0

Re: DPA_Create/Search may be missing
by Rolf Kalbermatter 19 Jan '04

19 Jan '04

Francois Gouget <fgouget(a)free.fr> wrote: > >On Sun, 18 Jan 2004, Alexandre Julliard wrote: > > Francois Gouget <fgouget(a)free.fr> writes: > > > Or is there a way to keep the static ordinal import and still have > > something that compiles with MSVC? > > Yes, you just need an MSVC version that has a correct import lib (or > copy the import lib from somewhere). >The link fails with both the Visual C++ 6 import library, and the one >from the very latest Microsoft SDK (downloaded this week). So I'm not >sure such a 'correct' import lib exists. > >But I must be missing something: if the function is exported by ordinal >only, how is the linker supposed to know that 328 is DPA_Create? The import lib does export fully named symbols for ordinal DLL exports with the exception of those few functions which according to my under- standing are not there or just a crazy thought: maybe there is a COMCTL_328 function in there?? Nope it doesn't seem to! I can however see a _DPA_Search symbol in the import lib from Platform SDK Feb 2003. No _DPA_Create and _DPA_GetPtr though. Wine does the same for the import libs created from the spec files, or doesn't it? Rolf Kalbermatter

1 0

Re: DPA_Create/Search may be missing
by Rolf Kalbermatter 19 Jan '04

19 Jan '04

Alexandre Julliard <julliard(a)winehq.org> wrote: >Francois Gouget <fgouget(a)free.fr> writes: > >> Or is there a way to keep the static ordinal import and still have >> something that compiles with MSVC? > >Yes, you just need an MSVC version that has a correct import lib (or >copy the import lib from somewhere). Does that exist???? Of course one could create one (no, not the entire comctl32.lib but just an extension import lib) but how to distribute it in a way that anyone trying to compile the test suite with MSVC has it? Rolf Kalbermatter

1 0

Re: Fixed some problems found while compiling and linking Wine under Cygwin
by BiGgUn 19 Jan '04

19 Jan '04

Hi Did you succeed in running Wine under Cygwin ? Stéphan

2 1

INSENG, IActiveSetup and ICifFile interfaces ...
by Mike McCormack 19 Jan '04

19 Jan '04

Hi All, This is a stub implemenation of the undocumented IActiveSetup from Internet Explorer's INSENG.DLL. I'm not sure that any other software except for Internet Explorer uses INSENG, however incase anybody is ever interested in it, I'm posting it here. To build this dll in wine place the following 3 files in dlls/inseng, remove the #MKDLL_SKIP line from Makefile.in, add dlls/inseng/Makefile to configure.ac and run make_dlls. Hopefully this will be of use to somebody someday... Mike #MKDLL_SKIP TOPSRCDIR = @top_srcdir@ TOPOBJDIR = ../.. SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = inseng.dll IMPORTS = user32 advapi32 kernel32 ntdll EXTRALIBS = $(LIBUNICODE) $(LIBUUID) EXTRADEFS = -DCOM_NO_WINDOWS_H C_SRCS = \ inseng.c @MAKE_DLL_RULES@ ### Dependencies: /* * INSENG Implementation * * Copyright 2002 Lionel Ulmer * Copyright 2003 Mike McCormack * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include "config.h" #include <stdarg.h> #include "windef.h" #include "winbase.h" #include "winuser.h" #include "ole2.h" #include "uuids.h" #include "wine/debug.h" #include "initguid.h" DEFINE_GUID(CLSID_DLManager, 0xBFC880F1,0x7484,0x11D0,0x83,0x09,0x00,0xAA,0x00,0xB6,0x01,0x5C); DEFINE_GUID(CLSID_ActiveSetupEng, 0x6e449686,0xc509,0x11cf,0xaa,0xfa,0x00,0xaa,0x00,0xb6,0x01,0x5c ); DEFINE_GUID(IID_IActiveSetupUnknown, 0x6e449689,0xc509,0x11cf,0xaa,0xfa,0x00,0xaa,0x00,0xb6,0x01,0x5c ); WINE_DEFAULT_DEBUG_CHANNEL(inseng); static HRESULT create_activesetup(IUnknown *pUnkOuter, LPVOID *ppObj); /* For the moment, do nothing here. */ BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpv) { switch(fdwReason) { case DLL_PROCESS_ATTACH: DisableThreadLibraryCalls(hInstDLL); break; case DLL_PROCESS_DETACH: break; } return TRUE; } /****************************************************************************** * INSENG ClassFactory */ typedef struct { IClassFactory ITF_IClassFactory; DWORD ref; HRESULT (*pfnCreateInstance)(IUnknown *pUnkOuter, LPVOID *ppObj); } IClassFactoryImpl; struct object_creation_info { const CLSID *clsid; LPCSTR szClassName; HRESULT (*pfnCreateInstance)(IUnknown *pUnkOuter, LPVOID *ppObj); }; static const struct object_creation_info object_creation[] = { { &CLSID_DLManager, "Active Download Manager", NULL }, { &CLSID_ActiveSetupEng, "Active Setup Engine", create_activesetup }, }; static HRESULT WINAPI INSENGCF_QueryInterface(LPCLASSFACTORY iface,REFIID riid,LPVOID *ppobj) { ICOM_THIS(IClassFactoryImpl,iface); if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_IClassFactory)) { IClassFactory_AddRef(iface); *ppobj = This; return S_OK; } WARN("(%p)->(%s,%p),not found\n",This,debugstr_guid(riid),ppobj); return E_NOINTERFACE; } static ULONG WINAPI INSENGCF_AddRef(LPCLASSFACTORY iface) { ICOM_THIS(IClassFactoryImpl,iface); return ++(This->ref); } static ULONG WINAPI INSENGCF_Release(LPCLASSFACTORY iface) { ICOM_THIS(IClassFactoryImpl,iface); ULONG ref = --This->ref; TRACE("%p\n",This); if (ref == 0) HeapFree(GetProcessHeap(), 0, This); return ref; } static HRESULT WINAPI INSENGCF_CreateInstance(LPCLASSFACTORY iface, LPUNKNOWN pOuter, REFIID riid, LPVOID *ppobj) { ICOM_THIS(IClassFactoryImpl,iface); HRESULT hres; LPUNKNOWN punk; TRACE("(%p)->(%p,%s,%p)\n",This,pOuter,debugstr_guid(riid),ppobj); hres = This->pfnCreateInstance(pOuter, (LPVOID *) &punk); if (FAILED(hres)) { *ppobj = NULL; return hres; } hres = IUnknown_QueryInterface(punk, riid, ppobj); if (FAILED(hres)) { *ppobj = NULL; return hres; } IUnknown_Release(punk); return hres; } static HRESULT WINAPI INSENGCF_LockServer(LPCLASSFACTORY iface,BOOL dolock) { ICOM_THIS(IClassFactoryImpl,iface); FIXME("(%p)->(%d),stub!\n",This,dolock); return S_OK; } static ICOM_VTABLE(IClassFactory) INSENGCF_Vtbl = { ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE INSENGCF_QueryInterface, INSENGCF_AddRef, INSENGCF_Release, INSENGCF_CreateInstance, INSENGCF_LockServer }; HRESULT WINAPI INSENG_DllGetClassObject(REFCLSID rclsid, REFIID iid, LPVOID *ppv) { int i; IClassFactoryImpl *factory; TRACE("%s %s %p\n",debugstr_guid(rclsid), debugstr_guid(iid), ppv); if ( !IsEqualGUID( &IID_IClassFactory, iid ) && ! IsEqualGUID( &IID_IUnknown, iid) ) return E_NOINTERFACE; for (i=0; i < sizeof(object_creation)/sizeof(object_creation[0]); i++) { if (IsEqualGUID(object_creation[i].clsid, rclsid)) break; } if (i == sizeof(object_creation)/sizeof(object_creation[0])) { FIXME("%s: no class found.\n", debugstr_guid(rclsid)); return CLASS_E_CLASSNOTAVAILABLE; } TRACE("Creating a class factory for %s\n",object_creation[i].szClassName); if( !object_creation[i].pfnCreateInstance) return CLASS_E_CLASSNOTAVAILABLE; factory = HeapAlloc(GetProcessHeap(), 0, sizeof(*factory)); if (factory == NULL) return E_OUTOFMEMORY; factory->ITF_IClassFactory.lpVtbl = &INSENGCF_Vtbl; factory->ref = 1; factory->pfnCreateInstance = object_creation[i].pfnCreateInstance; *ppv = &(factory->ITF_IClassFactory); TRACE("(%p) <- %p\n", ppv, &(factory->ITF_IClassFactory) ); return S_OK; } HRESULT WINAPI INSENG_DllCanUnloadNow(void) { FIXME("\n"); return S_FALSE; } STDAPI DllRegisterServer(void) { FIXME("\n"); return S_OK; } BOOL WINAPI CheckTrustEx( LPVOID a, LPVOID b, LPVOID c, LPVOID d, LPVOID e ) { FIXME("%p %p %p %p %p\n", a, b, c, d, e ); return TRUE; } /*************************************************************************/ typedef struct IENUMSetupModes IENUMSetupModes; typedef struct IENUMSetupModes_Vtbl IENUMSetupModes_Vtbl; struct IENUMSetupModes { const IENUMSetupModes_Vtbl* lpVtbl; }; struct IENUMSetupModes_Vtbl { ICOM_MSVTABLE_COMPAT_FIELDS /*** IUnknown methods ***/ HRESULT (STDMETHODCALLTYPE *QueryInterface)( IENUMSetupModes* This, REFIID riid, void** ppvObject); ULONG (STDMETHODCALLTYPE *AddRef)( IENUMSetupModes* This); ULONG (STDMETHODCALLTYPE *Release)( IENUMSetupModes* This); ULONG (STDMETHODCALLTYPE *Method1)( IENUMSetupModes* This, LPVOID *ptr); }; static HRESULT WINAPI IENUMSetupModes_QueryInterface(IENUMSetupModes * iface,REFIID riid,LPVOID *ppobj); static ULONG WINAPI IENUMSetupModes_AddRef(IENUMSetupModes * iface); static ULONG WINAPI IENUMSetupModes_Release(IENUMSetupModes * iface); static ULONG WINAPI IENUMSetupModes_Method1(IENUMSetupModes * iface, LPVOID *ptr); const struct IENUMSetupModes_Vtbl enummodes_vtbl = { ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE IENUMSetupModes_QueryInterface, IENUMSetupModes_AddRef, IENUMSetupModes_Release, IENUMSetupModes_Method1 }; typedef struct { IENUMSetupModes ITF_IENUMSetupModes; DWORD ref; } enummodes_impl; static HRESULT WINAPI IENUMSetupModes_QueryInterface(IENUMSetupModes * iface,REFIID riid,LPVOID *ppobj) { ICOM_THIS(enummodes_impl,iface); FIXME("%p %s %p\n", This, debugstr_guid(riid), ppobj); return E_NOINTERFACE; } static ULONG WINAPI IENUMSetupModes_AddRef(IENUMSetupModes * iface) { ICOM_THIS(enummodes_impl,iface); TRACE("%p\n",This); return ++(This->ref); } static ULONG WINAPI IENUMSetupModes_Release(IENUMSetupModes * iface) { ICOM_THIS(enummodes_impl,iface); ULONG ref = --This->ref; TRACE("%p\n",This); if (ref == 0) HeapFree(GetProcessHeap(), 0, This); return ref; } static ULONG WINAPI IENUMSetupModes_Method1(IENUMSetupModes * iface, LPVOID *ptr) { ICOM_THIS(enummodes_impl,iface); FIXME("%p %p\n",This, ptr); return E_NOTIMPL; } static HRESULT create_enummodes( LPVOID *ppObj ) { enummodes_impl *em; em = HeapAlloc( GetProcessHeap(), 0, sizeof (enummodes_impl) ); if (em == NULL) return E_OUTOFMEMORY; em->ITF_IENUMSetupModes.lpVtbl = &enummodes_vtbl; em->ref = 1; *ppObj = em; TRACE("%p\n",em); return S_OK; } /*************************************************************************/ typedef struct ICifFile ICifFile; typedef struct ICifFile_Vtbl ICifFile_Vtbl; struct ICifFile { const ICifFile_Vtbl* lpVtbl; }; struct ICifFile_Vtbl { ICOM_MSVTABLE_COMPAT_FIELDS /*** IUnknown methods ***/ HRESULT (STDMETHODCALLTYPE *QueryInterface)( ICifFile* This, REFIID riid, void** ppvObject); ULONG (STDMETHODCALLTYPE *AddRef)( ICifFile* This); ULONG (STDMETHODCALLTYPE *Release)( ICifFile* This); ULONG (STDMETHODCALLTYPE *EnumComponents)( ICifFile* This, LPVOID *ppObj, LPVOID b, LPVOID c); ULONG (STDMETHODCALLTYPE *Method2)( ICifFile* This); ULONG (STDMETHODCALLTYPE *EnumGroups)( ICifFile* This, LPVOID *ppObj, LPVOID b, LPVOID c); ULONG (STDMETHODCALLTYPE *Method4)( ICifFile* This); ULONG (STDMETHODCALLTYPE *EnumModes)( ICifFile* This, LPVOID *ppObj, LPVOID b, LPVOID c); ULONG (STDMETHODCALLTYPE *Method6)( ICifFile* This); ULONG (STDMETHODCALLTYPE *Method7)( ICifFile* This); }; static HRESULT WINAPI ICifFile_QueryInterface(ICifFile * iface,REFIID riid,LPVOID *ppobj); static ULONG WINAPI ICifFile_AddRef(ICifFile * iface); static ULONG WINAPI ICifFile_Release(ICifFile * iface); static ULONG WINAPI ICifFile_EnumComponents(ICifFile * iface, LPVOID *ppObj, LPVOID b, LPVOID c); static ULONG WINAPI ICifFile_Method2(ICifFile * iface); static ULONG WINAPI ICifFile_EnumGroups(ICifFile * iface, LPVOID *ppObj, LPVOID b, LPVOID c); static ULONG WINAPI ICifFile_Method4(ICifFile * iface); static ULONG WINAPI ICifFile_EnumModes(ICifFile * iface, LPVOID *ppObj, LPVOID b, LPVOID c); static ULONG WINAPI ICifFile_Method6(ICifFile * iface); static ULONG WINAPI ICifFile_Method7(ICifFile * iface); const struct ICifFile_Vtbl ciffile_vtbl = { ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE ICifFile_QueryInterface, ICifFile_AddRef, ICifFile_Release, ICifFile_EnumComponents, ICifFile_Method2, ICifFile_EnumGroups, ICifFile_Method4, ICifFile_EnumModes, ICifFile_Method6, ICifFile_Method7 }; typedef struct { ICifFile ITF_ICifFile; DWORD ref; } ciffile_impl; static HRESULT WINAPI ICifFile_QueryInterface(ICifFile * iface,REFIID riid,LPVOID *ppobj) { /* ICOM_THIS(ciffile_impl,iface); */ FIXME("%p %s %p\n", iface, debugstr_guid(riid), ppobj); /*jif( IsEqualGUID(riid, &IID_IActiveSetupUnknown) ) { activesetupimpl_AddRef(iface); *ppobj = This; ERR("OK\n"); return S_OK; }*/ return E_NOINTERFACE; } static ULONG WINAPI ICifFile_AddRef(ICifFile * iface) { ICOM_THIS(ciffile_impl,iface); TRACE("%p\n",This); return ++(This->ref); } static ULONG WINAPI ICifFile_Release(ICifFile * iface) { ICOM_THIS(ciffile_impl,iface); ULONG ref = --This->ref; TRACE("%p\n",This); if (ref == 0) HeapFree(GetProcessHeap(), 0, This); return ref; } static ULONG WINAPI ICifFile_EnumComponents(ICifFile * iface, LPVOID *ppObj, LPVOID b, LPVOID c) { ICOM_THIS(ciffile_impl,iface); FIXME("%p %p %p %p\n", This, ppObj, b, c); return create_enummodes( ppObj ); } static ULONG WINAPI ICifFile_Method2(ICifFile * iface) { ICOM_THIS(ciffile_impl,iface); FIXME("%p\n", This); return E_FAIL; } static ULONG WINAPI ICifFile_EnumGroups(ICifFile * iface, LPVOID *ppObj, LPVOID b, LPVOID c) { ICOM_THIS(ciffile_impl,iface); FIXME("%p %p %p %p\n", This, ppObj, b, c); return create_enummodes( ppObj ); //return E_FAIL; } static ULONG WINAPI ICifFile_Method4(ICifFile * iface) { ICOM_THIS(ciffile_impl,iface); FIXME("%p\n", This); return E_FAIL; } static ULONG WINAPI ICifFile_EnumModes(ICifFile * iface, LPVOID *ppObj, LPVOID b, LPVOID c) { ICOM_THIS(ciffile_impl,iface); FIXME("%p %p %p %p\n", This, ppObj, b, c); return create_enummodes( ppObj ); //return E_NOTIMPL; } static ULONG WINAPI ICifFile_Method6(ICifFile * iface) { ICOM_THIS(ciffile_impl,iface); FIXME("%p\n", This); return E_FAIL; } static ULONG WINAPI ICifFile_Method7(ICifFile * iface) { ICOM_THIS(ciffile_impl,iface); FIXME("%p\n", This); return E_FAIL; } static HRESULT create_ciffile( LPVOID *ppObj ) { ciffile_impl *cf; cf = HeapAlloc( GetProcessHeap(), 0, sizeof (ciffile_impl) ); if (cf == NULL) return E_OUTOFMEMORY; cf->ITF_ICifFile.lpVtbl = &ciffile_vtbl; cf->ref = 1; *ppObj = cf; TRACE("%p\n",cf); return S_OK; } /*************************************************************************/ typedef struct IActiveSetupUnknown IActiveSetupUnknown; typedef struct IActiveSetupUnknown_Vtbl IActiveSetupUnknown_Vtbl; struct IActiveSetupUnknown { const IActiveSetupUnknown_Vtbl* lpVtbl; }; struct IActiveSetupUnknown_Vtbl { ICOM_MSVTABLE_COMPAT_FIELDS /*** IUnknown methods ***/ HRESULT (STDMETHODCALLTYPE *QueryInterface)( IActiveSetupUnknown* This, REFIID riid, void** ppvObject); ULONG (STDMETHODCALLTYPE *AddRef)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Release)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method1)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *EnumModes)( IActiveSetupUnknown* This, LPVOID *ptr, DWORD b, DWORD c); ULONG (STDMETHODCALLTYPE *Method3)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method4)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method5)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method6)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method7)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method8)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method9)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method10)( IActiveSetupUnknown* This, DWORD a, DWORD b, DWORD c); ULONG (STDMETHODCALLTYPE *Method11)( IActiveSetupUnknown* This, DWORD a, LPVOID b); ULONG (STDMETHODCALLTYPE *Method12)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method13)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method14)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method15)( IActiveSetupUnknown* This, LPVOID a); ULONG (STDMETHODCALLTYPE *SetInstallDrive)( IActiveSetupUnknown* This, CHAR drive); ULONG (STDMETHODCALLTYPE *SetInstallOption)( IActiveSetupUnknown* This, DWORD a); ULONG (STDMETHODCALLTYPE *Method18)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method19)( IActiveSetupUnknown* This, IStream * stm); ULONG (STDMETHODCALLTYPE *Method20)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method21)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method22)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *SetLocalCif)( IActiveSetupUnknown* This, LPCSTR name ); ULONG (STDMETHODCALLTYPE *GetICifFile)( IActiveSetupUnknown* This, LPVOID *ptr ); ULONG (STDMETHODCALLTYPE *Method25)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method26)( IActiveSetupUnknown* This); ULONG (STDMETHODCALLTYPE *Method27)( IActiveSetupUnknown* This); }; static HRESULT WINAPI activesetupimpl_QueryInterface(IActiveSetupUnknown * iface,REFIID riid,LPVOID *ppobj); static ULONG WINAPI activesetupimpl_AddRef(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Release(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method1(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_EnumModes(IActiveSetupUnknown * iface, LPVOID *ptr, DWORD b, DWORD c); static ULONG WINAPI activesetupimpl_Method3(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method4(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method5(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method6(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method7(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method8(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method9(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method10(IActiveSetupUnknown * iface, DWORD a, DWORD b, DWORD c); static ULONG WINAPI activesetupimpl_Method11(IActiveSetupUnknown * iface, DWORD a, LPVOID b ); static ULONG WINAPI activesetupimpl_Method12(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method13(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method14(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method15(IActiveSetupUnknown * iface, LPVOID a); static ULONG WINAPI activesetupimpl_SetInstallDrive(IActiveSetupUnknown * iface, CHAR drive); static ULONG WINAPI activesetupimpl_SetInstallOption(IActiveSetupUnknown * iface, DWORD a); static ULONG WINAPI activesetupimpl_Method18(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method19(IActiveSetupUnknown * iface, IStream * stm ); static ULONG WINAPI activesetupimpl_Method20(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method21(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method22(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_SetLocalCif(IActiveSetupUnknown * iface, LPCSTR name ); static ULONG WINAPI activesetupimpl_GetICifFile(IActiveSetupUnknown * iface, LPVOID *ptr ); static ULONG WINAPI activesetupimpl_Method25(IActiveSetupUnknown * iface); static ULONG WINAPI activesetupimpl_Method26(IActiveSetupUnknown * iface); const struct IActiveSetupUnknown_Vtbl activesetupimpl_vtbl = { ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE activesetupimpl_QueryInterface, activesetupimpl_AddRef, activesetupimpl_Release, activesetupimpl_Method1, activesetupimpl_EnumModes, activesetupimpl_Method3, activesetupimpl_Method4, activesetupimpl_Method5, activesetupimpl_Method6, activesetupimpl_Method7, activesetupimpl_Method8, activesetupimpl_Method9, activesetupimpl_Method10, activesetupimpl_Method11, activesetupimpl_Method12, activesetupimpl_Method13, activesetupimpl_Method14, activesetupimpl_Method15, activesetupimpl_SetInstallDrive, activesetupimpl_SetInstallOption, activesetupimpl_Method18, activesetupimpl_Method19, activesetupimpl_Method20, activesetupimpl_Method21, activesetupimpl_Method22, activesetupimpl_SetLocalCif, activesetupimpl_GetICifFile, activesetupimpl_Method25, activesetupimpl_Method26 }; typedef struct { IActiveSetupUnknown ITF_IActiveSetupUnknown; DWORD ref; } activesetup_impl; static HRESULT WINAPI activesetupimpl_QueryInterface(IActiveSetupUnknown *iface,REFIID riid,LPVOID *ppobj) { ICOM_THIS(activesetup_impl,iface); TRACE("%p %s %p\n", iface, debugstr_guid(riid), ppobj); if( IsEqualGUID(riid, &IID_IActiveSetupUnknown) ) { activesetupimpl_AddRef(iface); *ppobj = This; ERR("OK\n"); return S_OK; } return E_NOINTERFACE; } static ULONG WINAPI activesetupimpl_AddRef(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); TRACE("%p\n",This); return ++(This->ref); } static ULONG WINAPI activesetupimpl_Release(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); ULONG ref = --This->ref; TRACE("%p\n",This); if (ref == 0) HeapFree(GetProcessHeap(), 0, This); return ref; } static ULONG WINAPI activesetupimpl_Method1(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_EnumModes(IActiveSetupUnknown * iface, LPVOID *ppObj, DWORD dwPlatform, DWORD c) { ICOM_THIS(activesetup_impl,iface); FIXME("%p %p %08lx %ld\n", This, ppObj, dwPlatform, c ); return E_FAIL; //return create_enummodes( ppObj ); } static ULONG WINAPI activesetupimpl_Method3(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method4(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method5(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method6(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method7(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method8(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method9(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method10(IActiveSetupUnknown * iface, DWORD a, DWORD b, DWORD c) { ICOM_THIS(activesetup_impl,iface); FIXME("%p %ld %ld %ld\n", This, a, b, c ); return S_OK; } /* * the third parameter looks like a pointer to a structure * * struct { * DWORD dwSize; // size of this structure * DWORD a1; * DWORD a2; * DWORD a3; * DWORD x1; * DWORD b1; * DWORD b2; * DWORD b3; * DWORD b4; * DWORD x2; * } */ static ULONG WINAPI activesetupimpl_Method11(IActiveSetupUnknown * iface, DWORD a, LPVOID b ) { ICOM_THIS(activesetup_impl,iface); FIXME("%p %lx %p\n", This, a, b ); return S_OK; } static ULONG WINAPI activesetupimpl_Method12(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method13(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method14(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method15(IActiveSetupUnknown * iface, LPVOID a) { ICOM_THIS(activesetup_impl,iface); FIXME("%p %p\n", This, a ); return S_OK; //return E_FAIL; } static ULONG WINAPI activesetupimpl_SetInstallDrive(IActiveSetupUnknown * iface, CHAR drive) { ICOM_THIS(activesetup_impl,iface); FIXME("%p drive = %c\n", This, drive ); return E_FAIL; } static ULONG WINAPI activesetupimpl_SetInstallOption(IActiveSetupUnknown * iface, DWORD a) { ICOM_THIS(activesetup_impl,iface); FIXME("%p %08lx\n", This, a ); return E_NOTIMPL; } static ULONG WINAPI activesetupimpl_Method18(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } /* set the stream to log errors to */ static ULONG WINAPI activesetupimpl_Method19(IActiveSetupUnknown * iface, IStream *stm) { ICOM_THIS(activesetup_impl,iface); FIXME("%p %p\n", This, stm ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method20(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method21(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method22(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_SetLocalCif(IActiveSetupUnknown * iface, LPCSTR name) { ICOM_THIS(activesetup_impl,iface); FIXME("%p %s\n", This, debugstr_a( name ) ); return S_OK; } static ULONG WINAPI activesetupimpl_GetICifFile(IActiveSetupUnknown * iface, LPVOID *ppObj ) { ICOM_THIS(activesetup_impl,iface); FIXME("%p %p\n", This, ppObj ); return create_ciffile( ppObj ); } static ULONG WINAPI activesetupimpl_Method25(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static ULONG WINAPI activesetupimpl_Method26(IActiveSetupUnknown * iface) { ICOM_THIS(activesetup_impl,iface); FIXME("%p\n", This ); return E_FAIL; } static HRESULT create_activesetup(IUnknown *pUnkOuter, LPVOID *ppObj) { activesetup_impl *as; as = HeapAlloc( GetProcessHeap(), 0, sizeof (activesetup_impl) ); if (as == NULL) return E_OUTOFMEMORY; as->ITF_IActiveSetupUnknown.lpVtbl = &activesetupimpl_vtbl; as->ref = 1; *ppObj = as; TRACE("%p\n",as); return S_OK; } @ stub DownloadFile @ stub PurgeDownloadDirectory @ stub CheckForVersionConflict @ stub CheckTrust @ stdcall CheckTrustEx(ptr ptr ptr ptr ptr) @ stub DllCanUnloadNow @ stdcall DllGetClassObject(ptr ptr ptr) INSENG_DllGetClassObject @ stub DllInstall @ stdcall DllRegisterServer() @ stub DllUnregisterServer @ stub GetICifFileFromFile @ stub GetICifRWFileFromFile

2 2

Re: Translation assessment tool (part 1)
by Alexandre Julliard 19 Jan '04

19 Jan '04

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Here we go again after a couple of months... > > Changelog: > Adds a new dump flag to wrc, to be used to assess translations > advancement. OK, I put that one in with a few changes, but it would be really nice if it could be print something understandable, instead of just random characters that require an external parser to interpret. It wouldn't be much harder for the parser to check for specific strings instead of '+' or '-', and it would make that mode useful by itself, for instance to check translations of a single file. Also, this thing should be driven by make instead of having a shell script parse the makefiles by hand. -- Alexandre Julliard julliard(a)winehq.com

2 1

ntdll
by MediaHost (TM) 19 Jan '04

19 Jan '04

Hi, Just a small question: The error: err:ntdll:RtlpWaitForCriticalSection section 0x40dd36a0 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0032, blocked by 0039, retrying (60 sec) seams to happen often....Is there anything I can do about it? Also: fixme:system:SystemParametersInfoA Unknown action: 8198 Is disturbing many Micro$oft Apps. Again, what to do? Implement? Regards Signer: Eddy Nigg Company: StartCom Group at http://www.startcom.org MediaHostT at http://www.mediahost.org

1 0

Re: readme update
by Marcelo Duarte 18 Jan '04

18 Jan '04

Ivan, Dimi had much work in officializing the domain winehq.org and you modified text placing .com again. ----- Original Message ----- From: "Ivan Leo Murray-Smith" <puoti(a)inwind.it> To: "wine-patches" <wine-patches(a)winehq.com> Sent: Sunday, January 18, 2004 5:44 PM Subject: readme update This patch improves the italian version fo the README file, and uniforms it layout to the one of the English README. It also updates the links to the faq, the forums and the cvs to the urls currently used at winehq in all versions of README. Alexandre, I think it would be a good idea to move these files to the root source directory, so that non-English speakers can spot them immediately. It may also be a good idea to rename them something more obvious, for example from README.it to LEGGIMI.italiano (README.italian), shall I send in a patch that does this? License: LGPL Ivan.

1 0

Re: readme update
by Andreas Mohr 18 Jan '04

18 Jan '04

Hi, On Sun, Jan 18, 2004 at 08:44:19PM +0100, Ivan Leo Murray-Smith wrote: > This patch improves the italian version fo the README file, and uniforms it > layout to the one of the English README. It also updates the links to the faq, > the forums and the cvs to the urls currently used at winehq in all versions of > README. Alexandre, I think it would be a good idea to move these files to the root > source directory, so that non-English speakers can spot them immediately. It may > also be a good idea to rename them something more obvious, for example from > README.it to LEGGIMI.italiano (README.italian), shall I send in a patch that > does this? And then we do the same for French, Russian, German, Spanish, Chinese, Polish, Bavarian ;-), Portuguese, Norvegian, Danish, Raeto Romanian, Kiswahili? Don't think so ;-) I'd say as the very first part in the README file, we write something like *********************************************************** Foreign languages (language, langue, Sprache, lingua, ...): ---> open documentation/README.<country_domain> *********************************************************** Sounds better than polluting the Wine root directory with many different localized versions. (also, if people still haven't learned to look at a file called "README" first, then they're not supposed to use Wine anyway) I still think that someone should put a system in place to make sure that all localized content gets kept current properly. (otherwise we might just end up deleting more modern versions of installation-und-konfiguration.german again and again...) That file once was a beautiful piece of documentation... and then it died... horribly even. ;-) Anyway, thanks for your docu maintenance! Andreas Mohr

1 0

Re: I'm off to Cuba!
by Brian Vincent 18 Jan '04

18 Jan '04

> I hope it's going to be sweet, but I'll be off the web > until next Sunday. Until then, hasta la vista amigos! :) Excelente! Just in time to bring us souvenirs at Wineconf. -brian

2 1

Re: Regression tests and Paul Millars WRT
by Paul Millar 18 Jan '04

18 Jan '04

On Sat, 17 Jan 2004, Mike Hearn wrote: > On Sat, 17 Jan 2004 18:40:01 +0000, Paul Millar wrote: > >> 3) Is the source to WRT available anywhere? [...] > > http://www.astro.gla.ac.uk/users/paulm/Code/wrt-0.1.tar.gz > Cool, thanks! :) No problem. Of course, any feedback/bug-fixes would be appreciated :) BTW, I should have pointed out that wrt-0.1 isn't what the live version is using. I'm still testing v0.1 before switching over. > Good to know you're tracking these things anyway, though I don't recall > seeing you forward a build failure in a year of me hacking on Wine so I > guess failed tests don't get through these days.... >From April through to October last year it wasn't working: http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php?start=400 Some server juggling broke the (even more hacky) way the old code worked. At the same time, things at work got a bit hairy, taking up nearly all my time. Eventually got it up again... ---- Paul Millar

1 0

Re: bin2res - Make adding resources work on Windows.
by Dmitry Timoshkov 18 Jan '04

18 Jan '04

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > I dont know if anyone else has tried this but when I try to add > resources to a *.rc I get a error. This patch fixes it. What kind of error do you get? I just tried to change an .rc and to rebuild resources of commdlg under cygwin and I don't see any problem with it. -- Dmitry.

2 2

Re: ntdll / kernel32 #39-2
by Dmitry Timoshkov 18 Jan '04

18 Jan '04

"Eric Pouech" <pouech-eric(a)wanadoo.fr> wrote: > +DWORD WINAPI GetFullPathNameW( LPCWSTR name, DWORD len, LPWSTR buffer, > + LPWSTR *lastpart ) > +{ > + LPWSTR dst = HeapAlloc(GetProcessHeap(), 0, len * sizeof(buffer)); > + DWORD ret; > + > + if (!dst) return 0; > + ret = RtlGetFullPathName_U(name, len * sizeof(WCHAR), dst, lastpart) / sizeof(WCHAR); I don't quite understand the above bit of code: 1. HeapAlloc(GetProcessHeap(), 0, len * sizeof(buffer)) when buffer is a pointer 2. Why you don't pass buffer directly to RtlGetFullPathName_U without allocating an intermediate storage. -- Dmitry.

2 1

Alsa 1.0 patch for audio.c
by Brett I. Holcomb 18 Jan '04

18 Jan '04

In November Sylvain Petreolle posted a patch to audio.c to make it work with the new Alsa 1.0 version. What is the license on that patch? I ask because I'd like to pass it on to the winex-devel list so they can include it. Is it possible to send it on? If not that's fine - I want to check first. Thanks.

2 1

Debugger doc pages
by Jason Edmeades 18 Jan '04

18 Jan '04

Is it something about my machine but when I go to the online debugger docs, eg: http://www.winehq.com/site/docs/wine-devel/wine-debugger I can see absolutely nothing in the text boxes. I can highlight the text and it appears to be in a minute font, and cut+paste into an editor shows me the text is there, its just too small to be visible. I tried with mozilla and IE (both from a Windows machine). Jason

4 3

Re: Need help debugging ...
by Jason Edmeades 18 Jan '04

18 Jan '04

Hope you dont mind, I was bored and its a small download (DK1). The disassembly of the failure shows we have written to eax, and info regs shows eax of 0x00. dis 0x4e4a20 shows the routine where the return value is set up in eax, and some debugging shows the initial problem is a path problem. The routine parses the input path which inder windows is c:\path\to\KEEPER95.exe and under wine is KEEPER95. It searches backwards for the last backslash and returns a pointer to the backslash or 0x00. If 0x00, the trap occurs... Now the question is where does the full path come from. Jason

8 16

Re: Add iccvid.spec to winapi_check
by Hans Leidekker 18 Jan '04

18 Jan '04

On Thursday 15 January 2004 16:07, Vincent Béron wrote: > Changelog: > Yet another new spec file added to winapi_check/modules.dat, this time > iccvid.spec. After DLL separation is complete, adding these will no longer be necessary, right? -Hans

3 4

I'm off to Cuba!
by Dimitrie O. Paun 18 Jan '04

18 Jan '04

Si señor, I'm off for a week to Varadero, Cuba! Given the terrible temperatures we had here lately (-39C with the windchill), I am happy beyond words to bask in the sun for a week. I hope it's going to be sweet, but I'll be off the web until next Sunday. Until then, hasta la vista amigos! :) -- Dimi.

1 0

Re: PATCH: tools/winewrapper and memory limits
by Marcus Meissner 18 Jan '04

18 Jan '04

On Sun, Jan 18, 2004 at 02:11:22AM +0100, Gerald Pfeifer wrote: > This would have saved me a _lot_ of time late last year. With a > memory limit set too low, I would simply get an Abort, both when > running Wine itself and `ldd wine-binary`. :-( > > This is not really FreeBSD-specific, for Marcus Meissner encountered the > problem on SUSE Linux as well; feel free to remove the first condition! This does not really help, since winewrapper is only used for in-source-tree startup. Once installed, 'wine' is no longer this shellscript, but an ELF binary. Ciao, Marcus

2 1

Re: Need help debugging ... Ddraw issue
by Jason Edmeades 17 Jan '04

17 Jan '04

Wow, lots of updates, and rather than reply to each let me try to summarize. >> The one thing I couldnt answer is how the game 'gets' the command line. >int WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ); Perhaps this way? No, I noticed the difference between the exe hdrs, (console vs gui) and I ran some tests on this, and the value in lpCmdLine seemed to be just the parms and not the "command line" / executable name. Thats why I then went on to try GetCommandLine and spotted that issue. Nice idea though, thanks >Ok, that here is exactly the problem (dlls/kernel/environ.c), it's explained in the remark of the func: >GetCommandLineA (KERNEL32.@) >* * WARNING: there's a Windows incompatibility lurking here ! >* Win32s always includes the full path of the program file, >* whereas Windows NT only returns the full file path plus arguments >* in case the program has been started with a full path. >* Win9x seems to have inherited NT behaviour. I read that as saying Win32s just provides the path and probably exe name and Winnt provides the full path, exe and parms. You may be correct, I didnt investigate this further. >> With some experimentation with a GUI pgm I think I stumbled upon the / >> an answer: > Bug#1 - GetCommandLine() returns a full path on Windows but no path on Wine Doh. >Well this should definately be fixed anyway (with a regression test), and it does sound a lot like the problem doesn't it? >I expect we use this API (or similar) to set the parameters to WinMain Yes, but I didnt see any evidence it was being called. I may have missed it.. However I think this is also a red herring... > * Note that both Start Menu Execute and Explorer start programs with > * fully specified quoted app file paths, which is why probably the only case > * where you'll see single file names is in case of direct launch > * via CreateProcess or WinExec. This may be the real issue - I was running it from within msdev.exe which works, but launching it from the command line does trap the same way. "Windbg keeper95.exe" traps on run, but windbg, ctrl+e (open exe) doesnt, and I think thats because the file dialog returns fully qualified paths (at a guess). >I wonder if when a program is invoked directly from the wine loader app we should pretend >it's been run from Explorer and pass it the full path. Alexandre, would that be an acceptable >solution (subject to more thorough testing of course). I'd be worried this may cause more problems than it solves. This is an interesting one in that wine *does* correctly emulate windows behaviour, but the app is broken to only expect a full path. Aside from an app specific option (perhaps we could add in app specific config options into a central compatibility ini file), I think the only way to capture this is to document in eg. the appDB. >"Some debugging" is a bit vague but I'll let you off that ;) I guess I just need to get better at reading disassemblies. It certainly helps as I frequently drop down to assembler when things get confusing (my 'real' job involves lots of debugging!). I wish I was better with eg. gdb syntax as I really am mostly a Windows person so far (Boo Hiss...)! Jason

3 2

Re: winecfg: a patch to review
by Ivan Leo Murray-Smith 17 Jan '04

17 Jan '04

> Windows actually does have a few settings like this (Well, XP does) Windows server 2003 and longhorn have the same functionality, and blackcomb probably has it too. Ivan.

1 0

winecfg: a patch to review
by Kirk Ruff 17 Jan '04

17 Jan '04

Hello, I have started to work on winecfg a little in attempt to get used to some workings of WINE. This is the first real open source project I have actually tried to submit a patch to. I have started to work on a few functions that were not implemented yet and before I forget to try to submit a patch again I thought I would do it now. The only part I have included in this patch is the ability to remove an application from the "Application" tab. The way I assumed that this was to do is remove the appropriate key from the registry and update the listview. I realize this is a pitiful patch since it really doesn't add much but I thought I would see if I am doing it correctly and to see if does what it should. Any help is appreciated(I hope this patch is inline, my first try at it. Kirk

7 14

Re: GetShortPathName broken
by Stefan Leichter 17 Jan '04

17 Jan '04

Am Samstag, 17. Januar 2004 22:31 schrieb Eric Pouech: > > Thanks Eric, > > > > this was the right tip. My Problem is that i have two directories. The > > first one is "C:\Program Files" but the second one is C:\Programme. After > > i renamed (first character) the second one the test program works for me > > too. So what changed is the behavoir if two directories will match the > > short path. > > So, this shouldn't impact GetShortPathName. The short name should be > unique (as the long path). So, your test should work even with your two > directories. Something is wrong somewhere. > > This patch should help ? > Yes, thanks it works fine here Thanks Stefan

1 0

Re: Try using the Mozilla Active X control in MSHTML
by Dimitrie O. Paun 17 Jan '04

17 Jan '04

On January 16, 2004 01:06 am, Mike McCormack wrote: > Since some people have been complaining that MSHTML is a useless > distraction in it's current form (there's some element of truth in > that), here's a small patch to redirect calls to Mozilla's Active X > control. You need to add a "mshtml"="builtin,native" override in the > config file and download and install the control before this patch can > try to use it: > > http://www.iol.ie/~locka/mozilla/control.htm Very nice Mike! I guess this requires a Win32 build of Mozilla, no? Anyway, if the patch goes in, it would be nice if our good packagers can come up with a binary package (say, wine-mozilla?) that just installs alongside with the wine package and provides this capability. -- Dimi.

4 4

Running Wine under MS SFU under Wine ... ?
by Dan Kegel 17 Jan '04

17 Jan '04

I recently posted with problems running Microsoft's Services for Unix under Wine. I only tried it out of morbid curiosity, actually, and because MS was offering it for free. The free offer expired, but it's back again for a little while; slashdot.org seems to be running banner ads for it. I'd encourage any of you who even *might* be tempted to try this out to go order the CD-ROM. It would be way bitchin' cool if we could nest Wine and MS SFU (I seem to recall we can't nest Wine in Cygwin for some technical reason, but who knows, maybe SFU won't have the same problem). - Dan

3 3

GetShortPathName broken
by Stefan Leichter 17 Jan '04

17 Jan '04

Hello, The function GetShortPathName is broken in current cvs. This short program exhibits the problem: ------------------------------------ #include <stdio.h> #include <windows.h> #include <version.h> int main(int argc,char **argv[]) { char buffer[0x104] =""; DWORD retval; retval = GetShortPathName("C:\\Program Files", buffer, sizeof(buffer)); printf("%08x, %08x, %s\n", retval, GetLastError(), buffer ); return(0); } ----------------------------------------- On win2k and wine "2004-01-14 CST" i get 0000000b as retval and 00000000 from GetLastError() starting with wine "2004-01-14 18:21:00 CST" up to current cvs i get 00000000 for retavl and 00000002 from GetLastError(). So for my understanding the patch http://cvs.winehq.com/patch.py?id=10682 broke the function. Bye Stefan

2 2

Re: Debugger doc pages
by Jason Edmeades 17 Jan '04

17 Jan '04

>> Is it something about my machine but when I go to the online debugger >> docs, eg: http://www.winehq.com/site/docs/wine-devel/wine-debugger I can >> see absolutely nothing in the text boxes. I can highlight the text and >> it appears to be in a minute font, and cut+paste into an editor shows me >> the text is there, its just too small to be visible. >> I tried with mozilla and IE (both from a Windows machine). >WORKSFORME with Firebird 0.7 on Fedora... and >It looks fine for me in Konqy, under Linux (RH9). >Is the font setup on that machine odd in any way? Not that I know of! Its a relatively new (<2months) old WinXP install, but its something weird as my other machine (win2k partition) can see them fine. If it was 'just' IE or just Mozilla, I wouldnt mind, but for both to be broken does make it look like a machine wide issue. Debugging this further, the style sheet has as font for <pre> 'Fixed'. I changed this to PRE { FONT-SIZE: 10pt; FONT-FAMILY: Courier, Fixed } and it works, so it implies my 10pt Fixed family font is wrong? On my 2k(working) box, I ran character map, and in the font dropdown I had Fixedsys but not fixed. On my XP box I actually had listed an entry for 'fixed', which sure enough had small fonts. Any idea how to get from charmap -> font? I dir a dir *fixed* /s on my machine, no luck. Anyone else with XP who could try that page and see if they suffer the same way please? Jason

1 0

Problem with configure/config.cache
by Dominik Strasser 17 Jan '04

17 Jan '04

Hi, I am running into a problem, each time I rerun tools/wineinstall: wineinstall calls configure; configure finds a valid config.cache. On detction of the aRTS sound server it does the following: if test "${ac_cv_c_artsserver+set}" = set; then echo $ECHO_N "(cached) $ECHO_C" >&6 else # check for aRTS ... so if configure is called repeatedly, the else clause is not executed. But only in this else clause, ARTSC_CFLAGS and ARTSC_LIBS are set, which results in an uncompilable wine alsa driver because ARTSLIBS and ARTSINCL is set to those vars. Something similar happens in the detection of the asm keywords to be used in the stabs generation. I am not an autoconf guru, so I have no clue how to fix this. Regards Dominik

2 1

Re: Partial MDI rewrite
by Alexandre Julliard 17 Jan '04

17 Jan '04

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Merge the MDI and common window creation code. Change a way > MDI children are managed in MDIClient. > Add support for MDICREATESTRUCT A<->W conversions. > Add support for WM_MDIREFRESHMENU. The critical section thing worries me, especially since you are doing things that may require sending messages in there. I think you should use the normal USER lock when locking is really necessary; note that anything that is only accessed from the window procedure doesn't need locking at all. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Implement LockWindowUpdate [take 3]
by Alexandre Julliard 17 Jan '04

17 Jan '04

Mike Hearn <mike(a)theoretic.com> writes: > I hit Google and found a page describing how to reduce flickering in > FrontPage by writing a utility VB app using LockWindowUpdate and > FindWindow, so clearly my initial implementation was wrong and this does > need server support. The resultant code is also cleaner I feel. Yes it's much better. Now the problem is that the rest of the code won't be able to cope with it: in order to make sure painting always happens correctly, you will need to invalidate all the DCEs concerned by the window, to make sure all the update regions are recomputed correctly. Unfortunately this can't be done inter-process at the moment... -- Alexandre Julliard julliard(a)winehq.com

3 6

Regression tests and Paul Millars WRT
by Mike Hearn 17 Jan '04

17 Jan '04

So, I saw in WWN mention of this website which I stumbled across by accident a few weeks ago, and had another look. I couldn't believe how useful it was, yet nobody seemed to use it and it's not a part of WineHQ. A few questions, therefore: 1) Firstly, to Paul - could you hook things up so that when we get new red/purple builds an email is sent to wine-devel? I just sent a patch to fix the http tests that started failing but I wouldn't have seen it if it was not for your system. I think Alexandre runs the test suite before checking in each patch, but it's still possible that there are ones he misses (like this). If it was being done automatically perhaps AJ would not need to run the whole test suite before each commit, so he could work faster as well (and alexandre-cycles are waaaaay more valuable than cpu-cycles :) 2) Why is this not running on a WineHQ machine? Too expensive? Not needed? 3) Is the source to WRT available anywhere? thanks -mike

2 1

A question about winehq options
by Kirk Ruff 17 Jan '04

17 Jan '04

I am trying to work on a multimedia tab, unless someone else is doing this already. I am wondering what options should go on this tab. A select for the audio driver, wave mapper, and midi mapper is what I was thinking so far. The wave/midi mapper seem to each only have 1 option so what should I do for that? Is there any plan to add any more options to these two? The dsound options seem too obscure to be in winecfg, and I didn't see any other obvious options to put on. Hopefully someone else hasn't started on such a tab yet. Any help is appreciated.

3 3

Re: Need help debugging ... Ddraw issue
by Jason Edmeades 17 Jan '04

17 Jan '04

>I was following your posts here in real time and you almost found solutions faster than I could try them out, LOL! To be honest these things come down to luck sometimes, depending on what direction you start debugging! I was very lucky with this one - I ran them side by side on 2 machines, one under windows and one under wine, put breakpoints at the point of failure and worked backwards comparing the two. >I can confirm that the screen switches and a picture shows up when using full win-path and the mouse acts weird. >Haven't tried commenting out anything yet. Weird. Mine trapped as soon as the splash screen was removed, so I had to do that commenting before I could get to the main menu. >I'm trying to investigate that GetCommandLine thing. The one thing I couldnt answer is how the game 'gets' the command line. It doesnt (didnt!) appear to use any API to do it, although I didnt spend long looking into this. I hit it in wine when i tried to think of what possible ways you could get to the command line and tested some of them. This would probably need some more work to find out exactly how this game does it (I doubt it accesses the PEB directly). As to the mouse problem, I dont know - I've had other games where the mouse behaviour is weird and jumpy, but never quite like that. Does turning on (or off) dxgrab make a difference? (Not booted into Linux just now). Does DK2 suffer from the same thing, or is there another problem? Jason

2 1

Html Help
by Acke Carlsson 17 Jan '04

17 Jan '04

Heavy based on Chris Morgan's winebrowser i cut/paste a winehh, to use a Unix chm-file viewer. It works when there is no space in the path. How to do the transform from windows path to Unix path right? You find a static linked Unix chm-file viewer on this URL http://www.herdsoft.com/ftp/chmviewer-0.1.tar.gz Or get xchm from SourceForge Apologize for wrongly spelling. mvh Acke Carlsson Index: configure.ac =================================================================== RCS file: /mnt/hd/cvs/wine/wine/configure.ac,v retrieving revision 1.228 diff -u -r1.228 configure.ac --- configure.ac 9 Jan 2004 00:03:00 -0000 1.228 +++ configure.ac 9 Jan 2004 23:38:41 -0000 @@ -1657,6 +1657,7 @@ programs/wineconsole/Makefile programs/winedbg/Makefile programs/winefile/Makefile +programs/winehh/Makefile programs/winemenubuilder/Makefile programs/winemine/Makefile programs/winepath/Makefile Index: winedefault.reg =================================================================== RCS file: /mnt/hd/cvs/wine/wine/winedefault.reg,v retrieving revision 1.84 diff -u -r1.84 winedefault.reg --- winedefault.reg 6 Jan 2004 20:49:59 -0000 1.84 +++ winedefault.reg 9 Jan 2004 23:34:51 -0000 @@ -4614,6 +4614,16 @@ [HKEY_CLASSES_ROOT\http\shell\open\command] @="winebrowser %1" +[HKEY_CLASSES_ROOT\.chm] +@="chm.file" + +[HKEY_CLASSES_ROOT\chm.file] +@="Compiled HTML Help file" + +# Map requests to open "chm.file" entries to winehh +[HKEY_CLASSES_ROOT\chm.file\shell\open\command] +@="winehh %1" + # # Entries for DirectShow # Index: programs/Makefile.in =================================================================== RCS file: /mnt/hd/cvs/wine/wine/programs/Makefile.in,v retrieving revision 1.43 diff -u -r1.43 Makefile.in --- programs/Makefile.in 6 Jan 2004 20:49:59 -0000 1.43 +++ programs/Makefile.in 9 Jan 2004 23:47:00 -0000 @@ -27,6 +27,7 @@ wineconsole \ winedbg \ winefile \ + winehh \ winemenubuilder \ winemine \ winepath \ @@ -56,6 +57,7 @@ wineconsole \ winedbg \ winefile \ + winehh \ winemenubuilder \ winemine \ winepath \ @@ -78,6 +80,7 @@ wineconsole \ winedbg \ winefile \ + winehh \ winemine \ winepath \ winhelp @@ -107,6 +110,7 @@ wineconsole.exe \ winedbg.exe \ winefile.exe \ + winehh.exe \ winemenubuilder.exe \ winemine.exe \ winepath.exe \ @@ -227,6 +231,9 @@ winefile.exe$(DLLEXT): winefile/winefile.exe$(DLLEXT) $(RM) $@ && $(LN_S) winefile/winefile.exe$(DLLEXT) $@ +winehh.exe$(DLLEXT): winehh/winehh.exe$(DLLEXT) + $(RM) $@ && $(LN_S) winehh/winehh.exe$(DLLEXT) $@ + winemenubuilder.exe$(DLLEXT): winemenubuilder/winemenubuilder.exe$(DLLEXT) $(RM) $@ && $(LN_S) winemenubuilder/winemenubuilder.exe$(DLLEXT) $@ @@ -271,6 +278,7 @@ wineconsole/wineconsole.exe$(DLLEXT): wineconsole winedbg/winedbg.exe$(DLLEXT): winedbg winefile/winefile.exe$(DLLEXT): winefile +winehh/winehh.exe$(DLLEXT): winehh winemenubuilder/winemenubuilder.exe$(DLLEXT): winemenubuilder winemine/winemine.exe$(DLLEXT): winemine winepath/winepath.exe$(DLLEXT): winepath Index: programs/make_progs =================================================================== RCS file: /mnt/hd/cvs/wine/wine/programs/make_progs,v retrieving revision 1.2 diff -u -r1.2 make_progs --- programs/make_progs 6 Jan 2004 20:49:59 -0000 1.2 +++ programs/make_progs 9 Jan 2004 23:41:00 -0000 @@ -41,6 +41,7 @@ "wineconsole" => 1, "winedbg" => 1, "winefile" => 1, + "winehh" => 1, "winemine" => 1, "winepath" => 1, "winhelp" => 1, Index: tools/wineinstall =================================================================== RCS file: /mnt/hd/cvs/wine/wine/tools/wineinstall,v retrieving revision 1.64 diff -u -r1.64 wineinstall --- tools/wineinstall 6 Jan 2004 22:08:33 -0000 1.64 +++ tools/wineinstall 9 Jan 2004 23:43:59 -0000 @@ -146,6 +146,7 @@ link_app winhelp "$CROOT/windows/winhelp.exe" link_app winhelp "$CROOT/windows/winhlp32.exe" link_app winebrowser "$CROOT/windows/winebrowser.exe" + link_app winehh "$CROOT/windows/winehh.exe" } # startup... --- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ programs/winehh/.cvsignore 2004-01-10 01:18:52.000000000 +0100 @@ -0,0 +1,3 @@ +Makefile +winehh.exe.dbg.c +winehh.exe.spec.c --- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ programs/winehh/Makefile.in 2004-01-10 00:42:30.000000000 +0100 @@ -0,0 +1,14 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = winehh.exe +APPMODE = cui +IMPORTS = shell32 user32 advapi32 kernel32 + +C_SRCS = \ + main.c + +@MAKE_PROG_RULES@ + +### Dependencies: --- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ programs/winehh/main.c 2004-01-10 04:16:11.000000000 +0100 @@ -0,0 +1,109 @@ +/* + * winehh winelib app to launch native OS chm-file viewer + * + * Copyright (C) 2004 Chris Morgan + * Copyright (C) 2004 Acke Carlsson + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * NOTES: + * Winehh is a winelib application that will start the appropriate + * native chm-file viewer up for a wine installation that lacks a + * windows chm-file viewer. + */ + +#include "config.h" +#include "wine/port.h" + +#include <windows.h> +#include <stdio.h> +#include <stdlib.h> +#include <errno.h> + +/***************************************************************************** + * Main entry point. This is a console application so we have a main() not a + * winmain(). + */ +int main (int argc, char *argv[]) +{ + static char path[MAX_PATH]; + + typedef BOOL (WINAPI *wine_get_unix_file_name_t) ( LPCWSTR dos, LPSTR buffer, DWORD len ); + wine_get_unix_file_name_t wine_get_unix_file_name_ptr = NULL; + + wine_get_unix_file_name_ptr = (wine_get_unix_file_name_t) + GetProcAddress(GetModuleHandle("KERNEL32"), "wine_get_unix_file_name"); + + fprintf(stderr, "winehh open: %s\n", argv[1]); + + WCHAR dosW[MAX_PATH]; + MultiByteToWideChar(CP_ACP, 0, argv[1], -1, dosW, MAX_PATH); + wine_get_unix_file_name_ptr(dosW, path, sizeof(path)); + + fprintf(stderr, "winehh open: %s\n", path); + + const char *argv_new[3]; + DWORD maxLength; + CHAR szChmViewer[256]; + DWORD type; + CHAR *defaultChmViewer = "displaychm,xchm"; + char *chmviewer; + HKEY hkey; + LONG r; + + /* is this necessary for a chmviewer */ + unsetenv("TEMP"); + unsetenv("TMP"); + + maxLength = sizeof(szChmViewer); + + if(RegCreateKeyEx( HKEY_CURRENT_USER, + "Software\\Wine\\WineHH", 0, NULL, + REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, + &hkey, NULL)) + { + fprintf( stderr, "winehh: cannot create config key\n" ); + return 1; + } + + r = RegQueryValueExA( hkey, "ChmViewer", 0, &type, szChmViewer, &maxLength); + if(r != ERROR_SUCCESS) + { + /* set value to the default */ + RegSetValueExA(hkey, "ChmViewer", 0, REG_SZ, + (LPBYTE)defaultChmViewer, lstrlen(defaultChmViewer) + 1); + strcpy( szChmViewer, defaultChmViewer ); + } + + RegCloseKey(hkey); + + + /* now go through the list of chmviewers until we run out or we find one that */ + /* works */ + chmviewer = strtok(szChmViewer, ","); + + while(chmviewer) + { + argv_new[0] = chmviewer; + argv_new[1] = path; + argv_new[2] = NULL; + + spawnvp(_P_OVERLAY, chmviewer, argv_new); /* only returns on error */ + + chmviewer = strtok(NULL, ","); /* grab the next chmviewer */ + } + fprintf( stderr, "winehh: could not find a chmviewer to run\n" ); + return 1; +}

4 6

RE: dmesg error about pthreads
by PETREOLLE Sylvain 17 Jan '04

17 Jan '04

Hi Kevin, I have the same messages and was about to write to wine-devel. But I dont know what to do. -----Message d'origine----- De : Kevin DeKorte [mailto:kdekorte@yahoo.com] Envoyé : vendredi 16 janvier 2004 16:16 À : wine-devel(a)winehq.com Objet : dmesg error about pthreads On my FC1 system with the latest patches I'm getting this in the dmesg log. Been getting them for awhile. application bug: wine-pthread(4537) has SIGCHLD set to SIG_IGN but calls wait(). (see the NOTES section of 'man 2 wait'). Workaround activated. wine -v Wine 20031212 Is this anything I need to worry about Kevin ---------------------------------------------------------------------------- Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels et sont exclusivement destinés à l'usage de la personne à laquelle ils sont adressés. Tout point de vue ou toute opinion contenus dans ce message expriment la pensée personnelle de leur auteur et ne représentent pas nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas la personne à laquelle ce message est destiné, veuillez noter que vous avez reçu cet e-mail par erreur et qu'il vous est strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message. Si vous avez reçu ce message par erreur, merci de contacter la personne qui vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO déclinent toute responsabilité en cas d'altération, de modification, d'édition, de diffusion sans autorisation de ce message ou en cas d'affection de ce message par un virus. This message and any attachments (the "message") are confidential and intended solely for the use of the individual to whom they are addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the GEFCO Group of Companies. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this message is strictly prohibited. If you have received this message in error please contact the sender and delete the message immediately. The GEFCO Group of Companies shall not be liable for the message if altered, changed, falsified, edited, diffused without authorization or affected by any virus. ----------------------------------------------------------------------------

1 0

Re: [winecfg] - audio tab w/autodetection, misc
by Dimitrie O. Paun 17 Jan '04

17 Jan '04

On January 4, 2004 11:53 pm, Chris Morgan wrote: > I wasn't sure what to do with the resource files so I went and copied the > changes from the En.rc over to the rest of the rc files. Don't do that, it will hide the fact that the resource was not yet translated properly. Just update the En.rc one, and let the others be translated by the appropriate translators... -- Dimi.

2 1

Re: DPA_Create/Search may be missing
by Rolf Kalbermatter 16 Jan '04

16 Jan '04

On Fri, 16 Jan 2004, Hans Leidekker wrote: >> Did you by any chance build the test with MinGW? >No, I compiled it with Microsoft Visual C++ 6.0. I made sure to get the >latest and complete Windows SDK too as the previous one I had was >missing 'shlwapi.h'. Well those DPA (and DSA) functions are a little bit messy. They have been exported from the DLL since the start only by ordinal except maybe with Windows XP. The original Windows 95 SDK contained them all in the import libs (but no headers with the definitions) then they disappeard entirely from the SDK and were only lately added again to the SDK documentation together with many other undocumented shell32 functions. The import libs however missed them until SDK of February 2003 and there some, namely at least DPA_Create and DPA_GetPtr are still missing, requiring an application to either load them dynamiclly by ordinal or creating a separate import lib for them at least if you want to use Visual C ;-). Wine being smarter of course creates the correct import libs for its own use based on the spec files. Rolf Kalbermatter

1 0

slight trouble running winetests under windows
by Chris Morgan 16 Jan '04

16 Jan '04

I'm trying to get some of the wine tests compiling and running under windows, oleaut32 test specifically. I've got the project file built and everything opens fine under visual studio 6. The only issue is that during linking of the oleaut32 tests _IID_IFont is undefined. Oddly enough if I switch from a non-mfc project to a mfc project, compile, run into errors and then switch back to a non-mfc project things work fine, no more symbol errors about IID_IFont. I even tried cleaning things out and removing the output directory entirely and the test still compiles once the non-mfc->mfc->non-mfc change has been performed. I can't seem to see what difference going into mfc and back should have on the project, it seems like we are missing something from our .dsp project or something. I can't seem to identify changes in the .dsp or .dsw files either... Has anyone else seen this? Thanks, Chris

7 14

[Fwd: Bug#224498: A recipe of potential use to MS Office 97 aspiring users on Debian]
by Ove Kaaven 16 Jan '04

16 Jan '04

-----Videresendt melding----- From: Emmanuel Charpentier <charpent(a)bacbuc.dyndns.org> To: 224498(a)bugs.debian.org Cc: ovek(a)arcticnet.no Subject: Bug#224498: A recipe of potential use to MS Office 97 aspiring users on Debian Date: Mon, 12 Jan 2004 23:16:44 +0100 Dear Ove, dear Wine users and w(h)iners, First, a big "Thank you" to Ove : maintaining a Debian package is work, and maintaining a beast such as Wine is *hard* work. I feel very grateful to Debian maintainers, and to Ove. I have read the bug report about MS Office and the consecutive somewhat heated argument. While I won't delve in the "necessities" of using MS programs, I agree that there is not yet a free tool able to reach into .mdb databases sent by people you can't demand another format. (Yes, I'm aware of the .mdb tools. They crash on me any time I try to use them on a French .mdb ...). Ant that might be justification enough to try to get Wine working with that piece of s...oftware. The following recipe *might* help people not yet able to get rid of MS Office. Start by getting the latest (20031212) version of wine (that's in unstable for you, Debian users ...). This version seems to be a *vast* improvement over whatever I tried before (last time was summer '03, IIRC). You will need a working Windows 98 installation (for which, of course, you have a valid license...). But you'll have to start with a fresh no-windows installation. The simplest way I found is to rename any previous .wine/config file and .wine/fake-windows directory, then to call winsetup and to ask for the creation of a new config file without Windows installation. Starting from here, install from the MS cdrom : wine /cdrom/install.exe. This installation will copy a lot of files, then FAIL. That's not a problem. You'll then grab the following files from your working Windows installation: - stdole32.tlb (This one is the only one needed for Winword, Powerpoint and maybe Excel). - ole32.dll - vbajet32.dll (and maybe vba332.dll (that's not a typo), can't recall at the moment). - oleaut32.dll - msacnv30.dll - tzisolat.dll - (maybe) odbc.dll IIRC, all of this, except vba332.dll come from the \Windows\System directory of your native Win98 installation and go to .wine/fake_windows/Windows/System directory. In the .wine/config file, mark these libraries as "native,builtin" in the [DLLOverrides] section. Restart the installation of MS Office from the CD. This time, the installation should work (and be much faster than the first time around, since almost all file already exist). It will complaint that it cannot DDE-connect to the desktop (in order to create the shortcuts), but that's harmless : just hit "Ignore". The first launch of the applications may be painful : at first run, MS Office apps try to launch a "helpful" dialog box "presenting" the application, which have trouble communicating with the main program. I found that minimizing and restoring the main window may help. Don't ask me why. As far as my limited test can tell, Winword and Powerpoint work fine. With the relevant fonts in xfs and a correct CUPS setup, printing is automatic and gives very good results. MS Access still gives me guff : I have Cyrillic characters in place of Western accented characters, form creation dialog boxes have serious quirks (e. g. the "Properties" dialog box fights for focus with the "Save as" dialog box in Design mode), I had a crash trying to display an "outer join" view, etc ... But that is infinitely better that no MS Access at all ... I have now some hope of solving some of these hurdles. The SR1 and SR2 "service packs" can be installed with no problems. Hoping this helps, Emmanuel Charpentier PS : Ove, if you think this might be of interest elsewhere, and does not step too rudely on the (very) sensitive toes of DFSG and Social Contract, please feel free to forward to any relevant place, cut and paste or paraphrase at will ... PPS : Mandatory disclaimer : I found this by trial and error. I might be wrong. But that's my problem. Now, I won't accept *ANY* responsibility for the (mis-)use you may make of this information, either technical or legal. In other words, you're on your own : if this blows your system, drowns your basement, launches against you a thousand of ships full of angered Microsoft lawyers, shaves your cat or rapes your grandma (or vice-versa), that's *YOUR* problem, buddy, not mine.

1 0

Need help debugging ...
by Frank.Schruefer＠t-online.de 16 Jan '04

16 Jan '04

Hy list, I like to learn how to fix wine problems myself and am trying to track down an exception occuring while starting good old 'Dungeon Keeper'. For now I have two problems: 1. When I invoke the game with 'wine' and with 'winedbg' I get different exception messages (traces see below), why? 2. How to compile debug information into the 32bit DLL's so I don't get 'No debug information in 32bit DLL' anymore and maybe some better info? I tried 'configure --enable-debug && make depend && make && su -c "make install"' to no avail. I compiled 'fixme's into the 'SetThreadExecutionState' and 'VerSetConditionMask' funcs to see where the exceptions occure but it seems the methods aren't even called at all because the messages don't get printed out (or need the fixme messages switched on somewhere for that particular dll?). I also tried to start with --debugmsg +all in which case the output is overwriting the winedbg command line interface and crashing it when trying to exit with CTRL-C and CTRL-D. Only killall -9 wine-pthread helps then. The wine I'm using is fresh from CVS as of 15. Jan. 2004 but I had the problem with earlier versions too. ============= STARTING WITH 'wine' ================ merlin@Merlin:~/.wine/fake_windows/Program Files/Bullfrog/Keeper> wine KEEPER95.EXE wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 8 Loaded debug information from ELF 'wine' ((nil)) No debug information in 32bit DLL 'C:\Program Files\Bullfrog\Keeper\KEEPER95.EXE' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40220000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x404b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40760000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x406f0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x407d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x40790000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x408f0000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\MSS32.DLL' (0x20000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x409e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40960000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\WSND7R.DLL' (0x10000000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\SMACKW32.DLL' (0x40022000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DDRAW.DLL' (0x40a20000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DPLAYX.DLL' (0x40be0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IPHLPAPI.DLL' (0x40c30000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WS2_32.DLL' (0x40c10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WSOCK32.DLL' (0x40a80000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40d10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x41390000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x413e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x413c0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41400000) Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x00406062). In 32-bit mode. 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE): movb $0x0,0x0(%eax) Wine-dbg>bt Backtrace: =>0 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE) (ebp=406cff2c) 1 0x40501e3d (KERNEL32.DLL.SetThreadExecutionState+0x17fd in KERNEL32.DLL) (ebp=406cfff4) 2 0x4003e60d (SMACKW32.DLL..reloc+0x660d) (ebp=00000000) Wine-dbg> ============= STARTING WITH 'wine' END ============ ============= STARTING WITH 'winedbg' ============= merlin@Merlin:~/.wine/fake_windows/Program Files/Bullfrog/Keeper> winedbg KEEPER95.EXE fixme:console:SetConsoleCtrlHandler (0x405feed0,1) - no error checking or testing yet WineDbg starting on pid 19 Breakpoint 1 at 0x004f1ed0 Unable to add breakpoint, will check again any time a new DLL is loaded Loaded debug information from ELF 'wine' ((nil)) No debug information in 32bit DLL 'C:\Program Files\Bullfrog\Keeper\KEEPER95.EXE' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40220000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x404b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40760000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x406f0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x407d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x40790000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x408f0000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\MSS32.DLL' (0x20000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x409e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40960000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\WSND7R.DLL' (0x10000000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\SMACKW32.DLL' (0x40a05000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DDRAW.DLL' (0x40a40000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DPLAYX.DLL' (0x40be0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IPHLPAPI.DLL' (0x40c30000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WS2_32.DLL' (0x40c10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WSOCK32.DLL' (0x40aa0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40d20000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x41390000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x413e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x413d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41400000) In 32-bit mode. Wine-dbg>cont Stopped on breakpoint 1 at 0x004f1ed0 (KEEPER95.EXE.EntryPoint in KEEPER95.EXE) Wine-dbg>cont First chance exception: page fault on write access to 0x00000000Invalid address for breakpoint 1, disabling it in 32-bit code (0x00406062). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0007 EIP:00406062 ESP:406cfd18 EBP:406cff2c EFLAGS:00010206( R- 00 I - -P1 ) EAX:00000000 EBX:ffffffff ECX:00000000 EDX:406cfcec ESI:00776685 EDI:406cfd99 Stack dump: 0x406cfd18 (KERNEL32.DLL.VerSetConditionMask+0x14e97a): *** Invalid address 0x406cfd18 (KERNEL32.DLL.VerSetConditionMask+0x14e97a) 0200: sel=1007 base=4001a000 limit=00001f83 32-bit rw- Backtrace: =>0 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE) (ebp=406cff2c) Can't read TEB:cur_stack 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE): *** Invalid address 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE) -- no code -- Wine-dbg> ============= STARTING WITH 'winedbg' END ========= -- Thanks, Frank

4 5

Debugger bugs.
by Frank.Schruefer＠t-online.de 16 Jan '04

16 Jan '04

Hy, I've stumbled over problems trying to debug RtlCreateUserThread. The error I get depends on how I'm stepping through the code but seems to be caused by the syscall __NR_rt_sigprocmask (int 0x80 with eax=175). The thread for which procmask should get set is created by TIME_MMTimeStart in winmm/time.c; Unfortunately I've no idea whether that's "normal" or how to fix ... If you want me to provide more info just tell me what you need to know. I got three versions (common trace of all three versions see below): ========= FIRST VERSION: Stepping over 'sigprocmask( SIG_BLOCK, &block_set, &old_set );' ============= ... (COMMON TRACE) ... Wine-dbg> 241 struct __server_request_info * const req = req_ptr; Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> err:seh:setup_exception stack overflow 192 bytes in thread 000b eip 4023035b esp 405e0f40 stack 0x405e0000-0x406e0000 Invalid address for breakpoint 0, disabling it Invalid address for breakpoint 1, disabling it Invalid address for breakpoint 2, disabling it Invalid address for breakpoint 3, disabling it Process of pid=0000000a has terminated Wine-dbg> ====================================================================================================== ========= SECOND VERSION: Stepping over 'int 0x80' with eax=0xAF (=175) ============================== ... (COMMON TRACE) ... Wine-dbg> 241 struct __server_request_info * const req = req_ptr; Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg>si 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc81 (wine_server_call+0x22 [server.c:244] in NTDLL.DLL): pushl %eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc82 (wine_server_call+0x23 [server.c:244] in NTDLL.DLL): leal 0x5884(%ebx),%eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc88 (wine_server_call+0x29 [server.c:244] in NTDLL.DLL): pushl %eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc89 (wine_server_call+0x2a [server.c:244] in NTDLL.DLL): pushl $0x0 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc8b (wine_server_call+0x2c [server.c:244] in NTDLL.DLL): call 0x40211788 (_init+0x46c in ntdll.dll.so) 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 0x40211788 (_init+0x46c in ntdll.dll.so): jmp *0x11c(%ebx) Wine-dbg> 0x400cdb10 (NTDLL.DLL.toupper+0x64a0 in libc.so.6): pushl %ebp Wine-dbg> 0x400cdb11 (NTDLL.DLL.toupper+0x64a1 in libc.so.6): movl %esp,%ebp Wine-dbg> 0x400cdb13 (NTDLL.DLL.toupper+0x64a3 in libc.so.6): subl $8,%esp Wine-dbg> 0x400cdb16 (NTDLL.DLL.toupper+0x64a6 in libc.so.6): movl %esi,0x0(%esp) Wine-dbg> 0x400cdb19 (NTDLL.DLL.toupper+0x64a9 in libc.so.6): movl $0x8,%esi Wine-dbg> 0x400cdb1e (NTDLL.DLL.toupper+0x64ae in libc.so.6): movl %edi,0x4(%esp) Wine-dbg> 0x400cdb22 (NTDLL.DLL.toupper+0x64b2 in libc.so.6): movl 0x8(%ebp),%edi Wine-dbg> 0x400cdb25 (NTDLL.DLL.toupper+0x64b5 in libc.so.6): movl 0xc(%ebp),%ecx Wine-dbg> 0x400cdb28 (NTDLL.DLL.toupper+0x64b8 in libc.so.6): movl 0x10(%ebp),%edx Wine-dbg> 0x400cdb2b (NTDLL.DLL.toupper+0x64bb in libc.so.6): xchgl %ebx,%edi Wine-dbg> 0x400cdb2d (NTDLL.DLL.toupper+0x64bd in libc.so.6): movl $0xaf,%eax Wine-dbg> 0x400cdb32 (NTDLL.DLL.toupper+0x64c2 in libc.so.6): int $0x80 Wine-dbg> fixme:seh:UnhandledExceptionFilter Unhandled error on debug event: 0 0x400cdb36 (NTDLL.DLL.toupper+0x64c6 in libc.so.6): cmpl $-4096,%eax Wine-dbg> ====================================================================================================== ========= THIRD VERSION: Stepping into 'int 0x80' with eax=0xAF (=175) =============================== ... (COMMON TRACE) ... Wine-dbg> 241 struct __server_request_info * const req = req_ptr; Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg>si 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc81 (wine_server_call+0x22 [server.c:244] in NTDLL.DLL): pushl %eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc82 (wine_server_call+0x23 [server.c:244] in NTDLL.DLL): leal 0x5884(%ebx),%eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc88 (wine_server_call+0x29 [server.c:244] in NTDLL.DLL): pushl %eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc89 (wine_server_call+0x2a [server.c:244] in NTDLL.DLL): pushl $0x0 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc8b (wine_server_call+0x2c [server.c:244] in NTDLL.DLL): call 0x40211788 (_init+0x46c in ntdll.dll.so) 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 0x40211788 (_init+0x46c in ntdll.dll.so): jmp *0x11c(%ebx) Wine-dbg> 0x400cdb10 (NTDLL.DLL.toupper+0x64a0 in libc.so.6): pushl %ebp Wine-dbg> 0x400cdb11 (NTDLL.DLL.toupper+0x64a1 in libc.so.6): movl %esp,%ebp Wine-dbg> 0x400cdb13 (NTDLL.DLL.toupper+0x64a3 in libc.so.6): subl $8,%esp Wine-dbg> 0x400cdb16 (NTDLL.DLL.toupper+0x64a6 in libc.so.6): movl %esi,0x0(%esp) Wine-dbg> 0x400cdb19 (NTDLL.DLL.toupper+0x64a9 in libc.so.6): movl $0x8,%esi Wine-dbg> 0x400cdb1e (NTDLL.DLL.toupper+0x64ae in libc.so.6): movl %edi,0x4(%esp) Wine-dbg> 0x400cdb22 (NTDLL.DLL.toupper+0x64b2 in libc.so.6): movl 0x8(%ebp),%edi Wine-dbg> 0x400cdb25 (NTDLL.DLL.toupper+0x64b5 in libc.so.6): movl 0xc(%ebp),%ecx Wine-dbg> 0x400cdb28 (NTDLL.DLL.toupper+0x64b8 in libc.so.6): movl 0x10(%ebp),%edx Wine-dbg> 0x400cdb2b (NTDLL.DLL.toupper+0x64bb in libc.so.6): xchgl %ebx,%edi Wine-dbg> 0x400cdb2d (NTDLL.DLL.toupper+0x64bd in libc.so.6): movl $0xaf,%eax Wine-dbg> 0x400cdb32 (NTDLL.DLL.toupper+0x64c2 in libc.so.6): int $0x80 Wine-dbg>ni err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 ... INFINITE LOOP, PATTERN NOW REPEATING UNTIL 'killall -9 wine-pthread' ... ====================================================================================================== ============================================ COMMON TRACE ============================================ merlin@Merlin:/my/hom/merlin/.wine/fake_windows/Program Files/Bullfrog/Keeper> winedbg KEEPER95.EXE fixme:console:SetConsoleCtrlHandler (0x40615b43,1) - no error checking or testing yet WineDbg starting on pid e Breakpoint 1 at 0x004f1ed0 Unable to add breakpoint, will check again any time a new DLL is loaded Loaded debug information from ELF '/usr/local/bin/wine-pthread' ((nil)) Breakpoint 2 at 0x4000dd60 (_end+0x2fef9d60) Loaded debug information from ELF '/usr/local/lib/libwine.so.1' (0x4003a000) No debug information in ELF '/lib/i686/libpthread.so.0' (0x40053000) No debug information in ELF '/lib/i686/libc.so.6' (0x400a4000) No debug information in ELF '/lib/libdl.so.2' (0x401d7000) No debug information in ELF '/lib/i686/libm.so.6' (0x401da000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so' (0x401fe000) Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1' (0x40274000) Loaded debug information from ELF '/usr/local/lib/wine/kernel32.dll.so' (0x40480000) No debug information in 32bit DLL 'C:\Program Files\Bullfrog\Keeper\KEEPER95.EXE' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40220000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x404b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40780000) Loaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so' (0x406e0000) Loaded debug information from ELF '/usr/local/lib/wine/advapi32.dll.so' (0x4076a000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40700000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x407e0000) Loaded debug information from ELF '/usr/local/lib/wine/winspool.drv.so' (0x4079c000) Loaded debug information from ELF '/usr/local/lib/wine/user32.dll.so' (0x407c1000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x407b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x40920000) Loaded debug information from ELF '/usr/local/lib/wine/winmm.dll.so' (0x40914000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\MSS32.DLL' (0x20000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x40a20000) Loaded debug information from ELF '/usr/local/lib/wine/ole32.dll.so' (0x40988000) Loaded debug information from ELF '/usr/local/lib/wine/rpcrt4.dll.so' (0x40a04000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x409a0000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\WSND7R.DLL' (0x10000000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\SMACKW32.DLL' (0x40a4e000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DDRAW.DLL' (0x40a90000) Loaded debug information from ELF '/usr/local/lib/wine/ddraw.dll.so' (0x40a66000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x40021000) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x40b08000) No debug information in ELF '/usr/X11R6/lib/libXrandr.so.2' (0x4001c000) No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' (0x40032000) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x40b1f000) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40b2d000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DPLAYX.DLL' (0x40c40000) Loaded debug information from ELF '/usr/local/lib/wine/dplayx.dll.so' (0x40c29000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IPHLPAPI.DLL' (0x40ca0000) Loaded debug information from ELF '/usr/local/lib/wine/wsock32.dll.so' (0x40ae8000) Loaded debug information from ELF '/usr/local/lib/wine/ws2_32.dll.so' (0x40c66000) Loaded debug information from ELF '/usr/local/lib/wine/iphlpapi.dll.so' (0x40c8e000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WS2_32.DLL' (0x40c70000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WSOCK32.DLL' (0x40af0000) No debug information in ELF '/usr/lib/libfreetype.so.6' (0x40ccf000) No debug information in ELF '/usr/lib/libfontconfig.so.1' (0x40d25000) No debug information in ELF '/usr/lib/libexpat.so.0' (0x40d4d000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40d80000) Loaded debug information from ELF '/usr/local/lib/wine/x11drv.dll.so' (0x40d6d000) No debug information in ELF '/usr/lib/tls/libGL.so.1' (0x40df6000) No debug information in ELF '/usr/lib/tls/libGLcore.so.1' (0x40e53000) No debug information in ELF '/usr/X11R6/lib/libXcursor.so.1' (0x413a8000) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2' (0x4002a000) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x40caf000) No debug information in ELF '/usr/lib/gconv/ISO8859-15.so' (0x405dd000) No debug information in ELF '/usr/lib/libcups.so.2' (0x41415000) No debug information in ELF '/usr/lib/libssl.so.0.9.7' (0x41432000) No debug information in ELF '/usr/lib/libcrypto.so.0.9.7' (0x41462000) No debug information in ELF '/lib/libnss_files.so.2' (0x41554000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x41410000) Loaded debug information from ELF '/usr/local/lib/wine/wineoss.drv.so' (0x413f5000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x41460000) Loaded debug information from ELF '/usr/local/lib/wine/msacm.drv.so' (0x41438000) Loaded debug information from ELF '/usr/local/lib/wine/msacm32.dll.so' (0x41450000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x41440000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41480000) Loaded debug information from ELF '/usr/local/lib/wine/midimap.drv.so' (0x41472000) In 32-bit mode. Wine-dbg>c Stopped on breakpoint 1 at 0x004f1ed0 (KEEPER95.EXE.EntryPoint in KEEPER95.EXE) Wine-dbg>b RtlCreateUserThread Many symbols with name 'RtlCreateUserThread', choose the one you want (<cr> to abort): [1]: 0x40596350 (RtlCreateUserThread in KERNEL32.DLL) [2]: 0x40252665 (RtlCreateUserThread [thread.c:208] in NTDLL.DLL) => 2 Breakpoint 3 at 0x40252665 (RtlCreateUserThread [thread.c:208] in NTDLL.DLL) Wine-dbg>c Stopped on breakpoint 3 at 0x40252665 (RtlCreateUserThread [thread.c:208] in NTDLL.DLL) 208 { Wine-dbg>s 209 struct startup_info *info = NULL; Wine-dbg> 210 HANDLE handle = 0; Wine-dbg> 211 TEB *teb = NULL; Wine-dbg> 212 DWORD tid = 0; Wine-dbg> 217 if (pipe( request_pipe ) == -1) return STATUS_TOO_MANY_OPENED_FILES; Wine-dbg> 218 fcntl( request_pipe[1], F_SETFD, 1 ); /* set close on exec flag */ Wine-dbg> 219 wine_server_send_fd( request_pipe[0] ); Wine-dbg> 267 vec.iov_base = (void *)&data; Wine-dbg> 268 vec.iov_len = sizeof(data); Wine-dbg> 270 msghdr.msg_name = NULL; Wine-dbg> 271 msghdr.msg_namelen = 0; Wine-dbg> 272 msghdr.msg_iov = &vec; Wine-dbg> 273 msghdr.msg_iovlen = 1; Wine-dbg> 279 cmsg.len = sizeof(cmsg); Wine-dbg> 280 cmsg.level = SOL_SOCKET; Wine-dbg> 281 cmsg.type = SCM_RIGHTS; Wine-dbg> 282 cmsg.fd = fd; Wine-dbg> 283 msghdr.msg_control = &cmsg; Wine-dbg> 284 msghdr.msg_controllen = sizeof(cmsg); Wine-dbg> 285 msghdr.msg_flags = 0; Wine-dbg> 288 data.tid = GetCurrentThreadId(); Wine-dbg> 289 data.fd = fd; Wine-dbg> 293 if ((ret = sendmsg( fd_socket, &msghdr, 0 )) == sizeof(data)) return; Wine-dbg> 299 } Wine-dbg> 221 SERVER_START_REQ( new_thread ) Wine-dbg> 223 req->suspend = suspended; Wine-dbg> 224 req->inherit = 0; /* FIXME */ Wine-dbg> 225 req->request_fd = request_pipe[0]; Wine-dbg> 226 if (!(status = wine_server_call( req ))) Wine-dbg> 241 struct __server_request_info * const req = req_ptr; Wine-dbg> (LAST 3 LINES REPEATED IN ABOVE VERSIONS TO MAKE CLEAR WHERE THEY START) ====================================================================================================== -- Frank

1 0

Re: More Vacation backlog
by Alexandre Julliard 16 Jan '04

16 Jan '04

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > appended patch opens the devicefile connected to a drive as connected by the > user in ~/.wine/config [Drive X] "Device" = "/dev/yyy". > The appropriate action on that file ( read, write, set_file_pointer, ...) > succeed > according the the righte the user has on that device. The device should be opened like a normal file, using the create_file request. Then there wouldn't be any need to change the server device object (which is a nasty hack that should be removed). -- Alexandre Julliard julliard(a)winehq.com

3 3

Re: DPA_Create/Search may be missing
by Hans Leidekker 16 Jan '04

16 Jan '04

On Friday 16 January 2004 11:57, Francois Gouget wrote: > On NT4 (or is that on Internet Explorer <=5?), comctl32 is missing entry > points for DPA_Create and DPA_Search. So we need to link them > dynamically if we want the rest of the tests to run. Did you by any chance build the test with MinGW? I submitted a patch like yours a while ago and it was rejected because DPA_Create & friends where present in comctl32 but are exported by ordinal only. MinGW's libs export these by name, not ordinal only, so the resulting binary will not run on Windows. -Hans

2 1

Re: Shell32 patch from ROS 2
by Marcelo Duarte 16 Jan '04

16 Jan '04

OK. Relatively to files shlexec.c (ShellExecute, etc) I will do it. Others with you ;) ----- Original Message ----- From: "Steven Edwards" <steven_ed4153(a)yahoo.com> To: <wine-devel(a)bol.com.br>; <wine-patches(a)winehq.org> Sent: Friday, January 16, 2004 2:15 PM Subject: Re: Shell32 patch from ROS 2 > Hello Marcelo, > --- Marcelo Duarte <wine-devel(a)bol.com.br> wrote: > > Changelog: > > "Martin Fuchs" <martin-fuchs(a)gmx.net> > > - fixed HCR_GetExecuteCommandExA/W() to correct ShellExecuteEx() > > behaviour > > with flag SEE_MASK_CLASSNAME set > > Thanks for your help merging this patch. > Steven > > > __________________________________ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus

1 0

dmesg error about pthreads
by Kevin DeKorte 16 Jan '04

16 Jan '04

On my FC1 system with the latest patches I'm getting this in the dmesg log. Been getting them for awhile. application bug: wine-pthread(4537) has SIGCHLD set to SIG_IGN but calls wait(). (see the NOTES section of 'man 2 wait'). Workaround activated. wine -v Wine 20031212 Is this anything I need to worry about Kevin

1 0

DOS: fix loading of DOS exe files
by Michael Stefaniuc 16 Jan '04

16 Jan '04

Hello, the attached patch fixes a problem when loading DOS exe files which have 4 bytes on the last page of the executable. There is no comment in the code and i googled and couldn't find any reason or hint why having 4 bytes on the last page is special and why we should than load the full 512 bytes of the last page (i'm CC'ing wine-devel just in case). This prevents some of the "PC Intern 4, Systemprogrammierung" DOS example files from running with an 'invalid exe file' error. License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - do not load the full last page of a DOS EXE if we have only 4 bytes in it. 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

1 1

Re: Partial MDI rewrite
by Dmitry Timoshkov 16 Jan '04

16 Jan '04

"Duane Clark" <dclark(a)akamail.com> wrote: > > Could you please generate +win,+mdi logs before and after the patch > > and send them to me? > > > > They are a bit large, but here goes. Thank you very much. Now I see that I unintentionally omitted a bit of code dealing with cx or cy being CW_USEDEFAULT[16]. Attached patch should have it fixed. -- Dmitry.

1 0

win3.1 printer drivers
by Ivan Leo Murray-Smith 16 Jan '04

16 Jan '04

Are win3.1 printer driver still supported by wine? Ivan.

2 1

Partial MDI rewrite
by Dmitry Timoshkov 16 Jan '04

16 Jan '04

Hello all, here is a result of my work aimed to merge MDI child creation with common window creation code. The rewrite allows MDI children to have WS_EX_MDICHILD style set on WM_CREATE and therefore properly get lParam from MDICREATESTRUCT. MDICREATESTRUCT is now gets A<->W translated (translation 16-bit windows is still missing). Please give it a try with your favorite MDI application and report the results you get. The patch includes a simple test case, which passes on win9x and win2000 SP4. Thanks. -- Dmitry.

2 4

Re: Better cpuid support
by Alexandre Julliard 15 Jan '04

15 Jan '04

Robert Lunnon <bobl(a)optushome.com.au> writes: > Improves CPUID instruction support in cpu.c by reorganising the existing > FREEBSD code. Added more robust cpuid detection with built in 386 detection. > Code should work for all i386 platforms and has been tested under solaris. > Created subroutines for detecting number of CPUs and OS SSE support as this > can't be done in a uniform way across different OSes. Extracted relevant code > from each section to perform these OS specific operations (Mostly untested). It's hard to tell exactly what has changed, since you basically rewrote the whole thing, for no good reason IMO. Could you please try to merge your changes with the existing code instead? -- Alexandre Julliard julliard(a)winehq.com

2 5

activate window
by Shiming Dong 15 Jan '04

15 Jan '04

Hi there: I met with one problem. I try to send a simulated keystroke to another application (such as Notepad) to invoke one of its functions, but when I minimize the window of "Notepad", the message cannot be received even I used the SetFocus() and SetActiveWindow() function. When it is maximized, it works. Anyone can help? Here are my codes: int main( ) { HWND hwnd = FindWindow(NULL, "Untitled - Notepad"); short f3_key = VK_F3; UINT scancode = MapVirtualKey(f3_key, 0); if (hwnd!=NULL){ printf("Notepad is running!\n"); SetActiveWindow(hwnd); SetFocus(hwnd); } PostMessage(hwnd, WM_SYSKEYDOWN, f3_key, scancode); PostMessage(hwnd, WM_SYSCHAR, f3_key, scancode); PostMessage(hwnd, WM_SYSKEYUP, f3_key, scancode); return 0; } --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

1 0

CVS problem: stale lock?
by Sami Aario 15 Jan '04

15 Jan '04

Hi all, I'm getting this message over and over while attempting an update from the wine cvs repository: "cvs server: [13:31:41] waiting for wineowner's lock in /home/wine/wine" I'm guessing a CVS process has died and left a stale lock in the repository. Could someone check it out?

1 0

signing off -- good luck
by Jeremy Shaw 15 Jan '04

15 Jan '04

Hello, I am unsubscribing from wine-devel since I am no longer actively doing any wine development work. However, if any question arise about the patches I submitted recently, please feel free to email me. Good luck and have fun at wineconf! Jeremy Shaw.

1 0

Re: Build error in current cvs.
by Ivan Leo Murray-Smith 15 Jan '04

15 Jan '04

Patches http://www.winehq.com/hypermail/wine-patches/2004/01/0201.html and http://www.winehq.com/hypermail/wine-patches/2004/01/0202.html fix the problem. Ivan.

1 0

dropped mouse movement when playing CS while running another application with Wine
by Jan Brunner 15 Jan '04

15 Jan '04

Hello guys. I got CS running quite playable with and without Steam but with Steam mouse movement gets dropped sometimes (the sensitivity feels much lower). I experimented a bit and found out that this problem happens whenever Wine is running more than just hl.exe (e.g. CS + Winamp). In case this helps: Probably a bit of movement gets dropped while running CS only, too: Sensitivity 4.1 with Wine is about the same as 4.0 in Windows. It's constant though, so it doesn't matter. Any ideas on what causes the problem and how to fix it? -- Best regards, Jan Brunner <brunner(a)intergga.ch>

1 0

Fwd: Congratulations with your wine product.
by Dimitrie O. Paun 15 Jan '04

15 Jan '04

Some good words for a happy user... ---------- Forwarded Message ---------- Subject: Congratulations with your wine product. Date: January 15, 2004 09:28 am From: Pascal Pype <pascal.pype(a)skynet.be> To: wine-faq(a)winehq.org Hello maintainers and developers of wine, The performance and configuartion of your product have been tremendously enhanced with respect to an experimental version I used nearly three years ago. There were two win3.1 applications that were written with turbo pascal for windows quite some time ago. When I tried to run those from within a wine environment , the performance of wine was so poor that the applications were useless when run in a *NIX environment. (linux , freeBSD) In a linux user & developer edition , I read an article about wine and its team leader Alexandre Julliard. The article have me a good impression , so I decided to give wine another try. Here are the conclusions: 1. outstanding documentation, 2. flawless install and configuration, 3. one out of the two windows applications works exactly as it did on win3.1 whilst the other does its job for about 60% of the total functionality without any fine tuning of the wine configuration. CONGRATULATIONS AND KEEP UP THE EXECELLENT WORK!!! Yours scincerely, Pype pascal. ------------------------------------------------------- -- Dimi.

1 0

Build error in current cvs.
by Ivan Leo Murray-Smith 15 Jan '04

15 Jan '04

After a cvs update, there is this lovely build error, while building gdi, is it a problem with the recent gdi patches that have just got in or am I doing something wrong? make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/dlls/gdi' ../../tools/winebuild/winebuild -D__WINESRC__ -D_GDI32_ -o dispdib.spec.c --main-module gdi32.dll --spec dispdib.spec gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o dispdib.spec.o dispdib.spec.c ../../tools/winebuild/winebuild -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -o gdi.exe.spec.c --heap 65520 --main-module gdi32.dll --res version16.res --spec ./gdi.exe.spec gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o gdi.exe.spec.o gdi.exe.spec.c ../../tools/winebuild/winebuild -D__WINESRC__ -D_GDI32_ -o wing.spec.c --main-module gdi32.dll --spec wing.spec gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o wing.spec.o wing.spec.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o bidi16.o bidi16.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o gdi16.o gdi16.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o wing.o wing.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/bitblt.o ../../graphics/bitblt.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/dispdib.o ../../graphics/dispdib.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/env.o ../../graphics/env.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/escape.o ../../graphics/escape.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/fontengine.o ../../graphics/fontengine.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/mapping.o ../../graphics/mapping.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/painting.o ../../graphics/painting.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/path.o ../../graphics/path.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/bitmap.o ../../objects/bitmap.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/brush.o ../../objects/brush.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/clipping.o ../../objects/clipping.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/dc.o ../../objects/dc.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/dcvalues.o ../../objects/dcvalues.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/dib.o ../../objects/dib.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/enhmetafile.o ../../objects/enhmetafile.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/font.o ../../objects/font.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/gdiobj.o ../../objects/gdiobj.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/metafile.o ../../objects/metafile.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/palette.o ../../objects/palette.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/pen.o ../../objects/pen.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/region.o ../../objects/region.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/text.o ../../objects/text.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o bidi.o bidi.c bidi.c: In function `BIDI_Reorder': bidi.c:75: error: `WINE_GCPW_DIR_MASK' undeclared (first use in this function) bidi.c:75: error: (Each undeclared identifier is reported only once bidi.c:75: error: for each function it appears in.) bidi.c:77: error: `WINE_GCPW_FORCE_LTR' undeclared (first use in this function) bidi.c:80: error: `WINE_GCPW_FORCE_RTL' undeclared (first use in this function) bidi.c:83: error: `WINE_GCPW_LOOSE_LTR' undeclared (first use in this function) bidi.c:86: error: `WINE_GCPW_LOOSE_RTL' undeclared (first use in this function) make[2]: *** [bidi.o] Error 1 make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/dlls' make: *** [dlls] Error 2 [ivan@localhost wine]$

1 0

Wine User's guide : using Windows ODBC driver manager seems to work
by Emmanuel Charpentier 15 Jan '04

15 Jan '04

Following a suggestion in Wine User's Guide, (§ 1.1.2), I'd like to suggest an addition. The "ODBC" section (§ 5.12) gives details (§ 5.12.1) about the use of the native ODBC driver, routed through a fake "builtin" ODBC driver. I have not yet had to test it in real conditions. All I can tell is that I wasn't able to use it to "Attach" (M$ jargon) Postgres data in MS Access (see PPS for the setup) : when I tried to select "ODBC sources" from the "Attach tables" dialog, I got immediately an error box from unixODBC telling me that no data source was specified. However, the User's Guide is quite terse about the Windows ODBC driver. Exhaustive quotation : " Does anyone actually have any experience of this and anything to add?". Well, I do. In the same setup as before, I have been able to use the *native* odbc32.dll ODBC driver by pulling it from a real Windows instalation and adding "odbc32"="native,builtin" in the config file. I Installed the psqlodbc driver from the Postgres database, and retried : selecting "ODBC sources" in the "Attach tables" dialog box led me to the usual ODBC manager dialogs, where I have been able to create a DSN to my Postgres database. I have then been able to "Atach" my Postgres tables and views to an M$ Access database and peruse them. My conclusion is that such a setup can be used, if only to be able to export MS Access data to a more reasonable database manager. This information could be of some help to some people, and I'd like to see it reflected in the User's guide. Of course, I'm aware that such a quick test is no substitute to real tests and explorations. Feel free to reach to me for further information, test cases, etc ... Sincerely yours, Emmanuel Charpentier PS : I'm not on this list. Please Cc: me if you wishme to react to your answers. PPS : Setup : Debian (unstable), 2.4.21 kernel, Wine 20031212 as packaged in Debian, Win98SE (french), "fake windows" setup, using native stdole.tlb, ole32.dll, oleaut32.dll, rpcrt4.dll and, of course, odbc32.dll, MS Office 97 (installed without a hitch from the CD, except for a "Can't DDE connect to desktop" error in the setup, ignored) + SR1 parch. I have had success with SR2b, but this needs a lot more native DLLs, and I can't recall them at the moment (work machine). -- Emmanuel Charpentier

2 1

Re: Janitorial: Get rid of W->A calls for shlexec [RESEND]
by Marcelo Duarte 15 Jan '04

15 Jan '04

Why my patch was not applied? If it will be because it conflicts with the patches of the ROS, can leave that in the next weekend I intend to make this, thus diminishes the work of them. But necessary to know if my patch it goes to be accepted, if I do not go to be losing my time. Thank you. Em Sáb 10 Jan 2004 04:51, Marcelo Duarte escreveu: > Updated with the lastest cvs. > > Changelog: > Marcelo Duarte <wine-devel(a)bol.com.br> > -Janitorial: Get rid of W->A calls for shlexec > -Implementation of FindExecutableW -- Marcelo Duarte

1 0

Re: Solaris specific configuration
by Alexandre Julliard 15 Jan '04

15 Jan '04

Robert Lunnon <bobl(a)optushome.com.au> writes: > Changelog > Autodetection of XFREE86 as required for Solaris. This should be done in configure, assuming it is really necessary. Why can't we use the standard Xlib? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: ifenum.c mtu acquisition - Solaris
by Dimitrie O. Paun 15 Jan '04

15 Jan '04

On January 13, 2004 09:46 pm, Robert Lunnon wrote: > +#if !defined sun > *mtu = ifr.ifr_mtu; > +#else > + *mtu=ifr.ifr_metric; > + #endif The #endif is not properly indented, any special reason? -- Dimi.

2 1

comctl32/imagelist -> ImageList_Remove problem
by hatky 15 Jan '04

15 Jan '04

I run a free program call The All-seeing Eye, available for free at: http://www.udpsoft.com/eye2/index.html And run into a few errors like this: err:imagelist:ImageList_Remove index out of range! 0 ImageList_Remove gets( HIMAGELIST himl, int i) line 2040 of imagelist.c says: if ((i < -1) || (i >= himl->cCurImage)) { ERR("index out of range! %d\n", i); return FALSE; } But since "When an image is removed, the indexes of the remaining images are adjusted so that the ...." I assume most call do not include an index but only the handle as the case with this program from the trace I checked it sends 0 as the i and a true handle in himl and it makes since, since it first calls ImageList_Create to add images and ImageList_Create returns "Handle to the created image list" and not the place (remember the place changes anyway....) So..... I assume that in the case of the i = 0 the procedure should locate the i itself from the handle, am I right? getting close to his first patch :), Hatky. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 1

Will function advapi32.dll.RegOpenUserClassesRoot will be implemented?
by MediaHost (TM) 14 Jan '04

14 Jan '04

Hi, Is there a chance, that function advapi32.dll.RegOpenUserClassesRoot will be implemented? As I can see, most up 2 date software of Micro$oft (Explorer etc.) is using this function and can not run on a W2K environment. Any suggestions? Regards Signer: Eddy Nigg Company: StartCom Group at http://www.startcom.org MediaHostT at http://www.mediahost.org --- StartCom Ltd. http://www.startcom.org Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/10/2004

3 3

strange warning message when buildint current cvs
by Ivan Leo Murray-Smith 14 Jan '04

14 Jan '04

With current cvs, I get this strange warning message make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winetest' cp ../../dlls/advapi32/tests/advapi32_test.exe.so advapi32_test.exe.so && strip -s advapi32_test.exe.so cp ../../dlls/gdi/tests/gdi32_test.exe.so gdi32_test.exe.so && strip -s gdi32_test.exe.so cp ../../dlls/kernel/tests/kernel32_test.exe.so kernel32_test.exe.so && strip -s kernel32_test.exe.so cp ../../dlls/ntdll/tests/ntdll_test.exe.so ntdll_test.exe.so && strip -s ntdll_test.exe.so cp ../../dlls/user/tests/user32_test.exe.so user32_test.exe.so && strip -s user32_test.exe.so cp ../../dlls/winmm/tests/winmm_test.exe.so winmm_test.exe.so && strip -s winmm_test.exe.so cp ../../dlls/winspool/tests/winspool.drv_test.exe.so winspool.drv_test.exe.so && strip -s winspool.drv_test.exe.so LD_LIBRARY_PATH="../../libs/unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -fowinetest.res winetest.rc ../../tools/winebuild/winebuild -D_REENTRANT -fPIC -o winetest.exe.spec.c --exe winetest.exe --exe-mode gui winetest.res main.o send.o util.o winetest.exe.dbg.o -L../../dlls -luser32 -lwsock32 gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o winetest.exe.spec.o winetest.exe.spec.c {standard input}: Assembler messages: {standard input}:856275: Warning: .stabs: description field '1a385' too big, try a different debug format {standard input}:856278: Warning: .stabs: description field '1a38c' too big, try a different debug format {standard input}:856281: Warning: .stabn: description field '1a38c' too big, try a different debug format {standard input}:856287: Warning: .stabn: description field '1a38f' too big, try a different debug format {standard input}:856291: Warning: .stabn: description field '1a38c' too big, try a different debug format {standard input}:856299: Warning: .stabn: description field '1a38e' too big, try a different debug format {standard input}:856302: Warning: .stabn: description field '1a38f' too big, try a different debug format {standard input}:856305: Warning: .stabn: description field '1a38e' too big, try a different debug format {standard input}:856308: Warning: .stabn: description field '1a390' too big, try a different debug format {standard input}:856316: Warning: .stabn: description field '1a393' too big, try a different debug format {standard input}:856321: Warning: .stabn: description field '1a397' too big, try a different debug format {standard input}:856324: Warning: .stabn: description field '1a398' too big, try a different debug format {standard input}:856331: Warning: .stabn: description field '1a391' too big, try a different debug format {standard input}:856344: Warning: .stabn: description field '1a392' too big, try a different debug format {standard input}:856349: Warning: .stabn: description field '1a398' too big, try a different debug format {standard input}:856357: Warning: .stabn: description field '1a39a' too big, try a different debug format {standard input}:856378: Warning: .stabn: description field '1a39b' too big, try a different debug format {standard input}:856383: Warning: .stabn: description field '1a39c' too big, try a different debug format {standard input}:856389: Warning: .stabn: description field '1a39d' too big, try a different debug format {standard input}:856401: Warning: .stabn: description field '1a39e' too big, try a different debug format {standard input}:856413: Warning: .stabn: description field '1a39f' too big, try a different debug format {standard input}:856416: Warning: .stabn: description field '1a3a0' too big, try a different debug format {standard input}:856420: Warning: .stabn: description field '1a3a1' too big, try a different debug format {standard input}:856428: Warning: .stabn: description field '1a394' too big, try a different debug format {standard input}:856442: Warning: .stabs: description field '1a38d' too big, try a different debug format {standard input}:856443: Warning: .stabs: description field '1a38e' too big, try a different debug format {standard input}:856444: Warning: .stabs: description field '1a38f' too big, try a different debug format {standard input}:856445: Warning: .stabs: description field '1a38f' too big, try a different debug format {standard input}:856446: Warning: .stabs: description field '1a38f' too big, try a different debug format {standard input}:856509: Warning: .stabs: description field '1a3f3' too big, try a different debug format {standard input}:856513: Warning: .stabn: description field '1a3f3' too big, try a different debug format {standard input}:856522: Warning: .stabn: description field '1a3f5' too big, try a different debug format {standard input}:856530: Warning: .stabn: description field '1a3f6' too big, try a different debug format {standard input}:856548: Warning: .stabs: description field '1168a' too big, try a different debug format {standard input}:856549: Warning: .stabs: description field '12078' too big, try a different debug format {standard input}:856550: Warning: .stabs: description field '12fff' too big, try a different debug format {standard input}:856551: Warning: .stabs: description field '13f10' too big, try a different debug format {standard input}:856552: Warning: .stabs: description field '148d9' too big, try a different debug format {standard input}:856553: Warning: .stabs: description field '17277' too big, try a different debug format {standard input}:856554: Warning: .stabs: description field '181cf' too big, try a different debug format {standard input}:856555: Warning: .stabs: description field '18d39' too big, try a different debug format {standard input}:856556: Warning: .stabs: description field '19709' too big, try a different debug format {standard input}:856557: Warning: .stabs: description field '1a290' too big, try a different debug format {standard input}:856558: Warning: .stabs: description field '1a2a8' too big, try a different debug format {standard input}:856559: Warning: .stabs: description field '1a2f2' too big, try a different debug format {standard input}:856560: Warning: .stabs: description field '1a3cf' too big, try a different debug format gcc -shared -Wl,-Bsymbolic,-z,defs,-init,__wine_spec_init,-fini,__wine_spec_fini winetest.exe.spec.o main.o send.o util.o winetest.exe.dbg.o -o winetest.exe.so -L../../libs/wine -lwine -L../../libs/port -lwine_port -lm -lc make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winetest' make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winevdm' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winevdm' make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winhelp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winhelp' make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winver' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winver' make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs' make[1]: Entering directory `/home/ivan/Development/Wine/CVS/wine/server' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/server' Wine build complete. I've tried make distclean and I still get it. I'm using gcc 3.3.1-2mdk, does this classify as something that should be fixed? Ivan.

2 1

Re: PATCH: Port Tim Ferguson's ICCVID codec to Wine
by Dmitry Timoshkov 14 Jan '04

14 Jan '04

"Mike McCormack" <mike(a)codeweavers.com> wrote: > ChangeLog: > Tim Ferguson <Tim.Ferguson(a)infotech.monash.edu.au> > Mike McCormack <mike(a)codeweavers.com> > * Port Tim Ferguson's ICCVID codec to Wine Mike, could you put the iccvid sources at the same place as msrle32 (dlls/msvideo) and resend the patch? -- Dmitry.

4 4

Shell32 Patch 1.1
by Steven Edwards 14 Jan '04

14 Jan '04

This patch replaces the prior patch. The ReactOS changelog wasnt very good and Martin pointed out that I missed the spec file. Changelog: "Martin Fuchs" <martin-fuchs(a)gmx.net> Implement RestartDialog and RestartDialogEx __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

1 0

Re: More Vacation backlog
by Hans Leidekker 14 Jan '04

14 Jan '04

On Tuesday 13 January 2004 23:57, Uwe Bonnes wrote: > +HANDLE DEVICE_Open( LPCWSTR filenameW, DWORD access, DWORD attributes, LPSECURITY_ATTRIBUTES sa ) > { > const struct VxDInfo *info; > char filename[MAX_PATH]; > @@ -283,7 +283,7 @@ > > for (info = VxDList; info->name; info++) > if (!strncasecmp( info->name, filename, strlen(info->name) )) > - return FILE_CreateDevice( info->id | 0x10000, access, sa ); > + return FILE_CreateDevice( info->id | 0x10000, access, access, sa ); ^^^^^^ I think you want to pass 'attributes' here, right? -Hans

1 0

listview and LVS_OWNERDATA problems update
by Dan Kegel 14 Jan '04

14 Jan '04

I just revisited http://bugs.winehq.org/show_bug.cgi?id=1268 and found that things are improved, but not fully working; there is corruption to the left of column 1 in the demo app. I have not yet rechecked http://bugs.winehq.org/show_bug.cgi?id=1404 to see how well that demo app is doing. - Dan

1 0

wwn #110 ??
by Tom 14 Jan '04

14 Jan '04

If I look at WWN #110 on winehq.org I get this http://www.winehq.org/?issue=110 If I look at 110 at : http://kt.zork.net/wine/wn20011212_110.html it is almost toatly different!! Do I need to start reading both sites each week? And I guess ill send a patch to fix this as there is alot of good crap here to read! :) Tom

1 0

Oleaut32 tests fail
by Sylvain Petreolle 14 Jan '04

14 Jan '04

Running the oleaut32 tests shows that vartype and vartest are failing. The 25 tests that fail are returning DISP_E_TYPEMISMATCH (0x80020005) Has someone an idea about these ? vartest.c:2653:======== Testing different VARTYPES ======== fixme:ole:VarParseNumFromStr dwInFlags & NUMPRS_HEX_OCT not yet implemented! vartest.c:2680: Test failed: 14: vt 83, return value 80020005, expected was 0 ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Re: slight trouble running winetests under windows
by chmorgan＠charter.net 14 Jan '04

14 Jan '04

Ahh yes, this appears to be the issue. If I go to "project settings->link->object/library modules" and add "uuid.lib" to the list then the test compiles without many other issues. Shouldn't the script be adding this to the .dsp/.dsw? I'm having great troubles compiling the test against vs6 header files as well, should I upgrade to the latest platform sdk? The wine headers work pretty well except for errors from the compiler about not being able to convert __uint64 to double. Chris > > From: Hans Leidekker <hans(a)it.vu.nl> > Date: 2004/01/13 Tue AM 05:20:29 EST > To: wine-devel <wine-devel(a)winehq.com> > CC: Chris Morgan <cmorgan(a)alum.WPI.EDU> > Subject: Re: slight trouble running winetests under windows > > On Tuesday 13 January 2004 05:47, Chris Morgan wrote: > > > I'm trying to get some of the wine tests compiling and running under > > windows, oleaut32 test specifically. I've got the project file built and > > everything opens fine under visual studio 6. The only issue is that during > > linking of the oleaut32 tests _IID_IFont is undefined. Oddly enough if I > > I get these linking errors too when compiling with MinGW. I solve > these by manually adding -luuid. The dsound test needs -luuid and > -ldxguid to link. There has been some discussion in the past as to > how to solve this. I proposed a number of changes to Wine's build > system to fix this but they were rejected. > > Let's see if I can sum up the issues. In Wine uuids are put in > a lib called libwine_uuid. It's called like that because a > libuuid already exists. Second thing is that in MinGW and MSVC > there are two separate libraries with uuids, uuid and dxguid, > whereas in Wine they're all in one. > > -Hans > >

3 2

Re: Implement LockWindowUpdate [take 2]
by Alexandre Julliard 14 Jan '04

14 Jan '04

Mike Hearn <mike(a)theoretic.com> writes: > The other reason it might have bounced is if we're not allowed to extend > WND, though as it's purely internal and not accessible from the APIs that > should be OK? I'm not sure how to do this otherwise without exporting the > currently locked window variable from USER to X11DRV which probably breaks > dll separation. Either that, or adding a new driver procedure. Extending the WND structure is OK (though it doesn't seem necessary in that case), but accessing it from x11drv is a violation of dll separation. We still do that in a number of places but they will have to be fixed, so we probably shouldn't add new ones. -- Alexandre Julliard julliard(a)winehq.com

2 2

Cdrom driver
by Robert Lunnon 13 Jan '04

13 Jan '04

I have just finished embelishing the cdrom driver to support solaris but I have nothing to test it against. Can anyone recommend a good test program for excercising CDROM ioctls ? Thanks Bob

2 1

Re: Solaris compile time fixes for CVS wine
by Dimitrie O. Paun 13 Jan '04

13 Jan '04

On January 8, 2004 01:22 am, Robert Lunnon wrote: > Here are a buch of Solais compatibility patches for wine (Some but not all > of them). Within the enclosed tarball the diffs are structured according to > the wine cvs tree. There is a readme file accompanying each diff to explain > what the change is. Please break the archive into one patch per message, not compressed (preferably inlined). Here are a few pointers on how to send patches: http://www.winehq.org/site/sending_patches BTW, what's the status of building Wine under Solaris? What architecture (i386, etc) are you using? -- Dimi.

4 3

Re: [Bug 521] WINE removes trailing backslash in GetFullPathNameA/W in dos_fs.c.
by Eric Pouech 13 Jan '04

13 Jan '04

Mike McCormack a écrit : > > This closes bug 521, and removes a couple of wine_todos from the > regression test for pathes. The test for setting "lastpart" in both > GetFullPathNameA/W was wrong (would always pass). for the record, I also sent a patch regarding (among other things) this issue, which also has never been applied. I don't know Alexandre's state on this. A+

2 3

WWN Links are busted
by Tom 13 Jan '04

13 Jan '04

Hi, If you try to go to a WWN article from the status page's they don't work. example : Wine's fundamental architecture #154 = http://www.winehq.com/site/status_wine?issue=154#Kernel%20Module%20/%20Shar… the current link is: <a href="?issue=154#Kernel%20Module%20/%20Shared%20Memory%20Revisited">#154</a></td> when I think it should be: <a href="{$root}/site/?issue=154#Kernel%20Module%20/%20Shared%20Memory%20Revisited">#154</a></td> Jeremey N is this correct? If so I can fix all the links in the next day or so.. Tom

2 1

Re: WWN Links are busted
by Brian Vincent (C) 13 Jan '04

13 Jan '04

> the current link is: > <a > href="?issue=154#Kernel%20Module%20/%20Shared%20Memory%20Revisited">#154</a> </td> I think it should be: href="/?issue=154#Kernel%20Module%20/%20Shared%20Memory%20Revisited" sed -e "s/href=\"\?/href=\"\/\?/g" --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

1 0

Re: shell32 patches to be usable by ReactOS Explorer
by Alexandre Julliard 13 Jan '04

13 Jan '04

"Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > This was no joke. If you say, you would accept such as reformating patch, > I can easyly create one that eliminates all tab-characters, and generates > nice and uniform indented code. > This will make it a bit easier to create the small self-contained patches > you want to see instead of the big one. As additional bonus you will get > a very better formated shell32 code base. There's no reason to reformat all of shell32. If a given function is messed up you can fix it (in a separate patch), but otherwise it doesn't really matter if all functions don't use the exact same style. -- Alexandre Julliard julliard(a)winehq.com

2 1

stray file
by Hans Leidekker 13 Jan '04

13 Jan '04

Hi, There's a stray file, dlls/checklink.c, in Wine CVS with these contents: int main(void) { return 0; } It must be a leftover from a configure run. I suspected my own tree but but it came back after I removed it and did a cvs update. -Hans

4 4

Re: uxtheme: lots of infrastructure
by Alexandre Julliard 13 Jan '04

13 Jan '04

Kevin Koltzau <kevin(a)plop.org> writes: > This is a ton of infrastructure for my future patches, and a full > implementation of GetThemeDocumentationProperty which I primarilly > used to test my INI file processing, and its now possible to set the > current theme through the API..not that its much use to do that yet The part about storing the string maps as resources seems unnecessarily complicated and inefficient. Why can't you store an array directly in the code? -- Alexandre Julliard julliard(a)winehq.com

2 4

[Janitorial] Remove CopyMetaFileW->A call
by Vincent Béron 13 Jan '04

13 Jan '04

Indentation in CopyMetaFileW is a bit inconsistent (there are some tabs which I left since I didn't touch those lines). Should I redo my patch to get rid of them (adds some noise to the patch), keep them in a separate patch (limited to this very function) or leave it as is? Also, should I change MF_CreateMetaHeaderDisk to accept a LPCWSTR, even though it then needs to convert it back to Ascii, or is the proposed way sufficient? Changelog: Removed a W->A cross-call (CopyMetaFileW->CopyMetaFileA). Vincent

1 0

Re: Implemention of LockWindowUpdate
by Mike Hearn 13 Jan '04

13 Jan '04

On Tue, 13 Jan 2004 00:10:20 +0000, Mike Hearn wrote: > This patch makes the halflife menu screen look a bit better, with less > flashing. Unfortunately it also makes it feel a bit slower, but I think > that's just an optical illusion caused by less screen activity. The > bottleneck is elsewhere. Just had a hunch, and yes, switching off XRender and antialiasing speeds things up nicely. I guess I should yell at keithp or something.... :)

1 0

Re: wine/ windows/scroll.c include/user.h dlls/x11 ...
by Dimitrie O. Paun 12 Jan '04

12 Jan '04

On Mon, 12 Jan 2004, Alexandre Julliard wrote: > Log message: > ScrollDC doesn't need to be in the graphics driver. Yay! (I submitted a similar patch some time ago, but you didn't like the {Start,End}GraphicsExposures functions. I still think they are decent GUI abstractions :)): http://www.winehq.com/hypermail/wine-patches/2002/09/0196.html Speaking of these things, I also don't think the driver should know about the caret. I see no need for the USER driver to know anything about the caret, we can just always implement it ourselves, no? http://www.winehq.com/hypermail/wine-patches/2002/09/0174.html I think there is a bug in the above patch (IIRC, I used to get some freezing in certain situations), but the idea still stands. -- Dimi.

2 1

Re: [WINEALSA] Add Midi IN support (take 3)
by Alexandre Julliard 12 Jan '04

12 Jan '04

Christian Costa <titan.costa(a)wanadoo.fr> writes: > +static int npfd; > +static int pfd_array_size = 0; > +static struct pollfd *pfd = NULL; This isn't thread-safe. Why don't you simply allocate the array in the function and free it when you are done? -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: shell32 patches to be usable by ReactOS Explorer
by Martin Fuchs 12 Jan '04

12 Jan '04

On 12.01.2004 01:41:45 Alexandre Julliard wrote: > "Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > > > Mhh - could you please tell me which "ugly hacks" you are speaking of? > > From a quick look at the patch, what I noticed is mostly the ifdefs > and other various disabling/commenting out of parts of the code. We had to disable some calls to internal functions, which are only exported from WINE, no real Windows OS. > There are also a number of unneeded whitespace changes that make the > patch larger than it should be. Yes, I tried to make some functions I had to alter a bit more readable. What about running a pretty printer, for example astyle (http://astyle.sourceforge.net/) on the whole code (or at least the shell32 directory) ? Some sections are currently indented with 2, some with 4 and some with 8 spaces - even mixed in the same function. Regards, Martin

1 1

Re: [Janitorial] ResetDCA->ResetDCW
by Dmitry Timoshkov 12 Jan '04

12 Jan '04

"Vincent Beron" <vberon(a)mecano.gme.usherb.ca> wrote: > Changelog: > Get rid of a W->A crosscall (ResetDCA->ResetDCW). > -HDC WINAPI ResetDCW( HDC hdc, const DEVMODEW *devmode ) > +HDC WINAPI ResetDCA( HDC hdc, const DEVMODEA *devmode ) > { > - return ResetDCA(hdc, (const DEVMODEA*)devmode); /* FIXME */ > + DEVMODEW *devmodeW; > + HDC ret; > + > + if (devmode) devmodeW = GdiConvertToDevmodeW(devmode); > + else devmodeW = NULL; > + > + ret = ResetDCW(hdc, (const DEVMODEW*)devmode); It would be better to pass a real, newly allocated DEVMODEW* to ResetDCW(). That way you shouldn't need to cast type of a pointer. -- Dmitry.

2 1

Re: #2 - Mdi Win16/32 Split
by Dimitrie O. Paun 12 Jan '04

12 Jan '04

On January 2, 2004 10:31 am, Steven Edwards wrote: > Split up the Win16/32 MDI support a bit. Any idea what the status of the Win16/32 split is? What DLLs are still not properly split? -- Dimi.

4 11

Re: shell32 patches to be usable by ReactOS Explorer
by Dimitrie O. Paun 12 Jan '04

12 Jan '04

On January 11, 2004 08:04 am, Martin Fuchs wrote: > This patch consists of a number of changes we implemented in the ReactOS > CVS tree in order to use Wine's shell32.dll implementation for ReactOS > explorer. Please see the following changelog lists for the individual patch > descriptions: Martin, sending a bunch of patches compressed and in one message, makes them almost unreviewable but by the most die hards readers of wine-patches. It also makes it so much more difficult for Alexandre to split them up, match the ChangeLog, review them, etc. Please stick to one-(uncompressed, inlined)-patch-per-email-messsage rule, it's so much better for everybody. Here are some relevant links: http://www.winehq.org/site/sending_patches http://www.winehq.org/site/docs/wine-devel/patches -- Dimi.

4 6

Re: [Janitorial] ResetDCA->ResetDCW
by Dimitrie O. Paun 12 Jan '04

12 Jan '04

On January 11, 2004 03:43 pm, Vincent Béron wrote: > Dimi, do you prefer to keep track of progress on this yourself, or > should I send a patch for the janitorial page too? It would be great if you'd send the update to the janitorial page. I try to keep track, but it's so much easier if patch authors lend a hand. But please wait until Alexandre commits it. -- Dimi.

1 0

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)
by Ivan Leo Murray-Smith 11 Jan '04

11 Jan '04

> With this change, we can use the 6.3 version of Quicktime > to see streamed video from Wineconf... This would break Grand Prix Legends and Nascar 2002 (Thats why the patch was written in the first place), maybe you should contact the author of the patch, a proper fix would be better, why should we chose between 2 games and quicktime? It should be possible to run all these apps. Ivan.

4 4

Re: [WINEALSA] Add Midi IN support (w/o alloca)
by Eric Pouech 11 Jan '04

11 Jan '04

Christian Costa a écrit : > + for (wDevID = 0; wDevID < MIDM_NumDevs; wDevID++) > + if ( (ev->source.client == MidiInDev[wDevID].addr.client) && (ev->source.client == MidiInDev[wDevID].addr.client) ) > + break; Why do you do twice the same test ? A+

2 1

exception outside of stack limits
by Robert Lunnon 11 Jan '04

11 Jan '04

There is a warning in signal_i368.c WARN( "exception outside of stack limits in thread %04lx eip %08lx esp %08lx stack %p-%p\n", GetCurrentThreadId(), EIP_sig(sigcontext), Can anyone tell me what this "means" in terms of what would have to go wrong to generate this warning ??

2 2

Correction to wineps spec file
by Vincent Béron 11 Jan '04

11 Jan '04

Changelog: CreateDC in wineps is Unicode now, change the spec file accordingly. Vincent

1 0

Re: [WINEALSA] Add Midi IN support
by Alexandre Julliard 11 Jan '04

11 Jan '04

Christian Costa <titan.costa(a)wanadoo.fr> writes: > + int npfd; > + struct pollfd *pfd; > + > + npfd = snd_seq_poll_descriptors_count(midiSeq, POLLIN); > + pfd = (struct pollfd *)alloca(npfd * sizeof(struct pollfd)); You should not use alloca in Wine, it's not portable enough. -- Alexandre Julliard julliard(a)winehq.com

4 3

Direct3D8 - OpenGL header problem
by Thomas Brix Larsen 11 Jan '04

11 Jan '04

Hi list, just upgraded to 2.6.0 and the NVIDIA driver from minion.de and now I get this error when compiling wine: directx.c: In function `IDirect3D8Impl_GetDeviceCaps': directx.c:639: `GL_MAX_VERTEX_UNITS_ARB' undeclared (first use in this function) My X11/include/GL/ headers date, 2001-2002. Greetings, --Thomas _________________ My worst enemy gave me a copy of Windows...

3 2

Re: shell32 patches to be usable by ReactOS Explorer
by Martin Fuchs 11 Jan '04

11 Jan '04

Sorry, I forgot to include the new file "shlcpanel.c" into the shell32 patch mail. Changelog: - Implementation of control panel folder in shgell namespace -- Martin Fuchs martin-fuchs(a)gmx.net

1 0

Build fails for current CVS update
by Sami Aario 11 Jan '04

11 Jan '04

Hi, Building with tools/wineinstall fails with the latest CVS update on my system with the following: gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINE SRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-stri ct-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ddraw.spec.o ddraw.spec.c {standard input}: Assembler messages: {standard input}:654: Error: no such instruction: `yes "ddraw.dll"' {standard input}:655: Error: no such instruction: `yes "DDHAL32_VidMemAlloc"' {standard input}:656: Error: no such instruction: `yes "DDHAL32_VidMemFree"' {standard input}:657: Error: no such instruction: `yes "DDInternalLock"' and so on, lots more of the same. Anyone else getting these?

3 4

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)
by Mike Hearn 11 Jan '04

11 Jan '04

That looks familiar. In fact, the TRACE was originally a FIXME but it caused so much spew with so many apps I changed it. I couldn't see exactly what needed to be fixed given the contents of the message - it seems to be simply informing us of progress, but it's a possibility somebody knew this wasn't correct. On Sat, 10 Jan 2004 17:09:52 -0600, Jeremy White wrote: > Index: dlls/winsock/socket.c > =================================================================== > RCS file: /home/wine/wine/dlls/winsock/socket.c,v > retrieving revision 1.144 > diff -u -r1.144 socket.c > --- dlls/winsock/socket.c 2 Jan 2004 20:12:00 -0000 1.144 > +++ dlls/winsock/socket.c 10 Jan 2004 22:56:57 -0000 > @@ -1302,10 +1302,6 @@ > else > { > int on = 1; > - /* The game GrandPrixLegends binds more than one time, > but does > - * not do a SO_REUSEADDR - Stevens says this is ok */ > - TRACE( "Setting WS_SO_REUSEADDR on socket before we > bind it\n"); > - WS_setsockopt( s, WS_SOL_SOCKET, WS_SO_REUSEADDR, > (char*)&on, sizeof(on) ); > > if (bind(fd, uaddr, uaddrlen) < 0) > {

2 1

bogus patch to bind() dlls/winsock/socket.c (request removal)
by Jeremy Shaw 10 Jan '04

10 Jan '04

As a result of this patch (which is currently applied in cvs head): http://www.winehq.com/hypermail/wine-patches/2002/12/0009.html WS_bind() currently does this before every call to bind(): WS_setsockopt( s, WS_SOL_SOCKET, WS_SO_REUSEADDR, (char*)&on, sizeof(on) ); Basically, it sets SO_REUSEADDR for every call to WS_bind(). I can't imagine this is the correct thing to do. According to MSDN, bind() should fail unless the program has explicitly set SO_REUSEADDR. See Error code WSAEADDRINUSE at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/wi… I found that this patch causes major problems with the xten sipphone client. The xten client does not explicitly set SO_REUSEADDR and depends on bind() failing if it tries to bind to the same local address/port twice. When the sipphone client needs a socket, it starts at port 8000, and calls bind() on successive ports until bind() returns success. So normally, if the program is already using port 8000, then bind() will fail and will try port 8001. However, with the above patch in place, bind() always works. So then the sipphone client will be using port 8000 twice, which the program is not designed to handle. If I remove the call to WS_setsockopt(), the xten sipphone client works correctly. I am proposing that the portion of the patch applied to WS_bind() be removed unless someone has a convincing arguement that the patch is actually valid. Jeremy Shaw.

2 1

WWN broken
by Brian Vincent (C) 10 Jan '04

10 Jan '04

> We scan the XMl with tidy before posting. What is odd is that tidy > reports the XML is valid, but yet PHP's XML parser barfs on it. Whatever > the case, I just patched it, so it should be fixed online soon. Whoops. Sorry about that. I was running out the door when I put it up. I did run it through tidy, but tidy kind of sucks. The only way to really catch things is to run it through xmllint. But xmllint has a terrible interface for finding malformed problems.. hence tidy. Thanks for fixing that. Also, if anyone is bored and wants to do something easy, it might be nice to change all references in the WWN issues from winehq.com to winehq.org. I've just recently switched over to trying to be consistent on the .org thing. There's about 200 issues that could be run through sed. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

2 1

Re: dsound global variable use reduction
by Eric Pouech 10 Jan '04

10 Jan '04

Robert Reif a écrit : > Reduce the use of the dsound global variable by > passing address to functions. This is in preparation > of supporting multiple DirectSound devices. We can't > remove all uses because an mmtimer callback can be > called even after the timer is killed. Windows has an > mmtimer flag that prevents this but wine doesn't > implement it. Could you be more specific on this one ? timeKillEvent is not 100% thread safe (I'll send a patch later on), but timeKillEvent in Wine is always synchronous (ie the killer is killed when timeKillEvent returns).

2 3

Re: shell shortcuts
by Martin Fuchs 10 Jan '04

10 Jan '04

Hello again, I just had a look at some WIN98 shortcut files. They are also in ANSI format, not 16 bit Unicode: 00000000: 4C 00 00 00-01 14 02 00-00 00 00 00-C0 00 00 00 L ☺¶☻ └ 00000010: 00 00 00 46-1B 00 00 00-00 00 00 00-00 3E EA 22 F← >Û" 00000020: 0F 7D BD 01-00 98 32 60-C0 14 C2 01-00 3E EA 22 ☼}¢☺ ÿ2`└¶┬☺ >Û" 00000030: 0F 7D BD 01-00 D0 00 00-00 00 00 00-01 00 00 00 ☼}¢☺ ð ☺ 00000040: 00 00 00 00-00 00 00 00-00 00 00 00-61 00 14 00 a ¶ 00000050: 1F 0F E0 4F-D0 20 EA 3A-69 10 A2 D8-08 00 2B 30 ▼☼ÓOð Û:i►óÏ◘ +0 00000060: 30 9D 19 00-23 43 3A 5C-00 00 00 00-00 00 00 00 0Ø↓ #C:\ 00000070: 00 00 00 00-00 00 00 00-00 51 4D 17-00 31 00 00 QM↨ 1 00000080: 00 00 00 CF-2C 4C 27 10-00 57 49 4E-44 4F 57 53 ¤,L'► WINDOWS 00000090: 00 00 1B 00-32 00 00 D0-00 00 AB 24-20 98 00 00 ← 2 ð ½$ ÿ 000000A0: 4E 4F 54 45-50 41 44 2E-45 58 45 00-00 00 00 67 NOTEPAD.EXE g 000000B0: 00 00 00 1C-00 00 00 03-00 00 00 1C-00 00 00 32 ∟ ♥ ∟ 2 000000C0: 00 00 00 36-00 00 00 53-00 00 00 16-00 00 00 03 6 S ▬ ♥ 000000D0: 00 00 00 07-0D 2B 3E 10-00 00 00 57-49 4E 39 38 •♪+>► WIN98 000000E0: 00 43 3A 5C-00 1D 00 00-00 02 00 00-00 14 00 00 C:\ ↔ ☻ ¶ 000000F0: 00 00 00 00-00 00 00 02-00 5C 5C 4D-56 39 38 5C ☻ \\MV98\ 00000100: 43 00 57 49-4E 44 4F 57-53 5C 4E 4F-54 45 50 41 C WINDOWS\NOTEPA 00000110: 44 2E 45 58-45 00 0E 00-2E 2E 5C 4E-4F 54 45 50 D.EXE ♫ ..\NOTEP 00000120: 41 44 2E 45-58 45 0A 00-43 3A 5C 57-49 4E 44 4F AD.EXE◙ C:\WINDO 00000130: 57 53 00 00-00 00 - - WS -- Martin Fuchs martin-fuchs(a)gmx.net

1 0

Re: shell shorcuts
by Martin Fuchs 10 Jan '04

10 Jan '04

> Hmm..., I KNOW 'SCF_UNICODE' is NOT 0x1000 in the first place, but why do > you say it's 0x80 ? > > Going by the copyrights, Marcus Meissner and Juergen Schmied did the initial > job, and perhaps one of them put this value. > I don't know about Juergen, but I have tremendous faith in Marcus (I use > SuSE you see ;) ), and there MUST have been some reason why 'SCF_UNICODE' > got the value 0x1000, although it seems to be wrong ! I looked into the CVS history logs and found, when SCF_UNC (rev. 1.21) and SCF_UNICODE (rev. 1.54) have been introduced: ---------------------------- revision 1.21 date: 1999/08/15 14:31:36; author: julliard; state: Exp; lines: +23 -15 Juergen Schmied <juergen.schmied(a)metronet.de> More use of rc files for strings and menus, fixes. First internal icons. ---------------------------- revision 1.54 date: 2003/05/21 18:50:53; author: julliard; state: Exp; lines: +701 -846 Mike McCormack <mike(a)codeweavers.com> Remove code that starts wineshelllink, instead create a windows compatible shortcut (*.lnk) file. After creating that file, start a link processor (winemenubuilder) on it, which reads it back then calls wineshelllink. Rework CreateStreamFromFile to create an IStream object that is writeable. ---------------------------- Perhaps we should ask Juergen Schmied and Mike McCormack where they got their defintions from. But I think SCF_UNC = 0x80 is the right one. > Hence, please consolidate your assigning it 0x80 with some examples/hexedits > so that I can answer when I get grilled ;) OK, you want to see some hex dumps. Here ist one for notepad.exe on WIN95: (sorry for the likely unreadable formating) 00000000: 4C 00 00 00-01 14 02 00-00 00 00 00-C0 00 00 00 L ?¶? ? 00000010: 00 00 00 46-0B 00 00 00-20 00 00 00-00 92 6A 89 F? Æjë 00000020: 12 9B BB 01-00 58 E5 4E-04 D7 C3 01-00 92 6A 89 ?ø?? XÕN?Î?? Æjë 00000030: 12 9B BB 01-00 8A 00 00-00 00 00 00-01 00 00 00 ?ø?? è ? 00000040: 00 00 00 00-00 00 00 00-00 00 00 00-5F 00 14 00 _ ¶ 00000050: 1F 00 E0 4F-D0 20 EA 3A-69 10 A2 D8-08 00 2B 30 ? ÓOð Û:i?óÏ? +0 00000060: 30 9D 19 00-23 43 3A 5C-00 00 00 00-00 00 00 00 0Ø? #C:\ 00000070: 00 00 00 00-00 00 00 00-00 F1 8A 15-00 31 00 00 ±è§ 1 00000080: 00 00 00 2A-30 9D 64 10-80 57 69 6E-39 35 00 00 *0Ød?ÇWin95 00000090: 1B 00 32 00-00 8A 00 00-25 21 60 59-20 80 4E 6F ? 2 è %!`Y ÇNo 000000A0: 74 65 70 61-64 2E 65 78-65 00 00 00-00 48 00 00 tepad.exe H 000000B0: 00 1C 00 00-00 01 00 00-00 1C 00 00-00 32 00 00 ? ? ? 2 000000C0: 00 00 00 00-31 47 00 00-00 16 00 00-00 03 00 00 1G ? ? 000000D0: 00 04 13 5F-37 10 00 00-00 57 49 4E-39 35 00 43 ??_7? WIN95 C 000000E0: 3A 5C 57 49-4E 39 35 5C-4E 4F 54 45-50 41 44 2E :\WIN95\NOTEPAD. 000000F0: 45 58 45 00-00 0E 00 2E-2E 5C 4E 4F-54 45 50 41 EXE ? ..\NOTEPA 00000100: 44 2E 45 58-45 - - D.EXE Here is the dump of a XP shourtcut file: 00000000: 4C 00 00 00-01 14 02 00-00 00 00 00-C0 00 00 00 L ?¶? ? 00000010: 00 00 00 46-9B 02 00 00-80 00 00 00-A0 A6 B2 00 Fø? Ç áª? 00000020: 9B C8 C3 01-76 98 AB AD-7D D7 C3 01-00 C8 2F B0 ø???vÿ½¡}Î?? ?/? 00000030: E5 27 C1 01-00 02 01 00-00 00 00 00-01 00 00 00 Õ'?? ?? ? 00000040: 00 00 00 00-00 00 00 00-00 00 00 00-F3 00 14 00 ¾ ¶ 00000050: 1F 50 E0 4F-D0 20 EA 3A-69 10 A2 D8-08 00 2B 30 ?PÓOð Û:i?óÏ? +0 00000060: 30 9D 19 00-2F 45 3A 5C-00 00 00 00-00 00 00 00 0Ø? /E:\ 00000070: 00 00 00 00-00 00 00 00-00 00 00 3C-00 31 00 00 < 1 00000080: 00 00 00 21-30 DC 73 10-00 57 49 4E-44 4F 57 53 !0?s? WINDOWS 00000090: 00 26 00 03-00 04 00 EF-BE 3C 2D 98-18 2A 30 11 & ? ? ´¥<-ÿ?*0? 000000A0: 6A 14 00 00-00 57 00 49-00 4E 00 44-00 4F 00 57 j¶ W I N D O W 000000B0: 00 53 00 00-00 16 00 40-00 31 00 00-00 00 00 25 S ? @ 1 % 000000C0: 30 47 BE 10-00 73 79 73-74 65 6D 33-32 00 00 28 0G¥? system32 ( 000000D0: 00 03 00 04-00 EF BE 3C-2D 98 18 2A-30 11 6A 14 ? ? ´¥<-ÿ?*0?j¶ 000000E0: 00 00 00 73-00 79 00 73-00 74 00 65-00 6D 00 33 s y s t e m 3 000000F0: 00 32 00 00-00 18 00 48-00 32 00 00-02 01 00 12 2 ? H 2 ?? ? 00000100: 2B 00 68 80-00 6E 6F 74-65 70 61 64-2E 65 78 65 + hÇ notepad.exe 00000110: 00 2E 00 03-00 04 00 EF-BE 96 2F 5C-76 2A 30 99 . ? ? ´¥û/\v*0Ö 00000120: 6B 14 00 00-00 6E 00 6F-00 74 00 65-00 70 00 61 k¶ n o t e p a 00000130: 00 64 00 2E-00 65 00 78-00 65 00 00-00 1A 00 00 d . e x e ? 00000140: 00 54 00 00-00 1C 00 00-00 01 00 00-00 1C 00 00 T ? ? ? 00000150: 00 33 00 00-00 00 00 00-00 53 00 00-00 17 00 00 3 S ? 00000160: 00 03 00 00-00 04 5D C9-28 10 00 00-00 53 79 73 ? ?]?(? Sys ... (snipped here) Look at the dword from 0x0014 to 0x0017. It is 0xB ("0B 00 00 00") for WIN95 and 0x29B ("9B 02 00 00") for XP. Please don't ask me for the meanging of this 0x200 - I just don't know it. But believe me - this bit with value 0x80 has been zero in any WIN95 created .lnk file I saw. And it has been set in all .lnk files of XP. As you know, WIN95 uses ANSI strings and XP uses UTF16 strings. Bit "0x1000" was never set in any OS's shortcut files. If you double-click a WIN95-link on XP it also works. You can even edit its properties. When saving it using XP, it get overwritten with the new format. The bit in question is now set! However Windows itself seems to ignore the bit when reading shortcut files. It can successfully read them regardless of me having changed the bit before. This is some kind of "file recovery" if you ask me. > However, I think that we should ALL handle strings as Unicode internally, > and convert to ANSI when required, and NOT the other way round. > Hence, we will be compatible with Win98/ME/2K/XP, as that's what M$ does... > If you see my code carefully, you will notice that EVERYTHING is handled as > Unicode internally. Of course. Shell link objects in memory should store the strings in Unicode format. > The flag 'SCF_UNICODE' is used to test the bit mask and determine if the > .lnk is serialized in Unicode or not... > I am pretty sure that Windows >95 handle EVERYTHING in Unicode, and thus a > wrong value of 'SCF_UNICODE' will ONLY mess up Win95 .lnk files ! > > If you can consolidate your defining 'SCF_UNICODE' as 0x80, I will ONLY be > too happy to incorporate that, else those still using Win95 (?) may suffer, > as Win95 handles strings as ANSI and not Unicode... Regards, Martin

1 0

Key signing party at wineconf
by Shachar Shemesh 09 Jan '04

09 Jan '04

Hi all, I'm organizing a key signing party at wineconf. Anyone who wishes to participate, please email me the following details: Your full, real, name. It is not possible to participate in a key signing party using a nickname or a virtual identity. Sorry. Your key's fingerprint. Your actual key. Again, the key must have your real name on it (I am talking public key, of course. You should never send your private key to anyone). I am going to compile the list of names into a keyring and post it to a public key server. If, for any reason, you wish your key to remain unpublished (highly unrecommended), please note so in your mail. For more info about GPG key signing parties, check out the howto at http://www.cryptnet.net/fdp/crypto/gpg-party.html Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/

1 0

Compilation broken in CVS
by Paul Millar 09 Jan '04

09 Jan '04

Hi everyone, Looks like one of the patches broke compiling last night: http://www.astro.gla.ac.uk/users/paulm/WRT/buildinfo.php?id=472 I get error messages like: gcc -shared -Wl,-Bsymbolic,-z,defs,-init,__wine_spec_init,-fini,__wine_spec_fini winearts.drv.spec.o arts.o audio.o winearts.drv.dbg.o -o winearts.drv.so -L../../../libs/wine -lwine -L/usr/lib -ldl -lartsc -lpthread -L../../../libs/uuid -lwine_uuid -L../../../libs/port -lwine_port -lm -lc audio.o: In function `wodPlayer_WriteMaxFrags': /scratch/lilith1/paulm/wine/dlls/winmm/winearts/audio.c:722: undefined reference to `HeapRealloc' collect2: ld returned 1 exit status make[2]: *** [winearts.drv.so] Error 1 Anyone else get this? Cheers, Paul. ---- Paul Millar

3 4

Fwd: Re: [Discuss] Crossover Office with Microsoft Publish '97
by Jesse Hammons 09 Jan '04

09 Jan '04

Does anybody know the basic problem with Microsoft Publisher '97 not working with wine? I'm willing to debug it a bit, but I want to find out how big of a project it is first. Or maybe somebody else is working on this already? Publisher '97 loads files and seems to almost complete functionality on my system. Unfortunately I can't click on any UI elements and keyboard events aren't processed. Someone seems to have even gotton Publisher 2000 to work (there is a workaround posted in the application database). However this fix doesn't work on Publisher '97. I would like to patch this, especially if it is relatively straightforward to do so. What kind of logging can I turn on to find out what is happening to the mouse/keyboard events, etc. Thanks, -Jesse --- Jeremy White <jwhite(a)codeweavers.com> wrote: > Subject: Re: [Discuss] Crossover Office with Microsoft Publish '97 > From: Jeremy White <jwhite(a)codeweavers.com> > To: discuss(a)crossover.codeweavers.com > Date: 09 Jan 2004 08:58:30 -0600 > > Hi Jesse, > > This is a great question, and the answer is to a Wine hacker -- > we'd love to have your help! > > The full set of resources for hacking on Wine are at www.winehq.org; > I know that's intimidating, but there are friendly folks > on irc at #winehq. If you show that you're willing to do > the elbow grease (and are a bit patient), I think you'll find > that folks will jump to help you. > > Finally, it's fairly straightforward to configure CrossOver to > use Wine from CVS; look in the config file in the cxoffice/etc > directory. > > Good hunting, and welcome! > > Cheers, > > Jeremy > > > On Thu, 2004-01-08 at 15:32, Jesse Hammons wrote: > > > > I have downloaded and installed the Crossover Office trial version > on > > my debian GNU/linux system (sarge, kernel version 2.4.20). I used > the > > Crossover setup program to install MS Publisher from the Office '97 > CD. > > > > Setup installs MS publisher with no errors. Publisher starts up, > and > > displays the initial dialog (where you can choose a template or > open an > > existing file). After cancelling this initial dialog, publisher is > > aware of the mouse location (it updates the rulers when you move > the > > mouse) but no mouse clicks or keyboard presses are processed. > > Something wrong with window modality? > > > > Is there anything I can tweak to try to get MS pub to work? How > about > > a way to log the translation of X events to windows events, so I > can > > try to trace where they are going? > > > > PS This behavior in crossover is the same behavior as when I tried > with > > wine-030618. > > > > Thanks, > > -Jesse > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > > http://hotjobs.sweepstakes.yahoo.com/signingbonus > > _______________________________________________ > > discuss mailing list > > discuss(a)crossover.codeweavers.com > > http://crossover.codeweavers.com/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list > discuss(a)crossover.codeweavers.com > http://crossover.codeweavers.com/mailman/listinfo/discuss __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

1 0

Re: #6 - Add delay loading to rundll32
by Dmitry Timoshkov 09 Jan '04

09 Jan '04

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > I hope my formatting is right. I use EditPlus to do my development and > it tends to not agree with Wine sources sometimes so I have to go back > to notepad to clean it up. With this patch I can compile rundll32 on > Mingw now. > > Changelog: > Delay load Wine16 APIs for Win16 dlls. Your patch is not only formatted badly, but it also does things not allowed in plain C - places variables in the middle of the function body. Please fix. -- Dmitry.

2 1

WWN broken
by Mike Hearn 09 Jan '04

09 Jan '04

XML error: not well-formed (invalid token) at line 104 Looks like it contains a typo. I thought only 1 item was a bit strange :)

2 1

Re: #6 - Add delay loading to rundll32
by Andreas Mohr 09 Jan '04

09 Jan '04

On Fri, Jan 09, 2004 at 07:14:07AM -0800, Steven Edwards wrote: > Hello, > I hope my formatting is right. I use EditPlus to do my development and As soon as you have to resort to phrases like "I hope...", you already know that you're in troubled and boiling water. ;-) - HeapFree( GetProcessHeap(), 0, dllA );^M - return ret;^M Andreas Mohr

1 0

Re: shell shorcuts
by Subhobroto Sinha 09 Jan '04

09 Jan '04

One day thus spake Martin Fuchs: >I am working on the ReactOS Explorer, which uses Wine's shell32 implementation. >We already have made many bugfixes and estensions to the shell link and other >shell32 code. One of those extensions is the implementation of control panel in >shell namespace I am already aware of that (thanks to Steve), and I would appreciate if someone could send me the changes/patches to shell32 by the ReactOS team (even if the source does not compile) so I can have a look.. Perhaps you can send me a zip of the ReactOS shell32 directory (keep the makefiles and .defs out - send just the real source :) ) ? That will be nice >Well, I think it's because it has been defined wrong. I am currently using this >definition: >#define SCF_UNICODE 0x80 (instead of 0x1000) >This is at least compatible to links of WIN95 (ANSI strings) and WIN XP (UTF16 strings). >I did not yet test any other operating system versions. With this corrected >defintion and a few more extensions Stream_LoadString() works pretty well >on ReactOS. Hmm..., I KNOW 'SCF_UNICODE' is NOT 0x1000 in the first place, but why do you say it's 0x80 ? Going by the copyrights, Marcus Meissner and Juergen Schmied did the initial job, and perhaps one of them put this value. I don't know about Juergen, but I have tremendous faith in Marcus (I use SuSE you see ;) ), and there MUST have been some reason why 'SCF_UNICODE' got the value 0x1000, although it seems to be wrong ! Hence, please consolidate your assigning it 0x80 with some examples/hexedits so that I can answer when I get grilled ;) However, I think that we should ALL handle strings as Unicode internally, and convert to ANSI when required, and NOT the other way round. Hence, we will be compatible with Win98/ME/2K/XP, as that's what M$ does... If you see my code carefully, you will notice that EVERYTHING is handled as Unicode internally. The flag 'SCF_UNICODE' is used to test the bit mask and determine if the .lnk is serialized in Unicode or not... I am pretty sure that Windows >95 handle EVERYTHING in Unicode, and thus a wrong value of 'SCF_UNICODE' will ONLY mess up Win95 .lnk files ! If you can consolidate your defining 'SCF_UNICODE' as 0x80, I will ONLY be too happy to incorporate that, else those still using Win95 (?) may suffer, as Win95 handles strings as ANSI and not Unicode... Will send Alexandre my patch within the next few days as no one has objected to it being messy, so take the last chance ;) BTW Martin, great work with ROSExplorer, keep at it, and one day WINE will have a complete Desktop with shell namespaces ! Regards Subhobroto Sinha

2 1

reading relay log
by Ferenc Wagner 09 Jan '04

09 Jan '04

Hi, I feel rather stupid, but need help understanding this. I managed to screw up winetest so that it runs into trouble. The relay trace goes like (indented by examine-relay) -------------------------------------------------------------------- 000a:Call comctl32.InitCommonControls() ret=40593c29 000a:Ret comctl32.InitCommonControls() retval=40def6d4 ret=40593c29 000a:Call kernel32.GetModuleHandleA(00000000) ret=40593c3c 000a:Ret kernel32.GetModuleHandleA() retval=40540000 ret=40593c3c 000a:Call user32.CreateDialogParamA(40540000,00000064,00000000,40593b4c,00000000) ret=40593c42 000a:Call kernel32.FindResourceA(40540000,00000064,00000005) ret=407aa47f 000a:Ret kernel32.FindResourceA() retval=405954f8 ret=407aa47f 000a:Call kernel32.LoadResource(40540000,405954f8) ret=407aa48a 000a:Ret kernel32.LoadResource() retval=40590d20 ret=407aa48a 000a:Call kernel32._EnterSysLevel(40810b00) ret=407c21b8 000a:Ret kernel32._EnterSysLevel() retval=00000008 ret=407c21b8 000a:Call kernel32._LeaveSysLevel(40810b00) ret=407c21dc 000a:Ret kernel32._LeaveSysLevel() retval=00000000 ret=407c21dc 000a:Call kernel32._EnterSysLevel(40810b00) ret=407c21b8 000a:Ret kernel32._EnterSysLevel() retval=00000008 ret=407c21b8 000a:Call kernel32._EnterSysLevel(40810b00) ret=407c21b8 000a:Ret kernel32._EnterSysLevel() retval=00000008 ret=407c21b8 000a:Call kernel32._LeaveSysLevel(40810b00) ret=407c21dc 000a:Ret kernel32._LeaveSysLevel() retval=00000000 ret=407c21dc 000a:Call ntdll.RtlAllocateHeap(40300000,00000000,0000001c) ret=407a6047 000a:Ret ntdll.RtlAllocateHeap() retval=40347998 ret=407a6047 000a:Call gdi32.CreateDCA(407f0e04 "DISPLAY",00000000,00000000,00000000) ret=407a6066 000a:Call ntdll.RtlCreateUnicodeStringFromAsciiz(40def3e8,407f0e04 "DISPLAY") ret=408994dd 000a:Ret ntdll.RtlCreateUnicodeStringFromAsciiz() retval=00000001 ret=408994dd 000a:Call kernel32._CheckNotSysLevel(408cf320) ret=408a56e8 000a:Ret kernel32._CheckNotSysLevel() retval=0000000a ret=408a56e8 000a:Call ntdll.RtlEnterCriticalSection(408cf400) ret=408ae109 000a:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=408ae109 000a:Call ntdll.RtlLeaveCriticalSection(408cf400) ret=408ae1d9 000a:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=408ae1d9 000a:Call kernel32._EnterSysLevel(408cf320) ret=408a50cf 000a:Ret kernel32._EnterSysLevel() retval=0000000c ret=408a50cf 000a:Call ntdll.RtlAllocateHeap(40300000,00000000,00000138) ret=408a5215 000a:Ret ntdll.RtlAllocateHeap() retval=403479c0 ret=408a5215 000a:Call x11drv.CreateDC(403479c0,403479d8,40def15c L"DISPLAY",00000000,00000000,00000000) ret=40899405 000a:Call ntdll.RtlAllocateHeap(40300000,00000008,0000008c) ret=409ee0de 000a:Ret ntdll.RtlAllocateHeap() retval=40347b00 ret=409ee0de 000a:Call gdi32.GetObjectType(0000007c) ret=409ee125 000a:Call kernel32._EnterSysLevel(408cf320) ret=408a5527 000a:Ret kernel32._EnterSysLevel() retval=0000000c ret=408a5527 000a:Call kernel32._LeaveSysLevel(408cf320) ret=408a56c3 000a:Ret kernel32._LeaveSysLevel() retval=00000000 ret=408a56c3 000a:Ret gdi32.GetObjectType() retval=00000003 ret=409ee125 000a:Call ntdll.RtlEnterCriticalSection(40a20700) ret=409fe8b0 000a:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=409fe8b0 err:ntdll:RtlpWaitForCriticalSection section 0x40334040 "?" wait timed out in thread 000a, blocked by 0009, retrying (60 sec) -------------------------------------------------------------------- which I don't understand given the definition -------------------------------------------------------------------- HWND WINAPI CreateDialogParamA( HINSTANCE hInst, LPCSTR name, HWND owner, DLGPROC dlgProc, LPARAM param ) { HRSRC hrsrc; LPCDLGTEMPLATEA ptr; if (!(hrsrc = FindResourceA( hInst, name, (LPSTR)RT_DIALOG ))) return 0; if (!(ptr = (LPCDLGTEMPLATEA)LoadResource(hInst, hrsrc))) return 0; return CreateDialogIndirectParamA( hInst, ptr, owner, dlgProc, param ); } -------------------------------------------------------------------- After LoadResource returns, I would expect a call to CreateDialogIndirectParamA instead of the SysLevels etc. Could somebody explain this, please? Thanks a lot, Feri.

7 19

uxtheme and unicode INI files
by Kevin Koltzau 09 Jan '04

09 Jan '04

I've submitted this patch once with no luck, but I've got a question that may affect my need to use this patch (or one similar) Msstyles store a few INI files within the style that define various properties of the theme. Windows duplicates all the .ini file processing within uxtheme.dll, I would prefer to not do this (hence this patch) however, what are the feelings of temp files being generated from resources in a style while its being loaded (which would be needed to use the GetPrivateProfile* family of functions)? Or would it be preferable that I stick with the way windows does it (by duplicating the ini file loading within uxtheme) and do all the processing in memory?

2 1

Re: Allow runtime control of the number of X11 fonts
by Alexandre Julliard 09 Jan '04

09 Jan '04

Bill Medland <billmedland(a)mercuryspeed.com> writes: > Bill Medland (billmedland(a)mercuryspeed.com) > Allow runtime increase in the maximum number of fonts processed. Do we really need a config parameter for that? Actually, do we really need a limit at all? -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Broken Mandrake packages
by Ivan Leo Murray-Smith 08 Jan '04

08 Jan '04

> Hmm, OK. I don't know which this person was using. Why is /usr/lib/wine > even added to ld.so.conf though, surely that isn't necessary? Only > libwine needs to be in the linker path. libs are in /usr/lib/wine and dlls are in /usr/lib/wine/dlls, not adding /usr/lib/wine to ld.so.conf causes wine to fail, as it doesn't find ntdll.dll.so. There are alternative solutions, but this looks good to me, keeps dirs tidy and has always worked. Ivan.

4 6

dll name length (was: Windows dll replacement with Linux library)
by Dan Timis 08 Jan '04

08 Jan '04

I finally figured out what my problem was. If the name of the library is "USBUtils" it works, if it is "USBDeviceUtils" it doesn't. Actually the max length I can use is 11 characters. That is probably 15 characters including ".dll" In my config file all filesystems are "win95" The version is "nt40" Is there any way to configure wine to support longer names? Thanks, Dan Timis Sounds Just Right, Inc. > From: Dan Timis <timis(a)museresearch.com> > > On Saturday, January 3, 2004, at 01:07 AM, Dimitrie O. Paun wrote: > >>> I'm new to this so please bear with me. >>> >>> First I edited the Makefile and replaced gcc with winegcc. When I >>> run >>> "make" I get this error when it tries to link: >>> >>> could not open .def file for kernel32 >>> Error: /usr/bin/winebuild failed. >>> Error: /usr/bin/winewrap failed. >> >> Can you please send me the command that generates this? Just to make >> sure that we're on the same page, use winegcc (for now) just for >> building >> the test application, not the DLL. >> >>> Then, I ran ./configure --help and it says that you can use the "CC" >>> var to specify the compiler. I started from scratch, set "export >>> CC=winegcc", then ran configure again. The output looks like this: >>> >>> checking whether make sets {$MAKE}... yes >>> checking for gcc... winegcc >>> checking for C compiler default output... configure: error: C >>> compiler >>> cannot create executables >> >> This is very odd. winegcc should be configure friendly (it does work >> for >> wxWindows BTW). Hey, what version of Wine are you using? I do hope >> it's >> the latest CVS... > > I am using an older version 20030618. It's hard to change, other > people depend on this particular version and I would have to upgrade > several machines. I could try on one machine, but... > > A colleague who dealt with similar problems in the past helped me. He > added this to Makefile.in > > # generate a .def "import library" file from the spec file > $(usbutils_dll_DEF): $(usbutils_dll_SPEC_SRCS) Makefile.in > $(WINEBUILD) --def $(usbutils_dll_SPEC_SRCS) > $(usbutils_dll_DEF) > > Both the .dll.so and the .def go in /usr/lib/wine/wine. Earlier I > noticed that there was no .def file. That was our clue. > > For the test we added the library to the list of wine dlls in > Makefile.in. > > It's working. > > I'm still a little confused, but I understand much more than a week > ago. Thanks. > > Dan Timis > Muse Research, Inc. >

3 3

Re: Broken Mandrake packages
by Ivan Leo Murray-Smith 08 Jan '04

08 Jan '04

> These are all libraries that belong to /usr/lib. > All others (<dllname>.dll.so dlls must go to /usr/lib/wine/). > > libwine.so will look and find them in /usr/lib/wine/ by default when trying to load them. > > There is NO need to add /usr/lib/wine to ld.so.conf! OK, I'll change this in this months build. Ivan.

1 0

Re: Broken Mandrake packages
by Ivan Leo Murray-Smith 08 Jan '04

08 Jan '04

> Could whoever is responsible for these packages please double check the > specfiles? Never heard of such a problem, all RPMs are tested on both mdk 9.2 and 9.1, on 2 different computers, and I've never noticed any lib problem. /usr/lib/wine is added to ld.so.conf during post, and after that ldconfig is run. I am NOT responsible for the RPMS shipped by Mandrakesoft. Ivan.

2 1

Wine troubles on Diskless workstations.....
by Alex Stewart 08 Jan '04

08 Jan '04

Hi, Below is a thread I started in the wine-users list but so far no seems to know the answer. I've tried their suggestions but they dont work. I think its a simple question (maybe not I dont really know thats why I have the question) How does wine store the path to its libraries? Simply put I changed the prefix var in the wineinstall script to point to a different "root" path for a diskless client system. The path is the root folder that gets made into a compressed tar.gz for the ram disk. Anyway as you would think/probobly guessed when I run wine on the client the path to the libs are not correct, they still point to the path on the server instead of the true root (/lib/wine)..... Thanx a bunch in advance! -Alex PS- If I didnt explain to well above the drawn out thread of what Im doing and why is below....Thanx for your time! > Then perhaps you should build wine with the prefix that the clients > will > be using. You may need to create a chroot'ed environment that emulates > what the clients will be using. The problem with that is the Diskless clients are "Thin" ie they have a minimal system and thus no rpm management or a compiler (no gcc). > This is, of course, the problem you're actually having. You're pointing > the install directory to a directory that doesn't exist for the > clients. > Right. If I did point it to the correct path it would install on the server's local lib folder which the clients have no access to. If I rebuild wine (now that it has installed in the client root system) with the correct path would all I need to do is snag the new binaries from the bin folder of the server and put them in the bin of the client root? Sorry I keep asking this but WHERE is this path stored? Because its not in ./wine/config I cant seem to find it anywhere. I ask because if I do rebuild and its not hardcoded in the binary and it aint in ./wine/config then the problem will persist because I dont know where to change it back! On Jan 7, 2004, at 11:21 PM, Rob Hughes wrote: > On Wed, 2004-01-07 at 20:18, Alex Stewart wrote: > >> it looks for its libs at : >> /opt/pxes-0.7/stock/dist/lib/wine/ntdll.dll.so Which makes since. >> The >> directory "dist" >> is the distribution level of the root fs. So when it gets compressed >> the nodes think dist is root ie the libraries >> are in the file system there just not in >> opt/pxes-0.7/stock/dist/lib/wine/ntdll.dll.so they are in fact in >> /lib >> at the root of the ramdisk.......So my question is where is this path > > > Then perhaps you should build wine with the prefix that the clients > will > be using. You may need to create a chroot'ed environment that emulates > what the clients will be using. > > This is, of course, the problem you're actually having. You're pointing > the install directory to a directory that doesn't exist for the > clients. > > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-users >

3 2

Wineconf update, RFC re remote participation
by Jeremy White 08 Jan '04

08 Jan '04

Hi folks, Okay, I've updated the Wineconf page: http://www.winehq.org/wineconf/ One thing I would like to do is to stream audio from the conference out to the web and also work very hard to include folks from #winehq (or maybe #wineconf) in some of the sessions. The sessions I thought made particular sense were the ones around Wine 1.0 as well as on OLE and Games. Does anyone recall being remote to the last Wineconf? Did it work at all? Is there anything we could/should do to enable others to join us, if only virtually? (Please feel free to tell me that it didn't work worth beans and we should just drop it, btw <g>). Other thoughts or comments? Thanks, Jer

4 6

Will DCOM98 be pulled?
by Mike Hearn 08 Jan '04

08 Jan '04

Hi guys, I note that Win98 is about to be finally obsoleted. After this, it's possible Microsoft will do the same as they did with IE and other stuff for Win95 and pull downloads from their website. This is a problem, because we currently need the DCOM downloads in order for some apps to work - can somebody with legal knowledge check the EULA and see if we are allowed to redistribute this file? thanks -mike

6 12

Re: Re: winearts patch
by chmorgan＠charter.net 08 Jan '04

08 Jan '04

> > (4b) wodPlayer_FeedDSP() > > > > In the while loop, I could not figure out the purpose of 'availInQ > > > SPACE_THRESHOLD', so I changed it to 'availInQ'. In reality, the > > SPACE_THRESHOLD check could probably be left in, I am not sure what > > the purpose was in the first place. > Dunno either. Reading Chris response, we need this on OSS (because > sounds is processed by fragments of fixed size). I don't know how arts > behaves here... Thrashing it altogether could also work. It would seem to reduce the number of calls to arts if we waited for a minimum amount of data, not sure if the input size of each chunk of input data is large enough to make this check pointless or if it won't hurt performace making the additional calls, just wanted to point it out. The issue with OSS appears to be that for some drivers the fragment prior to the last one isn't played if the last fragment isn't complete, line 1398 of wineoss/audio.c, I'd be inclined to think this isn't something to worry about with arts. Chris

2 1

winearts patch
by Jeremy Shaw 08 Jan '04

08 Jan '04

Hello, This message is largely for Chris Morgan's review, but I thought I should open it to any interested parties. I have added wave-in support for arts. I also fixed some bugs in the waveout code, and made some "improvements". This code seems to work really well for me. If no one sees any problems I will submit the patch to the patches mailing list. Here is a brief description of the changes I made: (1) In ARTS_CloseDevice() (now named ARTS_CloseWaveOutDevice()) and wodPlayer_NotifyWait() I added 'wwo->sound_buffer = 0' after the HeapFree(). Without it, HeapFree() was being called twice on the same buffer, and would crash the second time. (2) ARTS_AddRingMessage() Added the same fix I submitted earlier for wineoss in regards to ring buffer resizing. (3) wodPlayer_WriteMaxFrags() DWORD *bytes, points to the number of bytes the winearts driver thinks it should be able to write. However, arts sometimes lies, and says it has (for example) 512 bytes available, but when you call arts_write() it returns zero bytes written. In that case, I update *bytes to point to 0, otherwise wodPlayer_WriteMaxFrags() will keep being called in vain. (4a) wodPlayer_FeedDSP() The old code had the following checks: /* input queue empty and output buffer with no space */ if (!wwo->lpPlayPtr && availInQ) { TRACE("Run out of wavehdr:s... flushing\n"); wwo->dwPlayedTotal = wwo->dwWrittenTotal; return INFINITE; } if(!availInQ) { TRACE("no more room, no need to try to feed\n"); return wodPlayer_DSPWait(wwo); } I could not understand the purpose of the '&& availInQ' in the first check. It seems that if we are out of wavehdrs, then it does not matter if there is space in the availInQ or not, because we don't have anything to write. So I removed the && availInQ part. Looking at it now, I realize that maybe I need to add 'if (!availInQ)' before 'wwo->dwPlayedTotal = wwo->dwWrittenTotal'? (4b) wodPlayer_FeedDSP() In the while loop, I could not figure out the purpose of 'availInQ > SPACE_THRESHOLD', so I changed it to 'availInQ'. In reality, the SPACE_THRESHOLD check could probably be left in, I am not sure what the purpose was in the first place. (4c) wodPlayer_FeedDSP() the while loop in wodPlayer_FeedDSP() can terminate for two reasons: + availInQ == 0 + ran out of waveHdrs to write. In the first case, wodPlayer_FeedDSP() should return the number of milliseconds before the buffer needs more data (which it currently does). In the second case, it should return INFINTE, since it can't feed anymore data until it gets some more wave headers. I added a bit of code to handle the second case. Notice also, that DSPWait() will only be called when the availInQ == 0. This means that DSPWait() is always calculating the same value which leads us to 4d. (4d) Removed wodPlayer_DSPWait() I just calculate the wait value once in wodOpen() and store it in wwo->dwSleepTime. (5) wodOpen () In wodOpen I changed the code from setting the ARTS_P_BUFFER_SIZE, to setting the ARTS_P_PACKET_SETTINGS. This allows for finer control which I needed in order to achieve lower latency. The rest of the changes are for adding wave in support. Jeremy Shaw. --- orig/dlls/winmm/winearts/winearts.drv.spec +++ mod/dlls/winmm/winearts/winearts.drv.spec @@ -1,2 +1,3 @@ @ stdcall DriverProc(long long long long long) ARTS_DriverProc @ stdcall wodMessage(long long long long long) ARTS_wodMessage +@ stdcall widMessage(long long long long long) ARTS_widMessage --- orig/dlls/winmm/winearts/audio.c +++ mod/dlls/winmm/winearts/audio.c @@ -32,8 +32,7 @@ * FIXME: * pause in waveOut does not work correctly in loop mode * - * TODO: - * implement wave-in support with artsc + * does something need to be done in for WaveIn DirectSound? */ /*#define EMULATE_SB16*/ @@ -65,10 +64,32 @@ #include <artsc.h> -#define BUFFER_SIZE 16 * 1024 -#define SPACE_THRESHOLD 5 * 1024 +/* The following four #defines allow you to fine-tune the packet + * settings in arts for better low-latency support. You must also + * adjust the latency in the KDE arts control panel. I recommend 4 + * fragments, 1024 bytes. + * + * The following is from the ARTS documentation and explains what CCCC + * and SSSS mean: + * + * @li ARTS_P_PACKET_SETTINGS (rw) This is a way to configure packet + * size & packet count at the same time. The format is 0xCCCCSSSS, + * where 2^SSSS is the packet size, and CCCC is the packet count. Note + * that when writing this, you don't necessarily get the settings you + * requested. + */ +#define WAVEOUT_PACKET_CCCC 0x000C +#define WAVEOUT_PACKET_SSSS 0x0008 +#define WAVEIN_PACKET_CCCC 0x000C +#define WAVEIN_PACKET_SSSS 0x0008 + +#define BUFFER_REFILL_THRESHOLD 4 + +#define WAVEOUT_PACKET_SETTINGS ((WAVEOUT_PACKET_CCCC << 16) | (WAVEOUT_PACKET_SSSS)) +#define WAVEIN_PACKET_SETTINGS ((WAVEIN_PACKET_CCCC << 16) | (WAVEIN_PACKET_SSSS)) #define MAX_WAVEOUTDRV (10) +#define MAX_WAVEINDRV (10) /* state diagram for waveOut writing: * @@ -96,7 +117,7 @@ /* events to be send to device */ enum win_wm_message { WINE_WM_PAUSING = WM_USER + 1, WINE_WM_RESTARTING, WINE_WM_RESETTING, WINE_WM_HEADER, - WINE_WM_UPDATE, WINE_WM_BREAKLOOP, WINE_WM_CLOSING + WINE_WM_UPDATE, WINE_WM_BREAKLOOP, WINE_WM_CLOSING, WINE_WM_STARTING, WINE_WM_STOPPING }; typedef struct { @@ -126,9 +147,12 @@ PCMWAVEFORMAT format; WAVEOUTCAPSA caps; + DWORD dwSleepTime; /* Num of milliseconds to sleep between filling the dsp buffers */ + /* arts information */ arts_stream_t play_stream; /* the stream structure we get from arts when opening a stream for playing */ DWORD dwBufferSize; /* size of whole buffer in bytes */ + int packetSettings; char* sound_buffer; long buffer_size; @@ -154,7 +178,29 @@ ARTS_MSG_RING msgRing; } WINE_WAVEOUT; +typedef struct { + volatile int state; /* one of the WINE_WS_ manifest constants */ + WAVEOPENDESC waveDesc; + WORD wFlags; + PCMWAVEFORMAT format; + WAVEINCAPSA caps; + + /* arts information */ + arts_stream_t record_stream; /* the stream structure we get from arts when opening a stream for recording */ + int packetSettings; + + LPWAVEHDR lpQueuePtr; + DWORD dwRecordedTotal; + + /* synchronization stuff */ + HANDLE hStartUpEvent; + HANDLE hThread; + DWORD dwThreadID; + ARTS_MSG_RING msgRing; +} WINE_WAVEIN; + static WINE_WAVEOUT WOutDev [MAX_WAVEOUTDRV]; +static WINE_WAVEIN WInDev [MAX_WAVEINDRV]; static DWORD wodDsCreate(UINT wDevID, PIDSDRIVER* drv); static DWORD wodDsDesc(UINT wDevID, PDSDRIVERDESC desc); @@ -169,6 +215,8 @@ "WINE_WM_UPDATE", "WINE_WM_BREAKLOOP", "WINE_WM_CLOSING", + "WINE_WM_STARTING", + "WINE_WM_STOPPING", }; /*======================================================================* @@ -229,22 +277,35 @@ } /****************************************************************** - * ARTS_CloseDevice + * ARTS_CloseWaveOutDevice * */ -void ARTS_CloseDevice(WINE_WAVEOUT* wwo) +void ARTS_CloseWaveOutDevice(WINE_WAVEOUT* wwo) { arts_close_stream(wwo->play_stream); /* close the arts stream */ wwo->play_stream = (arts_stream_t*)-1; /* free up the buffer we use for volume and reset the size */ if(wwo->sound_buffer) + { HeapFree(GetProcessHeap(), 0, wwo->sound_buffer); + wwo->sound_buffer = 0; + } wwo->buffer_size = 0; } /****************************************************************** + * ARTS_CloseWaveInDevice + * + */ +void ARTS_CloseWaveInDevice(WINE_WAVEIN* wwi) +{ + arts_close_stream(wwi->record_stream); /* close the arts stream */ + wwi->record_stream = (arts_stream_t*)-1; +} + +/****************************************************************** * ARTS_Init */ static int ARTS_Init(void) @@ -264,7 +325,15 @@ { if(WOutDev[iDevice].play_stream != (arts_stream_t*)-1) { - ARTS_CloseDevice(&WOutDev[iDevice]); + ARTS_CloseWaveOutDevice(&WOutDev[iDevice]); + } + } + + for(iDevice = 0; iDevice < MAX_WAVEINDRV; iDevice++) + { + if(WInDev[iDevice].record_stream != (arts_stream_t*)-1) + { + ARTS_CloseWaveInDevice(&WInDev[iDevice]); } } @@ -331,7 +400,44 @@ WOutDev[i].caps.dwFormats |= WAVE_FORMAT_1S16; } + for (i = 0; i < MAX_WAVEINDRV; ++i) + { + WInDev[i].record_stream = (arts_stream_t*)-1; + memset(&WInDev[i].caps, 0, sizeof(WInDev[i].caps)); /* zero out + caps values */ + /* FIXME: some programs compare this string against the content of the registry + * for MM drivers. The names have to match in order for the program to work + * (e.g. MS win9x mplayer.exe) + */ +#ifdef EMULATE_SB16 + WInDev[i].caps.wMid = 0x0002; + WInDev[i].caps.wPid = 0x0104; + strcpy(WInDev[i].caps.szPname, "SB16 Wave In"); +#else + WInDev[i].caps.wMid = 0x00FF; + WInDev[i].caps.wPid = 0x0001; + strcpy(WInDev[i].caps.szPname,"CS4236/37/38"); +#endif + WInDev[i].caps.vDriverVersion = 0x0100; + WInDev[i].caps.dwFormats = 0x00000000; + + WInDev[i].caps.wChannels = 2; + + WInDev[i].caps.dwFormats |= WAVE_FORMAT_4M08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_4S08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_4S16; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_4M16; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_2M08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_2S08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_2M16; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_2S16; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_1M08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_1S08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_1M16; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_1S16; + WInDev[i].caps.wReserved1 = 0; + } return 0; } @@ -376,9 +482,22 @@ EnterCriticalSection(&mr->msg_crst); if ((mr->msg_toget == ((mr->msg_tosave + 1) % mr->ring_buffer_size))) { + int old_ring_buffer_size = mr->ring_buffer_size; mr->ring_buffer_size += ARTS_RING_BUFFER_INCREMENT; TRACE("mr->ring_buffer_size=%d\n",mr->ring_buffer_size); mr->messages = HeapReAlloc(GetProcessHeap(),0,mr->messages, mr->ring_buffer_size * sizeof(RING_MSG)); + /* Now we need to rearrange the ring buffer so that the new + buffers just allocated are in between mr->msg_tosave and + mr->msg_toget. + */ + if (mr->msg_tosave < mr->msg_toget) + { + memmove(&(mr->messages[mr->msg_toget + ARTS_RING_BUFFER_INCREMENT]), + &(mr->messages[mr->msg_toget]), + sizeof(RING_MSG)*(old_ring_buffer_size - mr->msg_toget) + ); + mr->msg_toget += ARTS_RING_BUFFER_INCREMENT; + } } if (wait) { @@ -554,25 +673,6 @@ } /************************************************************************** - * wodPlayer_DSPWait [internal] - * Returns the number of milliseconds to wait for the DSP buffer to clear. - * This is based on the number of fragments we want to be clear before - * writing and the number of free fragments we already have. - */ -static DWORD wodPlayer_DSPWait(const WINE_WAVEOUT *wwo) -{ - int waitvalue = (wwo->dwBufferSize - arts_stream_get(wwo->play_stream, - ARTS_P_BUFFER_SPACE)) / ((wwo->format.wf.nSamplesPerSec * - wwo->format.wBitsPerSample * wwo->format.wf.nChannels) - /1000); - - TRACE("wait value of %d\n", waitvalue); - - /* return the time left to play the buffer */ - return waitvalue; -} - -/************************************************************************** * wodPlayer_NotifyWait [internal] * Returns the number of milliseconds to wait before attempting to notify * completion of the specified wavehdr. @@ -618,7 +718,10 @@ if(wwo->buffer_size < toWrite) { if(wwo->sound_buffer) - HeapFree(GetProcessHeap(), 0, wwo->sound_buffer); + { + HeapFree(GetProcessHeap(), 0, wwo->sound_buffer); + wwo->sound_buffer = 0; + } } /* if we don't have a buffer then get one */ @@ -664,7 +767,11 @@ TRACE("written = %d\n", written); - if (written <= 0) return written; /* if we wrote nothing just return */ + if (written <= 0) + { + *bytes = 0; /* apparently arts is actually full */ + return written; /* if we wrote nothing just return */ + } if (written >= dwLength) wodPlayer_PlayPtrNext(wwo); /* If we wrote all current wavehdr, skip to the next one */ @@ -690,6 +797,23 @@ { LPWAVEHDR lpWaveHdr; + if (wwo->lpQueuePtr) { + TRACE("lpWaveHdr=(%p), lpPlayPtr=(%p), lpLoopPtr=(%p), reserved=(%ld), dwWrittenTotal=(%ld), force=(%d)\n", + wwo->lpQueuePtr, + wwo->lpPlayPtr, + wwo->lpLoopPtr, + wwo->lpQueuePtr->reserved, + wwo->dwWrittenTotal, + force); + } else { + TRACE("lpWaveHdr=(%p), lpPlayPtr=(%p), lpLoopPtr=(%p), dwWrittenTotal=(%ld), force=(%d)\n", + wwo->lpQueuePtr, + wwo->lpPlayPtr, + wwo->lpLoopPtr, + wwo->dwWrittenTotal, + force); + } + /* Start from lpQueuePtr and keep notifying until: * - we hit an unwritten wavehdr * - we hit the beginning of a running loop @@ -699,7 +823,7 @@ (force || (lpWaveHdr != wwo->lpPlayPtr && lpWaveHdr != wwo->lpLoopPtr && - lpWaveHdr->reserved <= wwo->dwPlayedTotal))) { + lpWaveHdr->reserved <= wwo->dwWrittenTotal))) { wwo->lpQueuePtr = lpWaveHdr->lpNext; @@ -854,8 +978,8 @@ availInQ = arts_stream_get(wwo->play_stream, ARTS_P_BUFFER_SPACE); TRACE("availInQ = %ld\n", availInQ); - /* input queue empty and output buffer with no space */ - if (!wwo->lpPlayPtr && availInQ) { + /* input queue empty */ + if (!wwo->lpPlayPtr) { TRACE("Run out of wavehdr:s... flushing\n"); wwo->dwPlayedTotal = wwo->dwWrittenTotal; return INFINITE; @@ -865,7 +989,7 @@ if(!availInQ) { TRACE("no more room, no need to try to feed\n"); - return wodPlayer_DSPWait(wwo); + return wwo->dwSleepTime; } /* Feed from partial wavehdr */ @@ -878,16 +1002,26 @@ /* Feed wavehdrs until we run out of wavehdrs or DSP space */ if (!wwo->dwPartialOffset) { - while(wwo->lpPlayPtr && availInQ > SPACE_THRESHOLD) - { - TRACE("feeding waveheaders until we run out of space\n"); - /* note the value that dwPlayedTotal will return when this wave finishes playing */ - wwo->lpPlayPtr->reserved = wwo->dwWrittenTotal + wwo->lpPlayPtr->dwBufferLength; - wodPlayer_WriteMaxFrags(wwo, &availInQ); - } + while(wwo->lpPlayPtr && availInQ) + { + TRACE("feeding waveheaders until we run out of space\n"); + /* note the value that dwPlayedTotal will return when this wave finishes playing */ + wwo->lpPlayPtr->reserved = wwo->dwWrittenTotal + wwo->lpPlayPtr->dwBufferLength; + TRACE("reserved=(%ld) dwWrittenTotal=(%ld) dwBufferLength=(%ld)\n", + wwo->lpPlayPtr->reserved, + wwo->dwWrittenTotal, + wwo->lpPlayPtr->dwBufferLength + ); + wodPlayer_WriteMaxFrags(wwo, &availInQ); + } } - return wodPlayer_DSPWait(wwo); + if (!wwo->lpPlayPtr) { + TRACE("Ran out of wavehdrs\n"); + return INFINITE; + } + + return wwo->dwSleepTime; } @@ -1010,14 +1144,19 @@ if(!wwo->play_stream) return MMSYSERR_ALLOCATED; - /* Try to set buffer size from constant and store the value that it - was set to for future use */ - wwo->dwBufferSize = arts_stream_set(wwo->play_stream, - ARTS_P_BUFFER_SIZE, BUFFER_SIZE); - TRACE("Tried to set BUFFER_SIZE of %d, wwo->dwBufferSize is actually %ld\n", BUFFER_SIZE, wwo->dwBufferSize); + /* Try to set the packet settings from constant and store the value that it + was actually set to for future use */ + wwo->packetSettings = arts_stream_set(wwo->play_stream, ARTS_P_PACKET_SETTINGS, WAVEOUT_PACKET_SETTINGS); + TRACE("Tried to set ARTS_P_PACKET_SETTINGS to (%x), actually set to (%x)\n", WAVEOUT_PACKET_SETTINGS, wwo->packetSettings); + + wwo->dwBufferSize = arts_stream_get(wwo->play_stream, ARTS_P_BUFFER_SIZE); + TRACE("Buffer size is now (%ld)\n",wwo->dwBufferSize); + wwo->dwPlayedTotal = 0; wwo->dwWrittenTotal = 0; + wwo->dwSleepTime = ((1 << (wwo->packetSettings & 0xFFFF)) * 1000 * BUFFER_REFILL_THRESHOLD) / wwo->format.wf.nAvgBytesPerSec; + /* Initialize volume to full level */ wwo->volume_left = 100; wwo->volume_right = 100; @@ -1076,7 +1215,7 @@ ARTS_DestroyRingMessage(&wwo->msgRing); - ARTS_CloseDevice(wwo); /* close the stream and clean things up */ + ARTS_CloseWaveOutDevice(wwo); /* close the stream and clean things up */ ret = wodNotifyClient(wwo, WOM_CLOSE, 0L, 0L); } @@ -1399,6 +1538,499 @@ } /*======================================================================* + * Low level WAVE IN implementation * + *======================================================================*/ + +/************************************************************************** + * widGetNumDevs [internal] + */ +static DWORD widGetNumDevs(void) +{ + TRACE("%d \n",MAX_WAVEINDRV); + return MAX_WAVEINDRV; +} + +/************************************************************************** + * widNotifyClient [internal] + */ +static DWORD widNotifyClient(WINE_WAVEIN* wwi, WORD wMsg, DWORD dwParam1, DWORD dwParam2) +{ + TRACE("wMsg = 0x%04x dwParm1 = %04lX dwParam2 = %04lX\n", wMsg, dwParam1, dwParam2); + + switch (wMsg) { + case WIM_OPEN: + case WIM_CLOSE: + case WIM_DATA: + if (wwi->wFlags != DCB_NULL && + !DriverCallback(wwi->waveDesc.dwCallback, wwi->wFlags, + (HDRVR)wwi->waveDesc.hWave, wMsg, + wwi->waveDesc.dwInstance, dwParam1, dwParam2)) { + WARN("can't notify client !\n"); + return MMSYSERR_ERROR; + } + break; + default: + FIXME("Unknown callback message %u\n", wMsg); + return MMSYSERR_INVALPARAM; + } + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widGetDevCaps [internal] + */ +static DWORD widGetDevCaps(WORD wDevID, LPWAVEINCAPSA lpCaps, DWORD dwSize) +{ + TRACE("(%u, %p, %lu);\n", wDevID, lpCaps, dwSize); + + if (lpCaps == NULL) return MMSYSERR_NOTENABLED; + + if (wDevID >= MAX_WAVEINDRV) { + TRACE("MAX_WAVINDRV reached !\n"); + return MMSYSERR_BADDEVICEID; + } + + memcpy(lpCaps, &WInDev[wDevID].caps, min(dwSize, sizeof(*lpCaps))); + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widRecorder [internal] + */ +static DWORD CALLBACK widRecorder(LPVOID pmt) +{ + WORD uDevID = (DWORD)pmt; + WINE_WAVEIN* wwi = (WINE_WAVEIN*)&WInDev[uDevID]; + WAVEHDR* lpWaveHdr; + DWORD dwSleepTime; + DWORD bytesRead; + int dwBufferSpace; + enum win_wm_message msg; + DWORD param; + HANDLE ev; + + SetEvent(wwi->hStartUpEvent); + + /* make sleep time to be # of ms to record one packet */ + dwSleepTime = ((1 << (wwi->packetSettings & 0xFFFF)) * 1000) / wwi->format.wf.nAvgBytesPerSec; + TRACE("sleeptime=%ld ms\n", dwSleepTime); + + for(;;) { + /* Oddly enough, dwBufferSpace is sometimes negative.... + * + * NOTE: If you remove this call to arts_stream_get() and + * remove the && (dwBufferSpace > 0) the code will still + * function correctly. I don't know which way is + * faster/better. + */ + dwBufferSpace = arts_stream_get(wwi->record_stream, ARTS_P_BUFFER_SPACE); + TRACE("wwi->lpQueuePtr=(%p), wwi->state=(%d), dwBufferSpace=(%d)\n",wwi->lpQueuePtr,wwi->state,dwBufferSpace); + + /* read all data is arts input buffer. */ + if ((wwi->lpQueuePtr != NULL) && (wwi->state == WINE_WS_PLAYING) && (dwBufferSpace > 0)) + { + lpWaveHdr = wwi->lpQueuePtr; + + TRACE("read as much as we can\n"); + while(wwi->lpQueuePtr) + { + TRACE("attempt to read %ld bytes\n",lpWaveHdr->dwBufferLength - lpWaveHdr->dwBytesRecorded); + bytesRead = arts_read(wwi->record_stream, + lpWaveHdr->lpData + lpWaveHdr->dwBytesRecorded, + lpWaveHdr->dwBufferLength - lpWaveHdr->dwBytesRecorded); + TRACE("bytesRead=%ld\n",bytesRead); + if (bytesRead==0) break; + + lpWaveHdr->dwBytesRecorded += bytesRead; + wwi->dwRecordedTotal += bytesRead; + + /* buffer full. notify client */ + if (lpWaveHdr->dwBytesRecorded >= lpWaveHdr->dwBufferLength) + { + /* must copy the value of next waveHdr, because we have no idea of what + * will be done with the content of lpWaveHdr in callback + */ + LPWAVEHDR lpNext = lpWaveHdr->lpNext; + + TRACE("waveHdr full.\n"); + + lpWaveHdr->dwFlags &= ~WHDR_INQUEUE; + lpWaveHdr->dwFlags |= WHDR_DONE; + + widNotifyClient(wwi, WIM_DATA, (DWORD)lpWaveHdr, 0); + lpWaveHdr = wwi->lpQueuePtr = lpNext; + } + } + } + + /* wait for dwSleepTime or an event in thread's queue */ + WaitForSingleObject(wwi->msgRing.msg_event, dwSleepTime); + + while (ARTS_RetrieveRingMessage(&wwi->msgRing, &msg, &param, &ev)) + { + TRACE("msg=%s param=0x%lx\n",wodPlayerCmdString[msg - WM_USER - 1], param); + switch(msg) { + case WINE_WM_PAUSING: + wwi->state = WINE_WS_PAUSED; + + /* Put code here to "pause" arts recording + */ + + SetEvent(ev); + break; + case WINE_WM_STARTING: + wwi->state = WINE_WS_PLAYING; + + /* Put code here to "start" arts recording + */ + + SetEvent(ev); + break; + case WINE_WM_HEADER: + lpWaveHdr = (LPWAVEHDR)param; + /* insert buffer at end of queue */ + { + LPWAVEHDR* wh; + int num_headers = 0; + for (wh = &(wwi->lpQueuePtr); *wh; wh = &((*wh)->lpNext)) + { + num_headers++; + + } + *wh=lpWaveHdr; + } + break; + case WINE_WM_STOPPING: + if (wwi->state != WINE_WS_STOPPED) + { + + /* Put code here to "stop" arts recording + */ + + /* return current buffer to app */ + lpWaveHdr = wwi->lpQueuePtr; + if (lpWaveHdr) + { + LPWAVEHDR lpNext = lpWaveHdr->lpNext; + TRACE("stop %p %p\n", lpWaveHdr, lpWaveHdr->lpNext); + lpWaveHdr->dwFlags &= ~WHDR_INQUEUE; + lpWaveHdr->dwFlags |= WHDR_DONE; + widNotifyClient(wwi, WIM_DATA, (DWORD)lpWaveHdr, 0); + wwi->lpQueuePtr = lpNext; + } + } + wwi->state = WINE_WS_STOPPED; + SetEvent(ev); + break; + case WINE_WM_RESETTING: + wwi->state = WINE_WS_STOPPED; + wwi->dwRecordedTotal = 0; + + /* return all buffers to the app */ + for (lpWaveHdr = wwi->lpQueuePtr; lpWaveHdr; lpWaveHdr = lpWaveHdr->lpNext) { + TRACE("reset %p %p\n", lpWaveHdr, lpWaveHdr->lpNext); + lpWaveHdr->dwFlags &= ~WHDR_INQUEUE; + lpWaveHdr->dwFlags |= WHDR_DONE; + + widNotifyClient(wwi, WIM_DATA, (DWORD)lpWaveHdr, 0); + } + wwi->lpQueuePtr = NULL; + SetEvent(ev); + break; + case WINE_WM_CLOSING: + wwi->hThread = 0; + wwi->state = WINE_WS_CLOSED; + SetEvent(ev); + ExitThread(0); + /* shouldn't go here */ + default: + FIXME("unknown message %d\n", msg); + break; + } + } + } + ExitThread(0); + /* just for not generating compilation warnings... should never be executed */ + return 0; +} + +/************************************************************************** + * widOpen [internal] + */ +static DWORD widOpen(WORD wDevID, LPWAVEOPENDESC lpDesc, DWORD dwFlags) +{ + WINE_WAVEIN* wwi; + + TRACE("(%u, %p %08lX);\n",wDevID, lpDesc, dwFlags); + if (lpDesc == NULL) { + WARN("Invalid Parametr (lpDesc == NULL)!\n"); + return MMSYSERR_INVALPARAM; + } + + if (wDevID >= MAX_WAVEINDRV) { + TRACE ("MAX_WAVEINDRV reached !\n"); + return MMSYSERR_BADDEVICEID; + } + + /* if this device is already open tell the app that it is allocated */ + if(WInDev[wDevID].record_stream != (arts_stream_t*)-1) + { + TRACE("device already allocated\n"); + return MMSYSERR_ALLOCATED; + } + + /* only PCM format is support so far... */ + if (lpDesc->lpFormat->wFormatTag != WAVE_FORMAT_PCM || + lpDesc->lpFormat->nChannels == 0 || + lpDesc->lpFormat->nSamplesPerSec == 0) { + WARN("Bad format: tag=%04X nChannels=%d nSamplesPerSec=%ld !\n", + lpDesc->lpFormat->wFormatTag, lpDesc->lpFormat->nChannels, + lpDesc->lpFormat->nSamplesPerSec); + return WAVERR_BADFORMAT; + } + + if (dwFlags & WAVE_FORMAT_QUERY) { + TRACE("Query format: tag=%04X nChannels=%d nSamplesPerSec=%ld !\n", + lpDesc->lpFormat->wFormatTag, lpDesc->lpFormat->nChannels, + lpDesc->lpFormat->nSamplesPerSec); + return MMSYSERR_NOERROR; + } + + wwi = &WInDev[wDevID]; + + /* direct sound not supported, ignore the flag */ + dwFlags &= ~WAVE_DIRECTSOUND; + + wwi->wFlags = HIWORD(dwFlags & CALLBACK_TYPEMASK); + + memcpy(&wwi->waveDesc, lpDesc, sizeof(WAVEOPENDESC)); + memcpy(&wwi->format, lpDesc->lpFormat, sizeof(PCMWAVEFORMAT)); + + if (wwi->format.wBitsPerSample == 0) { + WARN("Resetting zerod wBitsPerSample\n"); + wwi->format.wBitsPerSample = 8 * + (wwi->format.wf.nAvgBytesPerSec / + wwi->format.wf.nSamplesPerSec) / + wwi->format.wf.nChannels; + } + + wwi->record_stream = arts_record_stream(wwi->format.wf.nSamplesPerSec, + wwi->format.wBitsPerSample, + wwi->format.wf.nChannels, + "winearts"); + TRACE("(wwi->record_stream=%p)\n",wwi->record_stream); + wwi->state = WINE_WS_STOPPED; + + wwi->packetSettings = arts_stream_set(wwi->record_stream, ARTS_P_PACKET_SETTINGS, WAVEIN_PACKET_SETTINGS); + TRACE("Tried to set ARTS_P_PACKET_SETTINGS to (%x), actually set to (%x)\n", WAVEIN_PACKET_SETTINGS, wwi->packetSettings); + TRACE("Buffer size is now (%d)\n", arts_stream_get(wwi->record_stream, ARTS_P_BUFFER_SIZE)); + + if (wwi->lpQueuePtr) { + WARN("Should have an empty queue (%p)\n", wwi->lpQueuePtr); + wwi->lpQueuePtr = NULL; + } + arts_stream_set(wwi->record_stream, ARTS_P_BLOCKING, 0); /* disable blocking on this stream */ + + if(!wwi->record_stream) return MMSYSERR_ALLOCATED; + + wwi->dwRecordedTotal = 0; + wwi->wFlags = HIWORD(dwFlags & CALLBACK_TYPEMASK); + + ARTS_InitRingMessage(&wwi->msgRing); + + /* create recorder thread */ + if (!(dwFlags & WAVE_DIRECTSOUND)) { + wwi->hStartUpEvent = CreateEventA(NULL, FALSE, FALSE, NULL); + wwi->hThread = CreateThread(NULL, 0, widRecorder, (LPVOID)(DWORD)wDevID, 0, &(wwi->dwThreadID)); + WaitForSingleObject(wwi->hStartUpEvent, INFINITE); + CloseHandle(wwi->hStartUpEvent); + } else { + wwi->hThread = INVALID_HANDLE_VALUE; + wwi->dwThreadID = 0; + } + wwi->hStartUpEvent = INVALID_HANDLE_VALUE; + + TRACE("wBitsPerSample=%u, nAvgBytesPerSec=%lu, nSamplesPerSec=%lu, nChannels=%u nBlockAlign=%u!\n", + wwi->format.wBitsPerSample, wwi->format.wf.nAvgBytesPerSec, + wwi->format.wf.nSamplesPerSec, wwi->format.wf.nChannels, + wwi->format.wf.nBlockAlign); + return widNotifyClient(wwi, WIM_OPEN, 0L, 0L); +} + +/************************************************************************** + * widClose [internal] + */ +static DWORD widClose(WORD wDevID) +{ + WINE_WAVEIN* wwi; + + TRACE("(%u);\n", wDevID); + if (wDevID >= MAX_WAVEINDRV || WInDev[wDevID].state == WINE_WS_CLOSED) { + WARN("can't close !\n"); + return MMSYSERR_INVALHANDLE; + } + + wwi = &WInDev[wDevID]; + + if (wwi->lpQueuePtr != NULL) { + WARN("still buffers open !\n"); + return WAVERR_STILLPLAYING; + } + + ARTS_AddRingMessage(&wwi->msgRing, WINE_WM_CLOSING, 0, TRUE); + ARTS_CloseWaveInDevice(wwi); + wwi->state = WINE_WS_CLOSED; + ARTS_DestroyRingMessage(&wwi->msgRing); + return widNotifyClient(wwi, WIM_CLOSE, 0L, 0L); +} + +/************************************************************************** + * widAddBuffer [internal] + */ +static DWORD widAddBuffer(WORD wDevID, LPWAVEHDR lpWaveHdr, DWORD dwSize) +{ + TRACE("(%u, %p, %08lX);\n", wDevID, lpWaveHdr, dwSize); + + if (wDevID >= MAX_WAVEINDRV || WInDev[wDevID].state == WINE_WS_CLOSED) { + WARN("can't do it !\n"); + return MMSYSERR_INVALHANDLE; + } + if (!(lpWaveHdr->dwFlags & WHDR_PREPARED)) { + TRACE("never been prepared !\n"); + return WAVERR_UNPREPARED; + } + if (lpWaveHdr->dwFlags & WHDR_INQUEUE) { + TRACE("header already in use !\n"); + return WAVERR_STILLPLAYING; + } + + lpWaveHdr->dwFlags |= WHDR_INQUEUE; + lpWaveHdr->dwFlags &= ~WHDR_DONE; + lpWaveHdr->dwBytesRecorded = 0; + lpWaveHdr->lpNext = NULL; + + ARTS_AddRingMessage(&WInDev[wDevID].msgRing, WINE_WM_HEADER, (DWORD)lpWaveHdr, FALSE); + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widPrepare [internal] + */ +static DWORD widPrepare(WORD wDevID, LPWAVEHDR lpWaveHdr, DWORD dwSize) +{ + TRACE("(%u, %p, %08lX);\n", wDevID, lpWaveHdr, dwSize); + + if (wDevID >= MAX_WAVEINDRV) return MMSYSERR_INVALHANDLE; + + if (lpWaveHdr->dwFlags & WHDR_INQUEUE) + return WAVERR_STILLPLAYING; + + lpWaveHdr->dwFlags |= WHDR_PREPARED; + lpWaveHdr->dwFlags &= ~WHDR_DONE; + lpWaveHdr->dwBytesRecorded = 0; + + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widUnprepare [internal] + */ +static DWORD widUnprepare(WORD wDevID, LPWAVEHDR lpWaveHdr, DWORD dwSize) +{ + TRACE("(%u, %p, %08lX);\n", wDevID, lpWaveHdr, dwSize); + if (wDevID >= MAX_WAVEINDRV) { + WARN("bad device ID !\n"); + return MMSYSERR_INVALHANDLE; + } + + if (lpWaveHdr->dwFlags & WHDR_INQUEUE) { + TRACE("Still playing...\n"); + return WAVERR_STILLPLAYING; + } + + lpWaveHdr->dwFlags &= ~WHDR_PREPARED; + lpWaveHdr->dwFlags |= WHDR_DONE; + + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widStart [internal] + */ +static DWORD widStart(WORD wDevID) +{ + TRACE("(%u);\n", wDevID); + if (wDevID >= MAX_WAVEINDRV || WInDev[wDevID].state == WINE_WS_CLOSED) { + WARN("can't start recording !\n"); + return MMSYSERR_INVALHANDLE; + } + + ARTS_AddRingMessage(&WInDev[wDevID].msgRing, WINE_WM_STARTING, 0, TRUE); + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widStop [internal] + */ +static DWORD widStop(WORD wDevID) +{ + TRACE("(%u);\n", wDevID); + if (wDevID >= MAX_WAVEINDRV || WInDev[wDevID].state == WINE_WS_CLOSED) { + WARN("can't stop !\n"); + return MMSYSERR_INVALHANDLE; + } + + ARTS_AddRingMessage(&WInDev[wDevID].msgRing, WINE_WM_STOPPING, 0, TRUE); + + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widReset [internal] + */ +static DWORD widReset(WORD wDevID) +{ + TRACE("(%u);\n", wDevID); + if (wDevID >= MAX_WAVEINDRV || WInDev[wDevID].state == WINE_WS_CLOSED) { + WARN("can't reset !\n"); + return MMSYSERR_INVALHANDLE; + } + ARTS_AddRingMessage(&WInDev[wDevID].msgRing, WINE_WM_RESETTING, 0, TRUE); + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widMessage (WINEARTS.6) + */ +DWORD WINAPI ARTS_widMessage(UINT wDevID, UINT wMsg, DWORD dwUser, + DWORD dwParam1, DWORD dwParam2) +{ + TRACE("(%u, %04X, %08lX, %08lX, %08lX);\n", + wDevID, wMsg, dwUser, dwParam1, dwParam2); + switch (wMsg) { + case DRVM_INIT: + case DRVM_EXIT: + case DRVM_ENABLE: + case DRVM_DISABLE: + /* FIXME: Pretend this is supported */ + return 0; + case WIDM_OPEN: return widOpen (wDevID, (LPWAVEOPENDESC)dwParam1, dwParam2); + case WIDM_CLOSE: return widClose (wDevID); + case WIDM_ADDBUFFER: return widAddBuffer (wDevID, (LPWAVEHDR)dwParam1, dwParam2); + case WIDM_PREPARE: return widPrepare (wDevID, (LPWAVEHDR)dwParam1, dwParam2); + case WIDM_UNPREPARE: return widUnprepare (wDevID, (LPWAVEHDR)dwParam1, dwParam2); + case WIDM_GETDEVCAPS: return widGetDevCaps (wDevID, (LPWAVEINCAPSA)dwParam1, dwParam2); + case WIDM_GETNUMDEVS: return widGetNumDevs (); + case WIDM_RESET: return widReset (wDevID); + case WIDM_START: return widStart (wDevID); + case WIDM_STOP: return widStop (wDevID); + default: + FIXME("unknown message %d!\n", wMsg); + } + return MMSYSERR_NOTSUPPORTED; +} + +/*======================================================================* * Low level DSOUND implementation * *======================================================================*/ static DWORD wodDsCreate(UINT wDevID, PIDSDRIVER* drv) @@ -1430,6 +2062,16 @@ * wodMessage (WINEARTS.@) */ DWORD WINAPI ARTS_wodMessage(WORD wDevID, WORD wMsg, DWORD dwUser, + DWORD dwParam1, DWORD dwParam2) +{ + FIXME("(%u, %04X, %08lX, %08lX, %08lX):stub\n", wDevID, wMsg, dwUser, dwParam1, dwParam2); + return MMSYSERR_NOTENABLED; +} + +/************************************************************************** + * widMessage (WINEARTS.6) + */ +DWORD WINAPI ARTS_widMessage(UINT wDevID, UINT wMsg, DWORD dwUser, DWORD dwParam1, DWORD dwParam2) { FIXME("(%u, %04X, %08lX, %08lX, %08lX):stub\n", wDevID, wMsg, dwUser, dwParam1, dwParam2);

3 4

Re: Wineconf update, RFC re remote participation
by Brian Vincent (C) 08 Jan '04

08 Jan '04

> p.s. If someone out there is thinking: of course you could do that, > if would be trivial if you just did 'X', please feel free to share X > with me. Otherwise, we'll have to investigate the open pbx project > and the possibility of getting some Quicknet cards... I have an 8 port conference bridge we can use. Unfortunately I can't provide toll free access. It will be long distance from MN too because I can't bring the PBX. If there's going to be more than 8 callers, I have another bridge available that will accomodate 32. I prefer not to use that one though. The neat solution would be to use the asterisk.org software to set up a PBX with a SIP stack. Then international folks could just use the Internet to participate. I've never used Asterisk though, so it's hard to say how much work would be involved setting that up. Is there a local LUG that would be willing to set something like that up? I imagine there's some geek in MN with all the equipment in his closet. -brian

1 0

Broken Mandrake packages
by Mike Hearn 08 Jan '04

08 Jan '04

Hi, I don't know who maintains the mandrake packages, but it appears that they incorrectly install libwine.so.1 into /usr/lib/wine instead of /usr/lib, and therefore all Wine apps fail to start with an unresolved import failure. Could whoever is responsible for these packages please double check the specfiles? thanks -mike

1 0

More on "no keyboard events in ddraw application"
by Robert Glowczynski 08 Jan '04

08 Jan '04

Hello, I had the same problem as Oleg Prokhorov (no keyboard input in fullscreen games) and following patch fixed it (just a single line in Randr and XVid drivers). I do not know if something gets broken by it; I have tested it with Railroad Tycoon II demo. --- wine-20031212/dlls/x11drv/xvidmode.c.orig 2003-11-26 19:59:36.000000000 -0500 +++ wine-20031212/dlls/x11drv/xvidmode.c 2004-01-06 15:57:58.000000000 -0500 @@ -143,6 +143,7 @@ #else XWarpPointer(gdi_display, None, DefaultRootWindow(gdi_display), 0, 0, 0, 0, 0, 0); #endif + XSetInputFocus(gdi_display, DefaultRootWindow(gdi_display), RevertToPointerRoot, CurrentTime); XSync(gdi_display, False); wine_tsx11_unlock(); } --- wine-20031212/dlls/x11drv/xrandr.c.orig 2004-01-06 16:00:30.000000000 -0500 +++ wine-20031212/dlls/x11drv/xrandr.c 2004-01-06 16:00:10.000000000 -0500 @@ -174,6 +174,8 @@ { ERR("Resolution change not successful -- perhaps display has chaned?"); } + XSetInputFocus(gdi_display, DefaultRootWindow(gdi_display), RevertToPointerRoot, CurrentTime); + XRRFreeScreenConfigInfo(sc); wine_tsx11_unlock(); } Thank you for great work, wine developers! -- ::Robert Glowczynski ::email: robertg(a)aurox.org ::Aurox Core Team http://www.aurox.org ::http://www.distrowatch.com/table.php?distribution=aurox

2 1

www.winehq.org down?
by Michael Stefaniuc 08 Jan '04

08 Jan '04

Hello, is the www.winehq.org website down? The host is pingable and port 80 is open but i get no data after the initial tcp connect. 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

3 2

wintab work
by Aric Stewart 08 Jan '04

08 Jan '04

Sorry all, This is way way way _way_ overdue. But it is really the first time i have had a chance to really take some time and review the changes Alexandre gave me, retest everything and put together a patch against the tip. I did some quick testing and it appears that this will work. I have broken it into 2 patches wine_wintab.diff is all the wintab work except for the x11drv stuff wine_x11_wintab.diff is the changes to x11drv. the reason for this is because i still have the ime patch that i submitted earlier in my wine tree so i had to had edit that x11 patch to try to make it not dependent on the xim stuff being already applied. This make there a chance that there are bits that may not apply cleanly, and if you are committing both of my patches (xim and this) then they wont apply cleanly without a bit of fudging. I am also giving you 2 test applications i used for wintab testing. SYSPRESS.EXE and TILTTEST.EXE These applications helped alot on testing things. They where found on the wacom developers site, i think i still have the source kicking around somewhere. Changelog: Enables Tablet support with both Tilt and Pressure -aric Index: dlls/wintab32/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/wintab32/Makefile.in,v retrieving revision 1.3 diff -u -w -r1.3 Makefile.in --- dlls/wintab32/Makefile.in 11 Oct 2003 01:09:16 -0000 1.3 +++ dlls/wintab32/Makefile.in 8 Jan 2004 14:57:45 -0000 @@ -3,14 +3,15 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = wintab32.dll -IMPORTS = kernel32 +IMPORTS = kernel32 user32 ALTNAMES = wintab.dll SPEC_SRCS16 = $(ALTNAMES:.dll=.spec) C_SRCS = \ context.c \ - manager.c + manager.c \ + wintab32.c C_SRCS16 = \ wintab16.c Index: dlls/wintab32/context.c =================================================================== RCS file: /home/wine/wine/dlls/wintab32/context.c,v retrieving revision 1.2 diff -u -w -r1.2 context.c --- dlls/wintab32/context.c 5 Sep 2003 23:08:26 -0000 1.2 +++ dlls/wintab32/context.c 8 Jan 2004 14:57:46 -0000 @@ -2,6 +2,7 @@ * Tablet Context * * Copyright 2002 Patrik Stridvall + * Copyright 2003 CodeWeavers, Aric Stewart * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -19,29 +20,340 @@ */ #include "config.h" - +#include <stdio.h> +#include <stdlib.h> #include <stdarg.h> #include "windef.h" -#include "winbase.h" #include "winerror.h" +#include "winbase.h" +#include "winuser.h" +#include "user.h" #include "wintab.h" +#include "wintab_internal.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(wintab32); +/* + * Documentation found at + * http://www.csl.sony.co.jp/projects/ar/restricted/wintabl.html + */ + +BOOL gLoaded= FALSE; + +LPOPENCONTEXT gOpenContexts = NULL; +INT gContextCount = 0; +HCTX gTopContext = (HCTX)0xc00; + +extern HWND hwndDefault; +extern CRITICAL_SECTION csTablet; + +char* DUMPBITS(int x, char* buf) +{ + strcpy(buf,"{"); + if (x&PK_CONTEXT) strcat(buf,"PK_CONTEXT "); + if (x&PK_STATUS) strcat(buf, "PK_STATUS "); + if (x&PK_TIME) strcat(buf, "PK_TIME "); + if (x&PK_CHANGED) strcat(buf, "PK_CHANGED "); + if (x&PK_SERIAL_NUMBER) strcat(buf, "PK_SERIAL_NUMBER "); + if (x&PK_CURSOR) strcat(buf, "PK_CURSOR "); + if (x&PK_BUTTONS) strcat(buf, "PK_BUTTONS "); + if (x&PK_X) strcat(buf, "PK_X "); + if (x&PK_Y) strcat(buf, "PK_Y "); + if (x&PK_Z) strcat(buf, "PK_Z "); + if (x&PK_NORMAL_PRESSURE) strcat(buf, "PK_NORMAL_PRESSURE "); + if (x&PK_TANGENT_PRESSURE) strcat(buf, "PK_TANGENT_PRESSURE "); + if (x&PK_ORIENTATION) strcat(buf, "PK_ORIENTATION "); + if (x&PK_ROTATION) strcat(buf, "PK_ROTATION "); + strcat(buf, "}"); + return buf; +} + +static inline void DUMPPACKET(WTPACKET packet) +{ + TRACE("pkContext: 0x%x pkStatus: 0x%x pkTime : 0x%x pkChanged: 0x%x pkSerialNumber: 0x%x pkCursor : %i pkButtons: %x pkX: %li pkY: %li pkZ: %li pkNormalPressure: %i pkTangentPressure: %i pkOrientation: (%i,%i,%i) pkRotation: (%i,%i,%i)\n" +,(UINT)packet.pkContext, + (UINT)packet.pkStatus, + (UINT)packet.pkTime, + (UINT)packet.pkChanged, + packet.pkSerialNumber, + packet.pkCursor, + (UINT)packet.pkButtons, + packet.pkX, + packet.pkY, + packet.pkZ, + packet.pkNormalPressure, + packet.pkTangentPressure, + packet.pkOrientation.orAzimuth, + packet.pkOrientation.orAltitude, packet.pkOrientation.orTwist, + packet.pkRotation.roPitch, + packet.pkRotation.roRoll, packet.pkRotation.roYaw); +} + +static inline void DUMPCONTEXT(LOGCONTEXTA lc) +{ + CHAR mmsg[4000]; + CHAR bits[100]; + CHAR bits1[100]; + CHAR bits2[100]; + + sprintf(mmsg,"%s, %x, %x, %x, %x, %x, %x, %x%s, %x%s, %x%s, %x, %x, %i, %i, %i, %li ,%li, %li, %li, %li, %li,%li, %li, %li, %li, %li, %li, %i, %i, %i, %i, %i %li %li\n", + debugstr_a(lc.lcName), lc.lcOptions, lc.lcStatus, lc.lcLocks, lc.lcMsgBase, +lc.lcDevice, lc.lcPktRate, (UINT)lc.lcPktData, DUMPBITS(lc.lcPktData,bits), +(UINT)lc.lcPktMode, DUMPBITS(lc.lcPktMode,bits1), (UINT)lc.lcMoveMask, +DUMPBITS(lc.lcMoveMask,bits2), (INT)lc.lcBtnDnMask, (INT)lc.lcBtnUpMask, +(INT)lc.lcInOrgX, (INT)lc.lcInOrgY, (INT)lc.lcInOrgZ, lc.lcInExtX, lc.lcInExtY, +lc.lcInExtZ, lc.lcOutOrgX, lc.lcOutOrgY, lc.lcOutOrgZ, lc.lcOutExtX, +lc.lcOutExtY, lc.lcOutExtZ, lc.lcSensX, lc.lcSensY, lc.lcSensZ, lc.lcSysMode, +lc.lcSysOrgX, lc.lcSysOrgY, lc.lcSysExtX, lc.lcSysExtY, lc.lcSysSensX, +lc.lcSysSensY); + TRACE("context: %s",mmsg); +} + + +/* Find an open context given the handle */ +LPOPENCONTEXT TABLET_FindOpenContext(HCTX hCtx) +{ + LPOPENCONTEXT ptr = gOpenContexts; + while (ptr) + { + if (ptr->handle == hCtx) return ptr; + ptr = ptr->next; + } + return NULL; +} + +static void LoadTablet() +{ + TRACE("Initilizing the tablet to hwnd 0x%x\n",(INT)hwndDefault); + gLoaded= TRUE; + pLoadTabletInfo(hwndDefault); +} + +int TABLET_PostTabletMessage(LPOPENCONTEXT newcontext, UINT msg, WPARAM wParam, + LPARAM lParam, BOOL send_always) +{ + if ((send_always) || (newcontext->context.lcOptions & CXO_MESSAGES)) + { + TRACE("Posting message %x to %x\n",msg, (UINT)newcontext->hwndOwner); + return PostMessageA(newcontext->hwndOwner, msg, wParam, lParam); + } + return 0; +} + +static inline DWORD ScaleForContext(DWORD In, DWORD InOrg, DWORD InExt, DWORD + OutOrg, DWORD OutExt) +{ + if (((InExt > 0 )&&(OutExt > 0)) || ((InExt<0) && (OutExt < 0))) + return ((In - InOrg) * abs(OutExt) / abs(InExt)) + OutOrg; + else + return ((abs(InExt) - (In - InOrg))*abs(OutExt) / abs(InExt)) + OutOrg; +} + +LPOPENCONTEXT FindOpenContext(HWND hwnd) +{ + LPOPENCONTEXT ptr=NULL; + ptr = gOpenContexts; + while (ptr) + { + TRACE("Trying Context %lx (%x %x)\n",(LONG)ptr->handle,(INT)hwnd, + (INT)ptr->hwndOwner); + + if (ptr->hwndOwner == hwnd) + return ptr; + } + return NULL; +} + +LPOPENCONTEXT AddPacketToContextQueue(LPWTPACKET packet, HWND hwnd) +{ + LPOPENCONTEXT ptr=NULL; + + EnterCriticalSection(&csTablet); + + ptr = gOpenContexts; + while (ptr) + { + TRACE("Trying Queue %lx (%x %x)\n",(LONG)ptr->handle,(INT)hwnd, + (INT)ptr->hwndOwner); + + if (ptr->hwndOwner == hwnd) + { + int tgt; + if (!ptr->enabled) + { + ptr = ptr->next; + continue; + } + + tgt = ptr->PacketsQueued; + + packet->pkContext = ptr->handle; + + /* translate packet data to the context */ + + /* Scale as per documentation */ + packet->pkY = ScaleForContext(packet->pkY, ptr->context.lcInOrgY, + ptr->context.lcInExtY, ptr->context.lcOutOrgY, + ptr->context.lcOutExtY); + + packet->pkX = ScaleForContext(packet->pkX, ptr->context.lcInOrgX, + ptr->context.lcInExtX, ptr->context.lcOutOrgX, + ptr->context.lcOutExtX); + + /* flip the Y axis */ + if (ptr->context.lcOutExtY > 0) + packet->pkY = ptr->context.lcOutExtY - packet->pkY; + + DUMPPACKET(*packet); + + if (tgt + 1 == ptr->QueueSize) + { + TRACE("Queue Overflow %p\n",ptr->handle); + packet->pkStatus = TPS_QUEUE_ERR; + } + else + { + TRACE("Placed in queue %p index %i\n",ptr->handle,tgt); + memcpy(&ptr->PacketQueue[tgt], packet, sizeof + (WTPACKET)); + ptr->PacketsQueued++; + + if (ptr->ActiveCursor != packet->pkCursor) + { + ptr->ActiveCursor = packet->pkCursor; + if (ptr->context.lcOptions & CXO_CSRMESSAGES) + TABLET_PostTabletMessage(ptr, WT_CSRCHANGE, + (WPARAM)packet->pkSerialNumber, (LPARAM)ptr->handle, + FALSE); + } + } + break; + } + ptr = ptr->next; + } + LeaveCriticalSection(&csTablet); + TRACE("Done (%p)\n",ptr); + return ptr; +} + +int static inline CopyTabletData(LPVOID target, LPVOID src, INT size) +{ + memcpy(target,src,size); + return(size); +} + +static INT TABLET_FindPacket(LPOPENCONTEXT context, UINT wSerial, + LPWTPACKET *pkt) +{ + int loop; + int index = -1; + for (loop = 0; loop < context->PacketsQueued; loop++) + if (context->PacketQueue[loop].pkSerialNumber == wSerial) + { + index = loop; + *pkt = &context->PacketQueue[loop]; + break; + } + + TRACE("%i .. %i\n",context->PacketsQueued,index); + + return index; +} + + +static LPVOID TABLET_CopyPacketData(LPOPENCONTEXT context, LPVOID lpPkt, + LPWTPACKET wtp) +{ + LPBYTE ptr; + CHAR bits[100]; + + ptr = lpPkt; + TRACE("Packet Bits %s\n",DUMPBITS(context->context.lcPktData,bits)); + + if (context->context.lcPktData & PK_CONTEXT) + ptr+=CopyTabletData(ptr,&wtp->pkContext,sizeof(HCTX)); + if (context->context.lcPktData & PK_STATUS) + ptr+=CopyTabletData(ptr,&wtp->pkStatus,sizeof(UINT)); + if (context->context.lcPktData & PK_TIME) + ptr+=CopyTabletData(ptr,&wtp->pkTime,sizeof(LONG)); + if (context->context.lcPktData & PK_CHANGED) + ptr+=CopyTabletData(ptr,&wtp->pkChanged,sizeof(WTPKT)); + if (context->context.lcPktData & PK_SERIAL_NUMBER) + ptr+=CopyTabletData(ptr,&wtp->pkChanged,sizeof(UINT)); + if (context->context.lcPktData & PK_CURSOR) + ptr+=CopyTabletData(ptr,&wtp->pkCursor,sizeof(UINT)); + if (context->context.lcPktData & PK_BUTTONS) + ptr+=CopyTabletData(ptr,&wtp->pkButtons,sizeof(DWORD)); + if (context->context.lcPktData & PK_X) + ptr+=CopyTabletData(ptr,&wtp->pkX,sizeof(DWORD)); + if (context->context.lcPktData & PK_Y) + ptr+=CopyTabletData(ptr,&wtp->pkY,sizeof(DWORD)); + if (context->context.lcPktData & PK_Z) + ptr+=CopyTabletData(ptr,&wtp->pkZ,sizeof(DWORD)); + if (context->context.lcPktData & PK_NORMAL_PRESSURE) + ptr+=CopyTabletData(ptr,&wtp->pkNormalPressure,sizeof(UINT)); + if (context->context.lcPktData & PK_TANGENT_PRESSURE) + ptr+=CopyTabletData(ptr,&wtp->pkTangentPressure,sizeof(UINT)); + if (context->context.lcPktData & PK_ORIENTATION) + ptr+=CopyTabletData(ptr,&wtp->pkOrientation,sizeof(ORIENTATION)); + if (context->context.lcPktData & PK_ROTATION) + ptr+=CopyTabletData(ptr,&wtp->pkRotation,sizeof(ROTATION)); + + //TRACE("Copied %i bytes\n",(INT)ptr - (INT)lpPkt); + return ptr; +} + +static VOID TABLET_BlankPacketData(LPOPENCONTEXT context, LPVOID lpPkt, INT n) +{ + int rc = 0; + + if (context->context.lcPktData & PK_CONTEXT) + rc +=sizeof(HCTX); + if (context->context.lcPktData & PK_STATUS) + rc +=sizeof(UINT); + if (context->context.lcPktData & PK_TIME) + rc += sizeof(LONG); + if (context->context.lcPktData & PK_CHANGED) + rc += sizeof(WTPKT); + if (context->context.lcPktData & PK_SERIAL_NUMBER) + rc += sizeof(UINT); + if (context->context.lcPktData & PK_CURSOR) + rc += sizeof(UINT); + if (context->context.lcPktData & PK_BUTTONS) + rc += sizeof(DWORD); + if (context->context.lcPktData & PK_X) + rc += sizeof(DWORD); + if (context->context.lcPktData & PK_Y) + rc += sizeof(DWORD); + if (context->context.lcPktData & PK_Z) + rc += sizeof(DWORD); + if (context->context.lcPktData & PK_NORMAL_PRESSURE) + rc += sizeof(UINT); + if (context->context.lcPktData & PK_TANGENT_PRESSURE) + rc += sizeof(UINT); + if (context->context.lcPktData & PK_ORIENTATION) + rc += sizeof(ORIENTATION); + if (context->context.lcPktData & PK_ROTATION) + rc += sizeof(ROTATION); + + rc *= n; + memset(lpPkt,0,rc); +} + + /*********************************************************************** * WTInfoA (WINTAB32.20) */ UINT WINAPI WTInfoA(UINT wCategory, UINT nIndex, LPVOID lpOutput) { - FIXME("(%u, %u, %p): stub\n", wCategory, nIndex, lpOutput); + if (gLoaded == FALSE) + LoadTablet(); - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); - - return 0; + return pWTInfoA( wCategory, nIndex, lpOutput ); } /*********************************************************************** @@ -61,11 +373,38 @@ */ HCTX WINAPI WTOpenA(HWND hWnd, LPLOGCONTEXTA lpLogCtx, BOOL fEnable) { - FIXME("(%p, %p, %u): stub\n", hWnd, lpLogCtx, fEnable); + LPOPENCONTEXT newcontext; - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + TRACE("(%p, %p, %u)\n", hWnd, lpLogCtx, fEnable); + DUMPCONTEXT(*lpLogCtx); - return NULL; + newcontext = HeapAlloc(GetProcessHeap(), 0 , sizeof(OPENCONTEXT)); + memcpy(&(newcontext->context),lpLogCtx,sizeof(LOGCONTEXTA)); + newcontext->hwndOwner = hWnd; + newcontext->enabled = fEnable; + newcontext->ActiveCursor = -1; + newcontext->QueueSize = 10; + newcontext->PacketsQueued = 0; + newcontext->PacketQueue=HeapAlloc(GetProcessHeap(),0,sizeof(WTPACKET)*10); + newcontext->handle = gTopContext++; + newcontext->next = gOpenContexts; + + EnterCriticalSection(&csTablet); + gOpenContexts = newcontext; + LeaveCriticalSection(&csTablet); + + pAttachEventQueueToTablet(hWnd); + + TABLET_PostTabletMessage(newcontext, WT_CTXOPEN, (WPARAM)newcontext->handle, + newcontext->context.lcStatus, TRUE); + + newcontext->context.lcStatus = CXS_ONTOP; + + TABLET_PostTabletMessage(newcontext, WT_CTXOVERLAP, + (WPARAM)newcontext->handle, + newcontext->context.lcStatus, TRUE); + + return newcontext->handle; } /*********************************************************************** @@ -85,9 +424,32 @@ */ BOOL WINAPI WTClose(HCTX hCtx) { - FIXME("(%p): stub\n", hCtx); + LPOPENCONTEXT context,ptr; - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + TRACE("(%p)\n", hCtx); + + ptr = context = gOpenContexts; + + while ((context->handle != hCtx) && (context)) + { + ptr = context; + context = context->next; + } + if (!context) + return TRUE; + + EnterCriticalSection(&csTablet); + if (context == gOpenContexts) + gOpenContexts = context->next; + else + ptr->next = context->next; + LeaveCriticalSection(&csTablet); + + TABLET_PostTabletMessage(context, WT_CTXCLOSE, (WPARAM)context->handle, + context->context.lcStatus,TRUE); + + HeapFree(GetProcessHeap(),0,context->PacketQueue); + HeapFree(GetProcessHeap(),0,context); return TRUE; } @@ -97,23 +459,74 @@ */ int WINAPI WTPacketsGet(HCTX hCtx, int cMaxPkts, LPVOID lpPkts) { - FIXME("(%p, %d, %p): stub\n", hCtx, cMaxPkts, lpPkts); + int limit; + LPOPENCONTEXT context; + LPVOID ptr = lpPkts; - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + TRACE("(%p, %d, %p)\n", hCtx, cMaxPkts, lpPkts); + if (!hCtx || !lpPkts) return 0; + + context = TABLET_FindOpenContext(hCtx); + TABLET_BlankPacketData(context,lpPkts,cMaxPkts); + + EnterCriticalSection(&csTablet); + if (context->PacketsQueued == 0) + { + LeaveCriticalSection(&csTablet); return 0; } + for(limit = 0; limit < cMaxPkts && limit < context->PacketsQueued; limit++) + ptr=TABLET_CopyPacketData(context ,ptr, &context->PacketQueue[limit]); + + if (limit < context->PacketsQueued) + { + memcpy(context->PacketQueue, &context->PacketQueue[limit], + (context->QueueSize - (limit))*sizeof(WTPACKET)); + } + context->PacketsQueued -= limit; + LeaveCriticalSection(&csTablet); + + TRACE("Copied %i packets\n",limit); + + return limit; +} + /*********************************************************************** * WTPacket (WINTAB32.24) */ BOOL WINAPI WTPacket(HCTX hCtx, UINT wSerial, LPVOID lpPkt) { - FIXME("(%p, %d, %p): stub\n", hCtx, wSerial, lpPkt); + int rc = 0; + LPOPENCONTEXT context; + LPWTPACKET wtp; - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + TRACE("(%p, %d, %p)\n", hCtx, wSerial, lpPkt); - return FALSE; + if (!hCtx) return 0; + + context = TABLET_FindOpenContext(hCtx); + + EnterCriticalSection(&csTablet); + rc = TABLET_FindPacket(context ,wSerial, &wtp); + + if (rc >= 0) + { + if (lpPkt) + TABLET_CopyPacketData(context ,lpPkt, wtp); + + if ((rc+1) < context->QueueSize) + { + memcpy(context->PacketQueue, &context->PacketQueue[rc+1], + (context->QueueSize - (rc+1))*sizeof(WTPACKET)); + } + context->PacketsQueued -= (rc+1); + } + LeaveCriticalSection(&csTablet); + + TRACE("Returning %i\n",rc+1); + return rc+1; } /*********************************************************************** @@ -121,11 +534,16 @@ */ BOOL WINAPI WTEnable(HCTX hCtx, BOOL fEnable) { - FIXME("(%p, %u): stub\n", hCtx, fEnable); + LPOPENCONTEXT context; - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + TRACE("(%p, %u)\n", hCtx, fEnable); - return FALSE; + if (!hCtx) return 0; + + context = TABLET_FindOpenContext(hCtx); + context->enabled = fEnable; + + return TRUE; } /*********************************************************************** @@ -135,9 +553,7 @@ { FIXME("(%p, %u): stub\n", hCtx, fToTop); - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); - - return FALSE; + return TRUE; } /*********************************************************************** @@ -157,11 +573,17 @@ */ BOOL WINAPI WTGetA(HCTX hCtx, LPLOGCONTEXTA lpLogCtx) { - FIXME("(%p, %p): stub\n", hCtx, lpLogCtx); + LPOPENCONTEXT context; - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + TRACE("(%p, %p)\n", hCtx, lpLogCtx); - return FALSE; + if (!hCtx) return 0; + + context = TABLET_FindOpenContext(hCtx); + + memcpy(lpLogCtx,&context->context,sizeof(LOGCONTEXTA)); + + return TRUE; } /*********************************************************************** @@ -253,49 +675,166 @@ */ int WINAPI WTPacketsPeek(HCTX hCtx, int cMaxPkts, LPVOID lpPkts) { - FIXME("(%p, %d, %p): stub\n", hCtx, cMaxPkts, lpPkts); + int limit; + LPOPENCONTEXT context; + LPVOID ptr = lpPkts; - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + TRACE("(%p, %d, %p)\n", hCtx, cMaxPkts, lpPkts); + + if (!hCtx || !lpPkts) return 0; + + context = TABLET_FindOpenContext(hCtx); + EnterCriticalSection(&csTablet); + if (context->PacketsQueued == 0) + { + LeaveCriticalSection(&csTablet); return 0; } + for (limit = 0; limit < cMaxPkts && limit < context->PacketsQueued; limit++) + ptr = TABLET_CopyPacketData(context ,ptr, &context->PacketQueue[limit]); + + LeaveCriticalSection(&csTablet); + TRACE("Copied %i packets\n",limit); + return limit; +} + /*********************************************************************** * WTDataGet (WINTAB32.81) */ int WINAPI WTDataGet(HCTX hCtx, UINT wBegin, UINT wEnd, int cMaxPkts, LPVOID lpPkts, LPINT lpNPkts) { - FIXME("(%p, %u, %u, %d, %p, %p): stub\n", + LPOPENCONTEXT context; + LPVOID ptr = lpPkts; + UINT bgn = 0; + UINT end = 0; + UINT num = 0; + + TRACE("(%p, %u, %u, %d, %p, %p)\n", hCtx, wBegin, wEnd, cMaxPkts, lpPkts, lpNPkts); - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + if (!hCtx) return 0; + context = TABLET_FindOpenContext(hCtx); + + EnterCriticalSection(&csTablet); + if (context->PacketsQueued == 0) + { + LeaveCriticalSection(&csTablet); return 0; } + while (bgn < context->PacketsQueued && + context->PacketQueue[bgn].pkSerialNumber != wBegin) + bgn++; + + end = bgn; + while (end < context->PacketsQueued && + context->PacketQueue[end].pkSerialNumber != wEnd) + end++; + + if (bgn == end == context->PacketsQueued) + { + LeaveCriticalSection(&csTablet); + return 0; + } + + for (num = bgn; num <= end; num++) + ptr = TABLET_CopyPacketData(context ,ptr, &context->PacketQueue[end]); + + /* remove read packets */ + if ((end+1) < context->PacketsQueued) + memcpy( &context->PacketQueue[bgn], &context->PacketQueue[end+1], + (context->PacketsQueued - ((end-bgn)+1)) * sizeof (WTPACKET)); + + context->PacketsQueued -= ((end-bgn)+1); + *lpNPkts = ((end-bgn)+1); + + LeaveCriticalSection(&csTablet); + TRACE("Copied %i packets\n",*lpNPkts); + return (end - bgn)+1; +} + /*********************************************************************** * WTDataPeek (WINTAB32.82) */ int WINAPI WTDataPeek(HCTX hCtx, UINT wBegin, UINT wEnd, int cMaxPkts, LPVOID lpPkts, LPINT lpNPkts) { - FIXME("(%p, %u, %u, %d, %p, %p): stub\n", + LPOPENCONTEXT context; + LPVOID ptr = lpPkts; + UINT bgn = 0; + UINT end = 0; + UINT num = 0; + + TRACE("(%p, %u, %u, %d, %p, %p)\n", hCtx, wBegin, wEnd, cMaxPkts, lpPkts, lpNPkts); - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + if (!hCtx) return 0; + + context = TABLET_FindOpenContext(hCtx); + + EnterCriticalSection(&csTablet); + if (context->PacketsQueued == 0) + { + LeaveCriticalSection(&csTablet); + return 0; + } + while (bgn < context->PacketsQueued && + context->PacketQueue[bgn].pkSerialNumber != wBegin) + bgn++; + + end = bgn; + while (end < context->PacketsQueued && + context->PacketQueue[end].pkSerialNumber != wEnd) + end++; + + if (bgn == context->PacketsQueued || end == context->PacketsQueued) + { + TRACE("%i %i %i \n", bgn, end, context->PacketsQueued); + LeaveCriticalSection(&csTablet); return 0; } + for (num = bgn; num <= end; num++) + ptr = TABLET_CopyPacketData(context ,ptr, &context->PacketQueue[end]); + + *lpNPkts = ((end-bgn)+1); + LeaveCriticalSection(&csTablet); + + TRACE("Copied %i packets\n",*lpNPkts); + return (end - bgn)+1; +} + /*********************************************************************** * WTQueuePacketsEx (WINTAB32.200) */ BOOL WINAPI WTQueuePacketsEx(HCTX hCtx, UINT *lpOld, UINT *lpNew) { - FIXME("(%p, %p, %p): stub\n", hCtx, lpOld, lpNew); + LPOPENCONTEXT context; - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + TRACE("(%p, %p, %p)\n", hCtx, lpOld, lpNew); + + if (!hCtx) return 0; + + context = TABLET_FindOpenContext(hCtx); + + EnterCriticalSection(&csTablet); + if (context->PacketsQueued) + { + *lpOld = context->PacketQueue[0].pkSerialNumber; + *lpNew = context->PacketQueue[context->PacketsQueued-1].pkSerialNumber; + } + else + { + TRACE("No packets\n"); + LeaveCriticalSection(&csTablet); + return FALSE; + } + LeaveCriticalSection(&csTablet); return TRUE; } @@ -305,11 +844,13 @@ */ int WINAPI WTQueueSizeGet(HCTX hCtx) { - FIXME("(%p): stub\n", hCtx); + LPOPENCONTEXT context; + TRACE("(%p)\n", hCtx); - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + if (!hCtx) return 0; - return 0; + context = TABLET_FindOpenContext(hCtx); + return context->QueueSize; } /*********************************************************************** @@ -317,9 +858,20 @@ */ BOOL WINAPI WTQueueSizeSet(HCTX hCtx, int nPkts) { - FIXME("(%p, %d): stub\n", hCtx, nPkts); + LPOPENCONTEXT context; - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + TRACE("(%p, %d)\n", hCtx, nPkts); - return 0; + if (!hCtx) return 0; + + context = TABLET_FindOpenContext(hCtx); + + EnterCriticalSection(&csTablet); + context->PacketQueue = HeapReAlloc(GetProcessHeap(), 0, + context->PacketQueue, sizeof(WTPACKET)*nPkts); + + context->QueueSize = nPkts; + LeaveCriticalSection(&csTablet); + + return nPkts; } --- /dev/null Thu Aug 30 15:30:55 2001 +++ dlls/wintab32/wintab32.c Thu Jan 8 08:47:13 2004 @@ -0,0 +1,155 @@ +/* + * WinTab32 library + * + * Copyright 2003 CodeWeavers, Aric Stewart + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <stdarg.h> + +#include "windef.h" +#include "winbase.h" +#include "wingdi.h" +#include "winuser.h" +#include "winerror.h" +#include "wintab.h" +#include "wintab_internal.h" +#include "wine/debug.h" + +WINE_DEFAULT_DEBUG_CHANNEL(wintab32); + +HWND hwndDefault = (HWND)NULL; +static HANDLE hTabletInst; +static const WCHAR +WC_TABLETCLASSNAME[] = {'W','i','n','e','T','a','b','l','e','t','C','l','a','s','s',0}; +CRITICAL_SECTION csTablet; + +UINT (*pWTInfoA)(UINT wCategory, UINT nIndex, LPVOID lpOutput) = NULL; + +static LRESULT WINAPI TABLET_WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, + LPARAM lParam); + +static VOID TABLET_Register() +{ + WNDCLASSW wndClass; + ZeroMemory(&wndClass, sizeof(WNDCLASSW)); + wndClass.style = CS_GLOBALCLASS; + wndClass.lpfnWndProc = (WNDPROC) TABLET_WindowProc; + wndClass.cbClsExtra = 0; + wndClass.cbWndExtra = 0; + wndClass.hCursor = (HCURSOR)NULL; + wndClass.hbrBackground = (HBRUSH)(COLOR_WINDOW +1); + wndClass.lpszClassName = WC_TABLETCLASSNAME; + RegisterClassW(&wndClass); +} + +static VOID TABLET_Unregister() +{ + UnregisterClassW(WC_TABLETCLASSNAME, (HINSTANCE)NULL); +} + +BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpReserved) +{ + static const WCHAR name[] = {'T','a','b','l','e','t',0}; + static HMODULE hx11drv = NULL; + + TRACE("%p, %lx, %p\n",hInstDLL,fdwReason,lpReserved); + switch (fdwReason) + { + case DLL_PROCESS_ATTACH: + TRACE("Initialization\n"); + InitializeCriticalSection(&csTablet); + hx11drv = LoadLibraryA("x11drv.dll"); + if (hx11drv) + { + pLoadTabletInfo = (X11_LoadTabletInfo*)GetProcAddress(hx11drv, + "LoadTabletInfo"); + pAttachEventQueueToTablet = (X11_AttachEventQueueToTablet*) + GetProcAddress(hx11drv, "AttachEventQueueToTablet"); + pGetCurrentPacket = (X11_GetCurrentPacket*) + GetProcAddress(hx11drv, "GetCurrentPacket"); + pWTInfoA = (void *)GetProcAddress(hx11drv, "WTInfoA"); + TABLET_Register(); + hTabletInst = hInstDLL; + hwndDefault = CreateWindowW(WC_TABLETCLASSNAME, name, + WS_POPUPWINDOW,0,0,0,0,0,0,hTabletInst,0); + } + else + return FALSE; + break; + case DLL_PROCESS_DETACH: + TRACE("Detaching\n"); + if (hx11drv) + { + FreeLibrary(hx11drv); + if (hwndDefault) + { + DestroyWindow(hwndDefault); + hwndDefault = 0; + } + TABLET_Unregister(); + } + DeleteCriticalSection(&csTablet); + break; + } + return TRUE; +} + + +/* + * The window proc for the default TABLET window + */ +static LRESULT WINAPI TABLET_WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, + LPARAM lParam) +{ + TRACE("Incomming Message 0x%x (0x%08x, 0x%08x)\n", uMsg, (UINT)wParam, + (UINT)lParam); + + switch(uMsg) + { + case WM_NCCREATE: + return TRUE; + + case WT_PACKET: + { + WTPACKET packet; + LPOPENCONTEXT handler; + pGetCurrentPacket(&packet); + handler = AddPacketToContextQueue(&packet,(HWND)lParam); + if (handler) + TABLET_PostTabletMessage(handler, WT_PACKET, + (WPARAM)packet.pkSerialNumber, + (LPARAM)handler->handle, FALSE); + break; + } + case WT_PROXIMITY: + { + LPOPENCONTEXT handler; + LPARAM prox; + handler = FindOpenContext((HWND)lParam); + if (handler) + { + prox = wParam | 0x1 << 16; + TABLET_PostTabletMessage(handler, WT_PROXIMITY, + (WPARAM)handler->handle, (LPARAM)prox, + TRUE); + } + break; + } + } + return 0; +} + --- /dev/null Thu Aug 30 15:30:55 2001 +++ dlls/wintab32/wintab_internal.h Thu Jan 8 08:47:13 2004 @@ -0,0 +1,163 @@ +/* + * Tablet header + * + * Copyright 2003 CodeWeavers (Aric Stewart) + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +typedef struct tagWTI_INTERFACE_INFO { + CHAR WINTABID[1024]; + /* a copy of the null-terminated tablet hardware identification string + * in the user buffer. This string should include make, model, and + * revision information in user-readable format. + */ + WORD SPECVERSION; + /* the specification version number. The high-order byte contains the + * major version number; the low-order byte contains the minor version + * number. + */ + WORD IMPLVERSION; + /* the implementation version number. The high-order byte contains the + * major version number; the low-order byte contains the minor version + * number. + */ + UINT NDEVICES; + /* the number of devices supported. */ + UINT NCURSORS; + /* the total number of cursor types supported. */ + UINT NCONTEXTS; + /* the number of contexts supported. */ + UINT CTXOPTIONS; + /* flags indicating which context options are supported */ + UINT CTXSAVESIZE; + /* the size of the save information returned from WTSave.*/ + UINT NEXTENSIONS; + /* the number of extension data items supported.*/ + UINT NMANAGERS; + /* the number of manager handles supported.*/ + }WTI_INTERFACE_INFO, *LPWTI_INTERFACE_INFO; + +typedef struct tagWTI_STATUS_INFO{ + UINT CONTEXTS; + /* the number of contexts currently open.*/ + UINT SYSCTXS; + /* the number of system contexts currently open.*/ + UINT PKTRATE; + /* the maximum packet report rate currently being received by any + * context, in Hertz. + */ + WTPKT PKTDATA; + /* a mask indicating which packet data items are requested by at + * least one context. + */ + UINT MANAGERS; + /* the number of manager handles currently open.*/ + BOOL SYSTEM; + /* a non-zero value if system pointing is available to the whole + * screen; zero otherwise. + */ + DWORD BUTTONUSE; + /* a button mask indicating the logical buttons whose events are + * requested by at least one context. + */ + DWORD SYSBTNUSE; + /* a button mask indicating which logical buttons are assigned a system + * button function by the current cursor's system button map. + */ +} WTI_STATUS_INFO, *LPWTI_STATUS_INFO; + +typedef struct tagWTI_EXTENSIONS_INFO +{ + CHAR NAME[256]; + /* a unique, null-terminated string describing the extension.*/ + UINT TAG; + /* a unique identifier for the extension. */ + WTPKT MASK; + /* a mask that can be bitwise OR'ed with WTPKT-type variables to select + * the extension. + */ + UINT SIZE[2]; + /* an array of two UINTs specifying the extension's size within a packet + * (in bytes). The first is for absolute mode; the second is for + * relative mode. + */ + AXIS *AXES; + /* an array of axis descriptions, as needed for the extension. */ + BYTE *DEFAULT; + /* the current global default data, as needed for the extension. This + * data is modified via the WTMgrExt function. + */ + BYTE *DEFCONTEXT; + BYTE *DEFSYSCTX; + /* the current default context-specific data, as needed for the + * extension. The indices identify the digitizing- and system-context + * defaults, respectively. + */ + BYTE *CURSORS; + /* Is the first of one or more consecutive indices, one per cursor type. + * Each returns the current default cursor-specific data, as need for + * the extension. This data is modified via the WTMgrCsrExt function. + */ +} WTI_EXTENSIONS_INFO, *LPWTI_EXTENSIONS_INFO; + +typedef struct tagWTPACKET { + HCTX pkContext; + UINT pkStatus; + LONG pkTime; + WTPKT pkChanged; + UINT pkSerialNumber; + UINT pkCursor; + DWORD pkButtons; + DWORD pkX; + DWORD pkY; + DWORD pkZ; + UINT pkNormalPressure; + UINT pkTangentPressure; + ORIENTATION pkOrientation; + ROTATION pkRotation; /* 1.1 */ +} WTPACKET, *LPWTPACKET; + +typedef struct tagOPENCONTEXT +{ + HCTX handle; + LOGCONTEXTA context; + HWND hwndOwner; + BOOL enabled; + INT ActiveCursor; + INT QueueSize; + INT PacketsQueued; + LPWTPACKET PacketQueue; + struct tagOPENCONTEXT *next; +} OPENCONTEXT, *LPOPENCONTEXT; + +LPOPENCONTEXT TABLET_FindOpenContext(HCTX hCtx); +int TABLET_PostTabletMessage(LPOPENCONTEXT newcontext, UINT msg, WPARAM wParam, + LPARAM lParam, BOOL send_always); +LPOPENCONTEXT AddPacketToContextQueue(LPWTPACKET packet, HWND hwnd); +LPOPENCONTEXT FindOpenContext(HWND hwnd); + +/* X11drv functions */ +typedef int X11_LoadTabletInfo(HWND hwnddefault); + +typedef int X11_GetCurrentPacket(LPWTPACKET packet); + +typedef int X11_AttachEventQueueToTablet(HWND hOwner); + +X11_LoadTabletInfo *pLoadTabletInfo; +X11_AttachEventQueueToTablet *pAttachEventQueueToTablet; +X11_GetCurrentPacket *pGetCurrentPacket; + +extern UINT (*pWTInfoA)(UINT wCategory, UINT nIndex, LPVOID lpOutput); Index: include/wintab.h =================================================================== RCS file: /home/wine/wine/include/wintab.h,v retrieving revision 1.1 diff -u -w -r1.1 wintab.h --- include/wintab.h 17 Dec 2002 01:49:16 -0000 1.1 +++ include/wintab.h 8 Jan 2004 14:59:11 -0000 @@ -328,7 +328,9 @@ #define CSR_MINPKTDATA 17 /* 1.1 */ #define CSR_MINBUTTONS 18 /* 1.1 */ #define CSR_CAPABILITIES 19 /* 1.1 */ -#define CSR_MAX 19 +/* from http://www.wacomeng.com/devsupport/ibmpc/wacomwindevfaq.html */ +#define CSR_TYPE 20 +#define CSR_MAX 20 #endif Index: dlls/x11drv/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/x11drv/Makefile.in,v retrieving revision 1.38 diff -u -w -r1.38 Makefile.in --- dlls/x11drv/Makefile.in 5 Dec 2003 00:20:28 -0000 1.38 +++ dlls/x11drv/Makefile.in 8 Jan 2004 14:59:54 -0000 @@ -34,10 +34,12 @@ text.c \ window.c \ winpos.c \ + wintab.c \ x11ddraw.c \ x11drv_main.c \ xdnd.c \ Index: dlls/x11drv/event.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/event.c,v retrieving revision 1.30 diff -u -w -r1.30 event.c --- dlls/x11drv/event.c 5 Dec 2003 04:45:50 -0000 1.30 +++ dlls/x11drv/event.c 8 Jan 2004 14:59:54 -0000 @@ -275,8 +277,18 @@ WARN( "Got event %s for unknown Window %08lx\n", event_names[event->type], event->xany.window ); else - TRACE("Got event %s for hwnd %p\n", - event_names[event->type], hWnd ); + if (event->type <= MappingNotify) + TRACE("Got event %s for hwnd/window %p/%lx, GetFocus()=%p\n", + event_names[event->type], hWnd, event->xany.window, GetFocus() ); + else + TRACE("Got extension event for hwnd/window %p/%lx, GetFocus()=%p\n", + hWnd, event->xany.window, GetFocus() ); + + if (X11DRV_ProcessTabletEvent(hWnd, event)) + { + TRACE("Return: filtered by tablet\n"); + return; + } switch(event->type) { RCS file: /home/wine/wine/dlls/x11drv/x11drv.spec,v retrieving revision 1.50 diff -u -w -r1.50 x11drv.spec --- dlls/x11drv/x11drv.spec 26 Nov 2003 22:03:34 -0000 1.50 +++ dlls/x11drv/x11drv.spec 8 Jan 2004 14:59:57 -0000 @@ -114,3 +114,12 @@ # X11 locks @ cdecl -norelay wine_tsx11_lock() @ cdecl -norelay wine_tsx11_unlock() + +# WinTab32 +@ cdecl LoadTabletInfo(long) X11DRV_LoadTabletInfo +@ cdecl AttachEventQueueToTablet(long) X11DRV_AttachEventQueueToTablet +@ cdecl GetCurrentPacket(ptr) X11DRV_GetCurrentPacket +@ cdecl WTInfoA(long long ptr) X11DRV_WTInfoA Index: dlls/x11drv/x11drv_main.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11drv_main.c,v retrieving revision 1.83 diff -u -w -r1.83 x11drv_main.c --- dlls/x11drv/x11drv_main.c 5 Dec 2003 00:11:48 -0000 1.83 +++ dlls/x11drv/x11drv_main.c 8 Jan 2004 14:59:57 -0000 @@ -62,7 +62,10 @@ #include "xrandr.h" #include "dga2.h" #include "wine/server.h" +#include "wine/unicode.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(x11drv); --- /dev/null Thu Aug 30 15:30:55 2001 +++ dlls/x11drv/wintab.c Thu Jan 8 08:47:17 2004 @@ -0,0 +1,1134 @@ +/* + * X11 tablet driver + * + * Copyright 2003 CodeWeavers (Aric Stewart) + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include "config.h" +#include "wine/port.h" + +#include <stdlib.h> +#include <X11/Xlib.h> +#include <X11/extensions/XInput.h> +#include <X11/extensions/XI.h> + +#include "windef.h" +#include "x11drv.h" +#include "wine/debug.h" +#include "wintab.h" + +WINE_DEFAULT_DEBUG_CHANNEL(wintab32); +WINE_DECLARE_DEBUG_CHANNEL(event); + + +typedef struct tagWTI_CURSORS_INFO +{ + CHAR NAME[256]; + /* a displayable zero-terminated string containing the name of the + * cursor. + */ + BOOL ACTIVE; + /* whether the cursor is currently connected. */ + WTPKT PKTDATA; + /* a bit mask indicating the packet data items supported when this + * cursor is connected. + */ + BYTE BUTTONS; + /* the number of buttons on this cursor. */ + BYTE BUTTONBITS; + /* the number of bits of raw button data returned by the hardware.*/ + CHAR BTNNAMES[1024]; /* FIXME: make this dynamic */ + /* a list of zero-terminated strings containing the names of the + * cursor's buttons. The number of names in the list is the same as the + * number of buttons on the cursor. The names are separated by a single + * zero character; the list is terminated by two zero characters. + */ + BYTE BUTTONMAP[32]; + /* a 32 byte array of logical button numbers, one for each physical + * button. + */ + BYTE SYSBTNMAP[32]; + /* a 32 byte array of button action codes, one for each logical + * button. + */ + BYTE NPBUTTON; + /* the physical button number of the button that is controlled by normal + * pressure. + */ + UINT NPBTNMARKS[2]; + /* an array of two UINTs, specifying the button marks for the normal + * pressure button. The first UINT contains the release mark; the second + * contains the press mark. + */ + UINT *NPRESPONSE; + /* an array of UINTs describing the pressure response curve for normal + * pressure. + */ + BYTE TPBUTTON; + /* the physical button number of the button that is controlled by + * tangential pressure. + */ + UINT TPBTNMARKS[2]; + /* an array of two UINTs, specifying the button marks for the tangential + * pressure button. The first UINT contains the release mark; the second + * contains the press mark. + */ + UINT *TPRESPONSE; + /* an array of UINTs describing the pressure response curve for + * tangential pressure. + */ + DWORD PHYSID; + /* a manufacturer-specific physical identifier for the cursor. This + * value will distinguish the physical cursor from others on the same + * device. This physical identifier allows applications to bind + * functions to specific physical cursors, even if category numbers + * change and multiple, otherwise identical, physical cursors are + * present. + */ + UINT MODE; + /* the cursor mode number of this cursor type, if this cursor type has + * the CRC_MULTIMODE capability. + */ + UINT MINPKTDATA; + /* the minimum set of data available from a physical cursor in this + * cursor type, if this cursor type has the CRC_AGGREGATE capability. + */ + UINT MINBUTTONS; + /* the minimum number of buttons of physical cursors in the cursor type, + * if this cursor type has the CRC_AGGREGATE capability. + */ + UINT CAPABILITIES; + /* flags indicating cursor capabilities, as defined below: + CRC_MULTIMODE + Indicates this cursor type describes one of several modes of a + single physical cursor. Consecutive cursor type categories + describe the modes; the CSR_MODE data item gives the mode number + of each cursor type. + CRC_AGGREGATE + Indicates this cursor type describes several physical cursors + that cannot be distinguished by software. + CRC_INVERT + Indicates this cursor type describes the physical cursor in its + inverted orientation; the previous consecutive cursor type + category describes the normal orientation. + */ + UINT TYPE; + /* Manufacturer Unique id for the item type */ +} WTI_CURSORS_INFO, *LPWTI_CURSORS_INFO; + + +typedef struct tagWTI_DEVICES_INFO +{ + CHAR NAME[256]; + /* a displayable null- terminated string describing the device, + * manufacturer, and revision level. + */ + UINT HARDWARE; + /* flags indicating hardware and driver capabilities, as defined + * below: + HWC_INTEGRATED: + Indicates that the display and digitizer share the same surface. + HWC_TOUCH + Indicates that the cursor must be in physical contact with the + device to report position. + HWC_HARDPROX + Indicates that device can generate events when the cursor is + entering and leaving the physical detection range. + HWC_PHYSID_CURSORS + Indicates that device can uniquely identify the active cursor in + hardware. + */ + UINT NCSRTYPES; + /* the number of supported cursor types.*/ + UINT FIRSTCSR; + /* the first cursor type number for the device. */ + UINT PKTRATE; + /* the maximum packet report rate in Hertz. */ + WTPKT PKTDATA; + /* a bit mask indicating which packet data items are always available.*/ + WTPKT PKTMODE; + /* a bit mask indicating which packet data items are physically + * relative, i.e., items for which the hardware can only report change, + * not absolute measurement. + */ + WTPKT CSRDATA; + /* a bit mask indicating which packet data items are only available when + * certain cursors are connected. The individual cursor descriptions + * must be consulted to determine which cursors return which data. + */ + INT XMARGIN; + INT YMARGIN; + INT ZMARGIN; + /* the size of tablet context margins in tablet native coordinates, in + * the x, y, and z directions, respectively. + */ + AXIS X; + AXIS Y; + AXIS Z; + /* the tablet's range and resolution capabilities, in the x, y, and z + * axes, respectively. + */ + AXIS NPRESSURE; + AXIS TPRESSURE; + /* the tablet's range and resolution capabilities, for the normal and + * tangential pressure inputs, respectively. + */ + AXIS ORIENTATION[3]; + /* a 3-element array describing the tablet's orientation range and + * resolution capabilities. + */ + AXIS ROTATION[3]; + /* a 3-element array describing the tablet's rotation range and + * resolution capabilities. + */ + CHAR PNPID[256]; + /* a null-terminated string containing the devices Plug and Play ID.*/ +} WTI_DEVICES_INFO, *LPWTI_DEVICES_INFO; + +typedef struct tagWTPACKET { + HCTX pkContext; + UINT pkStatus; + LONG pkTime; + WTPKT pkChanged; + UINT pkSerialNumber; + UINT pkCursor; + DWORD pkButtons; + DWORD pkX; + DWORD pkY; + DWORD pkZ; + UINT pkNormalPressure; + UINT pkTangentPressure; + ORIENTATION pkOrientation; + ROTATION pkRotation; /* 1.1 */ +} WTPACKET, *LPWTPACKET; + + +static int motion_type = -1; +static int button_press_type = -1; +static int button_release_type = -1; +static int key_press_type = -1; +static int key_release_type = -1; +static int proximity_in_type = -1; +static int proximity_out_type = -1; + +HWND hwndTabletDefault = (HWND)NULL; +WTPACKET gMsgPacket; +static DWORD gSerial = 0; +static INT button_state[10] = {0,0,0,0,0,0,0,0,0,0}; + +#define CURSORMAX 10 + +static LOGCONTEXTA gSysContext; +static WTI_DEVICES_INFO gSysDevice; +static WTI_CURSORS_INFO gSysCursor[CURSORMAX]; +static INT gNumCursors; + + +/* XInput stuff */ +static void *xinput_handle; + +#define MAKE_FUNCPTR(f) static typeof(f) * p##f; +MAKE_FUNCPTR(XListInputDevices) +MAKE_FUNCPTR(XOpenDevice) +MAKE_FUNCPTR(XQueryDeviceState) +MAKE_FUNCPTR(XGetDeviceButtonMapping) +MAKE_FUNCPTR(XCloseDevice) +MAKE_FUNCPTR(XSelectExtensionEvent) +MAKE_FUNCPTR(XFreeDeviceState) +#undef MAKE_FUNCPTR + +INT X11DRV_XInput_Init(void) +{ + xinput_handle = wine_dlopen("libXi.so", RTLD_NOW, NULL, 0); + if (xinput_handle) + { +#define LOAD_FUNCPTR(f) if((p##f = wine_dlsym(xinput_handle, #f, NULL, 0)) == NULL) goto sym_not_found; + LOAD_FUNCPTR(XListInputDevices) + LOAD_FUNCPTR(XOpenDevice) + LOAD_FUNCPTR(XGetDeviceButtonMapping) + LOAD_FUNCPTR(XCloseDevice) + LOAD_FUNCPTR(XSelectExtensionEvent) + LOAD_FUNCPTR(XQueryDeviceState) + LOAD_FUNCPTR(XFreeDeviceState) +#undef LOAD_FUNCPTR + return 1; + } +sym_not_found: + return 0; +} + +void X11DRV_LoadTabletInfo(HWND hwnddefault) +{ + struct x11drv_thread_data *data = x11drv_thread_data(); + int num_devices; + int loop; + int cursor_target; + XDeviceInfo *devices; + XDeviceInfo *target = NULL; + BOOL axis_read_complete= FALSE; + + XAnyClassPtr any; + XButtonInfoPtr Button; + XValuatorInfoPtr Val; + XAxisInfoPtr Axis; + + XDevice *opendevice; + + if (!X11DRV_XInput_Init()) + { + ERR("Unable to initialized the XInput library.\n"); + return; + } + + hwndTabletDefault = hwnddefault; + + /* Do base initializaion */ + strcpy(gSysContext.lcName, "Wine Tablet Context"); + strcpy(gSysDevice.NAME,"Wine Tablet Device"); + + gSysContext.lcOptions = CXO_SYSTEM | CXO_MESSAGES | CXO_CSRMESSAGES; + gSysContext.lcLocks = CXL_INSIZE | CXL_INASPECT | CXL_MARGIN | + CXL_SENSITIVITY | CXL_SYSOUT; + + gSysContext.lcMsgBase= WT_DEFBASE; + gSysContext.lcDevice = 0; + gSysContext.lcPktData = + PK_CONTEXT | PK_STATUS | PK_SERIAL_NUMBER| PK_TIME | PK_CURSOR | + PK_BUTTONS | PK_X | PK_Y | PK_NORMAL_PRESSURE | PK_ORIENTATION; + gSysContext.lcMoveMask= + PK_BUTTONS | PK_X | PK_Y | PK_NORMAL_PRESSURE | PK_ORIENTATION; + gSysContext.lcStatus = CXS_ONTOP; + gSysContext.lcPktRate = 100; + gSysContext.lcBtnDnMask = 0xffffffff; + gSysContext.lcBtnUpMask = 0xffffffff; + gSysContext.lcSensX = 65536; + gSysContext.lcSensY = 65536; + gSysContext.lcSensX = 65536; + gSysContext.lcSensZ = 65536; + gSysContext.lcSysSensX= 65536; + gSysContext.lcSysSensY= 65536; + + /* Device Defaults */ + gSysDevice.HARDWARE = HWC_HARDPROX|HWC_PHYSID_CURSORS; + gSysDevice.FIRSTCSR= 0; + gSysDevice.PKTRATE = 100; + gSysDevice.PKTDATA = + PK_CONTEXT | PK_STATUS | PK_SERIAL_NUMBER| PK_TIME | PK_CURSOR | + PK_BUTTONS | PK_X | PK_Y | PK_NORMAL_PRESSURE | PK_ORIENTATION; + strcpy(gSysDevice.PNPID,"non-pluginplay"); + + wine_tsx11_lock(); + + cursor_target = -1; + devices = pXListInputDevices(data->display, &num_devices); + if (!devices) + { + WARN("XInput Extenstions reported as not avalable\n"); + wine_tsx11_unlock(); + return; + } + for (loop=0; loop < num_devices; loop++) + { + int class_loop; + + TRACE("Trying device %i(%s)\n",loop,devices[loop].name); + if (devices[loop].use == IsXExtensionDevice) + { + LPWTI_CURSORS_INFO cursor; + + TRACE("Is Extension Device\n"); + cursor_target++; + target = &devices[loop]; + cursor = &gSysCursor[cursor_target]; + + opendevice = pXOpenDevice(data->display,target->id); + if (opendevice) + { + unsigned char map[32]; + int i; + int shft = 0; + + pXGetDeviceButtonMapping(data->display, opendevice, map, 32); + + for (i=0; i< cursor->BUTTONS; i++,shft++) + { + cursor->BUTTONMAP[i] = map[i]; + cursor->SYSBTNMAP[i] = (1<<shft); + } + pXCloseDevice(data->display, opendevice); + } + else + { + WARN("Unable to open device %s\n",target->name); + cursor_target --; + continue; + } + + strcpy(cursor->NAME,target->name); + + cursor->ACTIVE = 1; + cursor->PKTDATA = PK_TIME | PK_CURSOR | PK_BUTTONS | PK_X | PK_Y | + PK_NORMAL_PRESSURE | PK_TANGENT_PRESSURE | + PK_ORIENTATION; + + cursor->PHYSID = cursor_target; + cursor->NPBUTTON = 1; + cursor->NPBTNMARKS[0] = 0 ; + cursor->NPBTNMARKS[1] = 1 ; + cursor->CAPABILITIES = 1; + if (strcasecmp(cursor->NAME,"stylus")==0) + cursor->TYPE = 0x4825; + if (strcasecmp(cursor->NAME,"eraser")==0) + cursor->TYPE = 0xc85a; + + + any = (XAnyClassPtr) (target->inputclassinfo); + + for (class_loop = 0; class_loop < target->num_classes; class_loop++) + { + switch (any->class) + { + case ValuatorClass: + if (!axis_read_complete) + { + Val = (XValuatorInfoPtr) any; + Axis = (XAxisInfoPtr) ((char *) Val + sizeof + (XValuatorInfo)); + + if (Val->num_axes>=1) + { + /* Axis 1 is X */ + gSysDevice.X.axMin = Axis->min_value; + gSysDevice.X.axMax= Axis->max_value; + gSysDevice.X.axUnits = 1; + gSysDevice.X.axResolution = Axis->resolution; + gSysContext.lcInOrgX = Axis->min_value; + gSysContext.lcSysOrgX = Axis->min_value; + gSysContext.lcInExtX = Axis->max_value; + gSysContext.lcSysExtX = Axis->max_value; + Axis++; + } + if (Val->num_axes>=2) + { + /* Axis 2 is Y */ + gSysDevice.Y.axMin = Axis->min_value; + gSysDevice.Y.axMax= Axis->max_value; + gSysDevice.Y.axUnits = 1; + gSysDevice.Y.axResolution = Axis->resolution; + gSysContext.lcInOrgY = Axis->min_value; + gSysContext.lcSysOrgY = Axis->min_value; + gSysContext.lcInExtY = Axis->max_value; + gSysContext.lcSysExtY = Axis->max_value; + Axis++; + } + if (Val->num_axes>=3) + { + /* Axis 3 is Normal Pressure */ + gSysDevice.NPRESSURE.axMin = Axis->min_value; + gSysDevice.NPRESSURE.axMax= Axis->max_value; + gSysDevice.NPRESSURE.axUnits = 1; + gSysDevice.NPRESSURE.axResolution = + Axis->resolution; + Axis++; + } + if (Val->num_axes >= 5) + { + /* Axis 4 and 5 are X and Y tilt */ + XAxisInfoPtr XAxis = Axis; + Axis++; + if (max (abs(Axis->max_value), + abs(XAxis->max_value))) + { + gSysDevice.ORIENTATION[0].axMin = 0; + gSysDevice.ORIENTATION[0].axMax = 3600; + gSysDevice.ORIENTATION[0].axUnits = 1; + gSysDevice.ORIENTATION[0].axResolution = + 235929600; + gSysDevice.ORIENTATION[1].axMin = -1000; + gSysDevice.ORIENTATION[1].axMax = 1000; + gSysDevice.ORIENTATION[1].axUnits = 1; + gSysDevice.ORIENTATION[1].axResolution = + 235929600; + Axis++; + } + } + axis_read_complete = TRUE; + } + break; + case ButtonClass: + { + CHAR *ptr = cursor->BTNNAMES; + int i; + + Button = (XButtonInfoPtr) any; + cursor->BUTTONS = Button->num_buttons; + for (i = 0; i < cursor->BUTTONS; i++) + { + strcpy(ptr,cursor->NAME); + ptr+=8; + } + } + break; + } + any = (XAnyClassPtr) ((char*) any + any->length); + } + } + } + wine_tsx11_unlock(); + gSysDevice.NCSRTYPES = cursor_target+1; + gNumCursors = cursor_target+1; +} + +static int figure_deg(int x, int y) +{ + int rc; + + if (y != 0) + { + rc = (int) 10 * (atan( (FLOAT)abs(y) / (FLOAT)abs(x)) / (3.1415 / 180)); + if (y>0) + { + if (x>0) + rc += 900; + else + rc = 2700 - rc; + } + else + { + if (x>0) + rc = 900 - rc; + else + rc += 2700; + } + } + else + { + if (x >= 0) + rc = 900; + else + rc = 2700; + } + + return rc; +} + +static int get_button_state(int deviceid) +{ + return button_state[deviceid]; +} + +static void set_button_state(XID deviceid) +{ + struct x11drv_thread_data *data = x11drv_thread_data(); + XDevice *device; + XDeviceState *state; + XInputClass *class; + int loop; + int rc = 0; + + wine_tsx11_lock(); + device = pXOpenDevice(data->display,deviceid); + state = pXQueryDeviceState(data->display,device); + + if (state) + { + class = state->data; + for (loop = 0; loop < state->num_classes; loop++) + { + if (class->class == ButtonClass) + { + int loop2; + XButtonState *button_state = (XButtonState*)class; + for (loop2 = 1; loop2 <= button_state->num_buttons; loop2++) + { + if (button_state->buttons[loop2 / 8] & (1 << (loop2 % 8))) + { + rc |= (1<<(loop2-1)); + } + } + } + class = (XInputClass *) ((char *) class + class->length); + } + } + pXFreeDeviceState(state); + wine_tsx11_unlock(); + button_state[deviceid] = rc; +} + +int X11DRV_ProcessTabletEvent(HWND hwnd, XEvent *event) +{ + memset(&gMsgPacket,0,sizeof(WTPACKET)); + + if(event->type == motion_type) + { + XDeviceMotionEvent *motion = (XDeviceMotionEvent *)event; + + TRACE_(event)("Received tablet motion event (%p)\n",hwnd); + TRACE("Received tablet motion event (%p)\n",hwnd); + gMsgPacket.pkTime = motion->time; + gMsgPacket.pkSerialNumber = gSerial++; + gMsgPacket.pkCursor = motion->deviceid; + gMsgPacket.pkX = motion->axis_data[0]; + gMsgPacket.pkY = motion->axis_data[1]; + gMsgPacket.pkOrientation.orAzimuth = + figure_deg(motion->axis_data[3],motion->axis_data[4]); + gMsgPacket.pkOrientation.orAltitude = 1000 - 15 * max + (abs(motion->axis_data[3]),abs(motion->axis_data[4])); + gMsgPacket.pkNormalPressure = motion->axis_data[2]; + gMsgPacket.pkButtons = get_button_state(motion->deviceid); + SendMessageW(hwndTabletDefault,WT_PACKET,0,(LPARAM)hwnd); + } + else if ((event->type == button_press_type)||(event->type == + button_release_type)) + { + XDeviceButtonEvent *button = (XDeviceButtonEvent *) event; + + TRACE_(event)("Received tablet button event\n"); + TRACE("Received tablet button %s event\n", (event->type == + button_press_type)?"press":"release"); + + set_button_state(button->deviceid); + } + else if (event->type == key_press_type) + { + TRACE_(event)("Received tablet key press event\n"); + FIXME("Received tablet key press event\n"); + } + else if (event->type == key_release_type) + { + TRACE_(event)("Received tablet key release event\n"); + FIXME("Received tablet key release event\n"); + } + else if ((event->type == proximity_in_type) || + (event->type == proximity_out_type)) + { + TRACE_(event)("Received tablet proximity event\n"); + TRACE("Received tablet proximity event\n"); + gMsgPacket.pkStatus = (event->type==proximity_out_type)?TPS_PROXIMITY:0; + SendMessageW(hwndTabletDefault, WT_PROXIMITY, + (event->type==proximity_out_type)?0:1, (LPARAM)hwnd); + } + else + return 0; + + return 1; +} + +int X11DRV_AttachEventQueueToTablet(HWND hOwner) +{ + struct x11drv_thread_data *data = x11drv_thread_data(); + int num_devices; + int loop; + int cur_loop; + XDeviceInfo *devices; + XDeviceInfo *target = NULL; + XDevice *the_device; + XInputClassInfo *ip; + XEventClass event_list[7]; + Window win; + WND *wndPtr; + + wine_tsx11_lock(); + + wndPtr = WIN_GetPtr(hOwner); + win = ((struct x11drv_win_data*)wndPtr->pDriverData)->whole_window; + + TRACE("Creating context for window 0x%x (%lx) %i cursors\n",(INT)hOwner, + win, gNumCursors); + + devices = pXListInputDevices(data->display, &num_devices); + + for (cur_loop=0; cur_loop < gNumCursors; cur_loop++) + { + int event_number=0; + + for (loop=0; loop < num_devices; loop ++) + if (strcmp(devices[loop].name,gSysCursor[cur_loop].NAME)==0) + target = &devices[loop]; + + TRACE("Opening cursor %i id %i\n",cur_loop,(INT)target->id); + + the_device = pXOpenDevice(data->display, target->id); + + if (!the_device) + { + WARN("Unable to Open device\n"); + continue; + } + + if (the_device->num_classes > 0) + { + for (ip = the_device->classes, loop=0; loop < target->num_classes; + ip++, loop++) + { + switch(ip->input_class) + { + case KeyClass: + DeviceKeyPress(the_device, key_press_type, + event_list[event_number]); + event_number++; + DeviceKeyRelease(the_device, key_release_type, + event_list[event_number]); + event_number++; + break; + case ButtonClass: + DeviceButtonPress(the_device, button_press_type, + event_list[event_number]); + event_number++; + DeviceButtonRelease(the_device, button_release_type, + event_list[event_number]); + event_number++; + break; + case ValuatorClass: + DeviceMotionNotify(the_device, motion_type, + event_list[event_number]); + event_number++; + ProximityIn(the_device, proximity_in_type, + event_list[event_number]); + event_number++; + ProximityOut(the_device, proximity_out_type, + event_list[event_number]); + event_number++; + break; + default: + ERR("unknown class\n"); + break; + } + } + if (pXSelectExtensionEvent(data->display, win, event_list, + event_number)) + { + ERR( "error selecting extended events\n"); + goto end; + } + } + } + +end: + WIN_ReleasePtr(wndPtr); + wine_tsx11_unlock(); + return 0; +} + +int X11DRV_GetCurrentPacket(LPWTPACKET *packet) +{ + memcpy(packet,&gMsgPacket,sizeof(WTPACKET)); + return 1; +} + + +int static inline CopyTabletData(LPVOID target, LPVOID src, INT size) +{ + memcpy(target,src,size); + return(size); +} + +/*********************************************************************** + * X11DRV_WTInfoA (X11DRV.@) + */ +UINT X11DRV_WTInfoA(UINT wCategory, UINT nIndex, LPVOID lpOutput) +{ + int rc = 0; + LPWTI_CURSORS_INFO tgtcursor; + TRACE("(%u, %u, %p)\n", wCategory, nIndex, lpOutput); + + switch(wCategory) + { + case 0: + /* return largest necessary buffer */ + TRACE("%i cursors\n",gNumCursors); + if (gNumCursors>0) + { + FIXME("Return proper size\n"); + return 200; + } + else + return 0; + break; + case WTI_INTERFACE: + switch (nIndex) + { + WORD version; + case IFC_WINTABID: + strcpy(lpOutput,"Wine Wintab 1.1"); + rc = 16; + break; + case IFC_SPECVERSION: + version = (0x01) | (0x01 << 8); + rc = CopyTabletData(lpOutput, &version,sizeof(WORD)); + break; + case IFC_IMPLVERSION: + version = (0x00) | (0x01 << 8); + rc = CopyTabletData(lpOutput, &version,sizeof(WORD)); + break; + default: + FIXME("WTI_INTERFACE unhandled index %i\n",nIndex); + rc = 0; + + } + case WTI_DEFSYSCTX: + case WTI_DDCTXS: + case WTI_DEFCONTEXT: + switch (nIndex) + { + case 0: + memcpy(lpOutput, &gSysContext, + sizeof(LOGCONTEXTA)); + rc = sizeof(LOGCONTEXTA); + break; + case CTX_NAME: + rc = CopyTabletData(lpOutput, &gSysContext.lcName, + strlen(gSysContext.lcName)+1); + break; + case CTX_OPTIONS: + rc = CopyTabletData(lpOutput, &gSysContext.lcOptions, + sizeof(UINT)); + break; + case CTX_STATUS: + rc = CopyTabletData(lpOutput, &gSysContext.lcStatus, + sizeof(UINT)); + break; + case CTX_LOCKS: + rc= CopyTabletData (lpOutput, &gSysContext.lcLocks, + sizeof(UINT)); + break; + case CTX_MSGBASE: + rc = CopyTabletData(lpOutput, &gSysContext.lcMsgBase, + sizeof(UINT)); + break; + case CTX_DEVICE: + rc = CopyTabletData(lpOutput, &gSysContext.lcDevice, + sizeof(UINT)); + break; + case CTX_PKTRATE: + rc = CopyTabletData(lpOutput, &gSysContext.lcPktRate, + sizeof(UINT)); + break; + case CTX_PKTMODE: + rc = CopyTabletData(lpOutput, &gSysContext.lcPktMode, + sizeof(WTPKT)); + break; + case CTX_MOVEMASK: + rc = CopyTabletData(lpOutput, &gSysContext.lcMoveMask, + sizeof(WTPKT)); + break; + case CTX_BTNDNMASK: + rc = CopyTabletData(lpOutput, &gSysContext.lcBtnDnMask, + sizeof(DWORD)); + break; + case CTX_BTNUPMASK: + rc = CopyTabletData(lpOutput, &gSysContext.lcBtnUpMask, + sizeof(DWORD)); + break; + case CTX_INORGX: + rc = CopyTabletData(lpOutput, &gSysContext.lcInOrgX, + sizeof(LONG)); + break; + case CTX_INORGY: + rc = CopyTabletData(lpOutput, &gSysContext.lcInOrgY, + sizeof(LONG)); + break; + case CTX_INORGZ: + rc = CopyTabletData(lpOutput, &gSysContext.lcInOrgZ, + sizeof(LONG)); + break; + case CTX_INEXTX: + rc = CopyTabletData(lpOutput, &gSysContext.lcInExtX, + sizeof(LONG)); + break; + case CTX_INEXTY: + rc = CopyTabletData(lpOutput, &gSysContext.lcInExtY, + sizeof(LONG)); + break; + case CTX_INEXTZ: + rc = CopyTabletData(lpOutput, &gSysContext.lcInExtZ, + sizeof(LONG)); + break; + case CTX_OUTORGX: + rc = CopyTabletData(lpOutput, &gSysContext.lcOutOrgX, + sizeof(LONG)); + break; + case CTX_OUTORGY: + rc = CopyTabletData(lpOutput, &gSysContext.lcOutOrgY, + sizeof(LONG)); + break; + case CTX_OUTORGZ: + rc = CopyTabletData(lpOutput, &gSysContext.lcOutOrgZ, + sizeof(LONG)); + break; + case CTX_OUTEXTX: + rc = CopyTabletData(lpOutput, &gSysContext.lcOutExtX, + sizeof(LONG)); + break; + case CTX_OUTEXTY: + rc = CopyTabletData(lpOutput, &gSysContext.lcOutExtY, + sizeof(LONG)); + break; + case CTX_OUTEXTZ: + rc = CopyTabletData(lpOutput, &gSysContext.lcOutExtZ, + sizeof(LONG)); + break; + case CTX_SENSX: + rc = CopyTabletData(lpOutput, &gSysContext.lcSensX, + sizeof(LONG)); + break; + case CTX_SENSY: + rc = CopyTabletData(lpOutput, &gSysContext.lcSensY, + sizeof(LONG)); + break; + case CTX_SENSZ: + rc = CopyTabletData(lpOutput, &gSysContext.lcSensZ, + sizeof(LONG)); + break; + case CTX_SYSMODE: + rc = CopyTabletData(lpOutput, &gSysContext.lcSysMode, + sizeof(LONG)); + break; + case CTX_SYSORGX: + rc = CopyTabletData(lpOutput, &gSysContext.lcSysOrgX, + sizeof(LONG)); + break; + case CTX_SYSORGY: + rc = CopyTabletData(lpOutput, &gSysContext.lcSysOrgY, + sizeof(LONG)); + break; + case CTX_SYSEXTX: + rc = CopyTabletData(lpOutput, &gSysContext.lcSysExtX, + sizeof(LONG)); + break; + case CTX_SYSEXTY: + rc = CopyTabletData(lpOutput, &gSysContext.lcSysExtY, + sizeof(LONG)); + break; + case CTX_SYSSENSX: + rc = CopyTabletData(lpOutput, &gSysContext.lcSysSensX, + sizeof(LONG)); + break; + case CTX_SYSSENSY: + rc = CopyTabletData(lpOutput, &gSysContext.lcSysSensY, + sizeof(LONG)); + break; + default: + FIXME("WTI_DEFSYSCTX unhandled index %i\n",nIndex); + rc = 0; + } + break; + case WTI_CURSORS: + case WTI_CURSORS+1: + case WTI_CURSORS+2: + case WTI_CURSORS+3: + case WTI_CURSORS+4: + case WTI_CURSORS+5: + case WTI_CURSORS+6: + case WTI_CURSORS+7: + case WTI_CURSORS+8: + case WTI_CURSORS+9: + case WTI_CURSORS+10: + tgtcursor = &gSysCursor[wCategory - WTI_CURSORS]; + switch (nIndex) + { + case CSR_NAME: + rc = CopyTabletData(lpOutput, &tgtcursor->NAME, + strlen(tgtcursor->NAME)+1); + break; + case CSR_ACTIVE: + rc = CopyTabletData(lpOutput,&tgtcursor->ACTIVE, + sizeof(BOOL)); + break; + case CSR_PKTDATA: + rc = CopyTabletData(lpOutput,&tgtcursor->PKTDATA, + sizeof(WTPKT)); + break; + case CSR_BUTTONS: + rc = CopyTabletData(lpOutput,&tgtcursor->BUTTONS, + sizeof(BYTE)); + break; + case CSR_BUTTONBITS: + rc = CopyTabletData(lpOutput,&tgtcursor->BUTTONBITS, + sizeof(BYTE)); + break; + case CSR_BTNNAMES: + FIXME("Button Names not returned correctly\n"); + rc = CopyTabletData(lpOutput,&tgtcursor->BTNNAMES, + strlen(tgtcursor->BTNNAMES)+1); + break; + case CSR_BUTTONMAP: + rc = CopyTabletData(lpOutput,&tgtcursor->BUTTONMAP, + sizeof(BYTE)*32); + break; + case CSR_SYSBTNMAP: + rc = CopyTabletData(lpOutput,&tgtcursor->SYSBTNMAP, + sizeof(BYTE)*32); + break; + case CSR_NPBTNMARKS: + memcpy(lpOutput,&tgtcursor->NPBTNMARKS,sizeof(UINT)*2); + rc = sizeof(UINT)*2; + break; + case CSR_NPBUTTON: + rc = CopyTabletData(lpOutput,&tgtcursor->NPBUTTON, + sizeof(BYTE)); + break; + case CSR_NPRESPONSE: + FIXME("Not returning CSR_NPRESPONSE correctly\n"); + rc = 0; + break; + case CSR_TPBUTTON: + rc = CopyTabletData(lpOutput,&tgtcursor->TPBUTTON, + sizeof(BYTE)); + break; + case CSR_TPBTNMARKS: + memcpy(lpOutput,&tgtcursor->TPBTNMARKS,sizeof(UINT)*2); + rc = sizeof(UINT)*2; + break; + case CSR_TPRESPONSE: + FIXME("Not returning CSR_TPRESPONSE correctly\n"); + rc = 0; + break; + case CSR_PHYSID: + { + DWORD id; + rc = CopyTabletData(&id,&tgtcursor->PHYSID, + sizeof(DWORD)); + id += (wCategory - WTI_CURSORS); + memcpy(lpOutput,&id,sizeof(DWORD)); + } + break; + case CSR_MODE: + rc = CopyTabletData(lpOutput,&tgtcursor->MODE,sizeof(UINT)); + break; + case CSR_MINPKTDATA: + rc = CopyTabletData(lpOutput,&tgtcursor->MINPKTDATA, + sizeof(UINT)); + break; + case CSR_MINBUTTONS: + rc = CopyTabletData(lpOutput,&tgtcursor->MINBUTTONS, + sizeof(UINT)); + break; + case CSR_CAPABILITIES: + rc = CopyTabletData(lpOutput,&tgtcursor->CAPABILITIES, + sizeof(UINT)); + break; + case CSR_TYPE: + rc = CopyTabletData(lpOutput,&tgtcursor->TYPE, + sizeof(UINT)); + break; + default: + FIXME("WTI_CURSORS unhandled index %i\n",nIndex); + rc = 0; + } + break; + case WTI_DEVICES: + switch (nIndex) + { + case DVC_NAME: + rc = CopyTabletData(lpOutput,gSysDevice.NAME, + strlen(gSysDevice.NAME)+1); + break; + case DVC_HARDWARE: + rc = CopyTabletData(lpOutput,&gSysDevice.HARDWARE, + sizeof(UINT)); + break; + case DVC_NCSRTYPES: + rc = CopyTabletData(lpOutput,&gSysDevice.NCSRTYPES, + sizeof(UINT)); + break; + case DVC_FIRSTCSR: + rc = CopyTabletData(lpOutput,&gSysDevice.FIRSTCSR, + sizeof(UINT)); + break; + case DVC_PKTRATE: + rc = CopyTabletData(lpOutput,&gSysDevice.PKTRATE, + sizeof(UINT)); + break; + case DVC_PKTDATA: + rc = CopyTabletData(lpOutput,&gSysDevice.PKTDATA, + sizeof(WTPKT)); + break; + case DVC_PKTMODE: + rc = CopyTabletData(lpOutput,&gSysDevice.PKTMODE, + sizeof(WTPKT)); + break; + case DVC_CSRDATA: + rc = CopyTabletData(lpOutput,&gSysDevice.CSRDATA, + sizeof(WTPKT)); + break; + case DVC_XMARGIN: + rc = CopyTabletData(lpOutput,&gSysDevice.XMARGIN, + sizeof(INT)); + break; + case DVC_YMARGIN: + rc = CopyTabletData(lpOutput,&gSysDevice.YMARGIN, + sizeof(INT)); + break; + case DVC_ZMARGIN: + rc = 0; /* unsupported */ + /* + rc = CopyTabletData(lpOutput,&gSysDevice.ZMARGIN, + sizeof(INT)); + */ + break; + case DVC_X: + rc = CopyTabletData(lpOutput,&gSysDevice.X, + sizeof(AXIS)); + break; + case DVC_Y: + rc = CopyTabletData(lpOutput,&gSysDevice.Y, + sizeof(AXIS)); + break; + case DVC_Z: + rc = 0; /* unsupported */ + /* + rc = CopyTabletData(lpOutput,&gSysDevice.Z, + sizeof(AXIS)); + */ + break; + case DVC_NPRESSURE: + rc = CopyTabletData(lpOutput,&gSysDevice.NPRESSURE, + sizeof(AXIS)); + break; + case DVC_TPRESSURE: + rc = 0; /* unsupported */ + /* + rc = CopyTabletData(lpOutput,&gSysDevice.TPRESSURE, + sizeof(AXIS)); + */ + break; + case DVC_ORIENTATION: + memcpy(lpOutput,&gSysDevice.ORIENTATION,sizeof(AXIS)*3); + rc = sizeof(AXIS)*3; + break; + case DVC_ROTATION: + rc = 0; /* unsupported */ + /* + memcpy(lpOutput,&gSysDevice.ROTATION,sizeof(AXIS)*3); + rc = sizeof(AXIS)*3; + */ + break; + case DVC_PNPID: + rc = CopyTabletData(lpOutput,gSysDevice.PNPID, + strlen(gSysDevice.PNPID)+1); + break; + default: + FIXME("WTI_DEVICES unhandled index %i\n",nIndex); + rc = 0; + } + break; + default: + FIXME("Unhandled Category %i\n",wCategory); + } + return rc; +}

1 0

Serial port under wine
by Paul Sheer 08 Jan '04

08 Jan '04

I am trying to write a simple serial port library that has the same lowest-common-denominator interface under both Windows and Linux. I developed it under wine using mingw32 - i want my apps that use it to work under both windows and linux (these are command-line apps only). i noticed that wine does not seem to report errors from GetOverLapped.. and Wait..Object in a way that makes sense. By ignoring errors, and just looking at the dwRead result, i got it to work. my attempt at a posix-like read function is below (the linux version follows further down) best wishes -paul --------- int serial_port_read (struct serial_port *p, unsigned char *buf, int buf_len, int milli_timeout) { static int c = 0; DWORD dwStart, dwRead, r; int l, total = 0; dwStart = GetTickCount (); while (buf_len > 0) { l = serial_port_chars_avail (p); if (l < 0) return total > 0 ? total : SERIAL_PORT_ERROR; if (l == 0 && GetTickCount () - dwStart >= milli_timeout) return total > 0 ? total : SERIAL_PORT_TIMEOUT; /* Like POSIX read(), we return without blocking if we have read at least one character: */ if (l == 0 && total >= 1) return total; /* Read minimum of one character, and a maximum of buf_len characters: */ CLIP (l, 1, buf_len); dwRead = 0; if (!ReadFile (p->hComm, buf, l, &dwRead, &p->osRead)) { if ((r = GetLastError ()) == ERROR_IO_PENDING) { dwRead = 0; GetOverlappedResult (p->hComm, &p->osRead, &dwRead, TRUE); } } total += dwRead; buf_len -= dwRead; buf += dwRead; } return total; } ------------ int serial_port_read (struct serial_port *p, unsigned char *buf, int buf_len, int milli_timeout) { int c; struct timeval tv; fd_set rd; if (!buf_len) return 0; FD_ZERO (&rd); FD_SET (p->fd, &rd); switch (select (p->fd + 1, &rd, NULL, NULL, milli_timeout < 0 ? NULL : (tv.tv_sec = milli_timeout / 1000, tv.tv_usec = milli_timeout % 1000, &tv))) { case 1: c = read (p->fd, buf, buf_len); if (!c) { p->error = 0; return SERIAL_PORT_HANGUP; } if (c < 0) { p->error = errno; return SERIAL_PORT_ERROR; } return c; case 0: return SERIAL_PORT_TIMEOUT; default: p->error = errno; return SERIAL_PORT_ERROR; } }

1 0

Problem with Access-mdb/DAO
by Fabian Cenedese 08 Jan '04

08 Jan '04

Hi I have posted this problem already long time ago but I never found the time to test it again. http://www.winehq.org/hypermail/wine-devel/2002/11/1530.html But now I tried with the actual wine from cvs (2003-12-03) and it's still there. The problem is that if I try to create a table in a Access database the last char of the name gets lost. I now have a small program which shows this error, maybe someone can use it for finding this bug. It's a simple VC6 Wizard generated Win32 command line app which uses MFC for DAO. The first time I tried was with SUSE 8.0, now I have Knoppix 3.3 (Debian). Thanks bye Fabi ---------------------------- mdbtest.cpp // mdbtest.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include <afxdao.h> // MFC DAO database classes #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif LPCTSTR lpszTableNodeTable = "Nodes"; LPCTSTR lpszTableNodeName = "NodeName"; LPCTSTR lpszTableNodeNodeType = "NodeType"; LPCTSTR lpszTableNodeBuildCL = "BuildCL"; LPCTSTR lpszTableNodeEditCL = "EditCL"; LPCTSTR lpszTableNodePath = "Path"; LPCTSTR lpszTableNodeFlags = "Flags"; LPCTSTR lpszTableNodeParam1 = "Param1"; LPCTSTR lpszTableNodeParam2 = "Param2"; LPCTSTR lpszTableNodeParam3 = "Param3"; LPCTSTR lpszTableNodeParam4 = "Param4"; ///////////////////////////////////////////////////////////////////////////// // The one and only application object CWinApp theApp; using namespace std; //----------------------------------------------------------------------------- void CreateNodeTable(CDaoDatabase* pDB) // throws CDaoException and CMemoryException { CDaoTableDef nodeDef(pDB); // attempt to create a new table def nodeDef.Create(lpszTableNodeTable); CDaoFieldInfo DaoFieldInfo; // init members DaoFieldInfo.m_strName = lpszTableNodeName; DaoFieldInfo.m_nType = dbText; DaoFieldInfo.m_lSize = 255; DaoFieldInfo.m_lAttributes = dbVariableField; DaoFieldInfo.m_nOrdinalPosition = 0; DaoFieldInfo.m_bRequired = FALSE; DaoFieldInfo.m_bAllowZeroLength = TRUE; DaoFieldInfo.m_lCollatingOrder = 0; // create name field nodeDef.CreateField(DaoFieldInfo); // create type field DaoFieldInfo.m_strName = lpszTableNodeNodeType; DaoFieldInfo.m_lSize = 30; nodeDef.CreateField(DaoFieldInfo); // create path field DaoFieldInfo.m_strName = lpszTableNodePath; DaoFieldInfo.m_lSize = 255; nodeDef.CreateField(DaoFieldInfo); // create flags field nodeDef.CreateField(lpszTableNodeFlags, dbLong, 4, dbFixedField); // create build command line field DaoFieldInfo.m_strName = lpszTableNodeBuildCL; DaoFieldInfo.m_nType = dbMemo; nodeDef.CreateField(DaoFieldInfo); // create edit command line field DaoFieldInfo.m_strName = lpszTableNodeEditCL; DaoFieldInfo.m_nType = dbMemo; nodeDef.CreateField(DaoFieldInfo); DaoFieldInfo.m_nType = dbMemo; //DaoFieldInfo.m_lSize = 200; DaoFieldInfo.m_strName = lpszTableNodeParam1; nodeDef.CreateField(DaoFieldInfo); // create Param cl field DaoFieldInfo.m_strName = lpszTableNodeParam2; nodeDef.CreateField(DaoFieldInfo); // create Param cl field DaoFieldInfo.m_strName = lpszTableNodeParam3; nodeDef.CreateField(DaoFieldInfo); // create Param cl field DaoFieldInfo.m_strName = lpszTableNodeParam4; nodeDef.CreateField(DaoFieldInfo); // create Param cl field nodeDef.Append(); // append table def to database nodeDef.Close(); // end CreateNodeTable } int _tmain(int argc, TCHAR* argv[], TCHAR* envp[]) { int nRetCode = 0; // initialize MFC and print and error on failure if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0)) { // TODO: change error code to suit your needs cerr << _T("Fatal Error: MFC initialization failed") << endl; nRetCode = 1; } else { // TODO: code your application's behavior here. CString m_Path="test.mdb"; CDaoDatabase db; CDaoRecordset rsNode(&db); // rs node try { // create database if not available cout << "Creating Database\n"; try { db.Create(m_Path); db.Close(); } catch (CDaoException* de) { // already exists I guess cout << "Database already existed\n"; de->Delete(); } cout << "Opening Database\n"; // try to open database db.Open(m_Path, TRUE, FALSE, _T("")); // --- delete old node and dependency tables and save new ones --- cout << "Deleting Tabledef\n"; try { // delete node table db.DeleteTableDef(lpszTableNodeTable); } catch (CDaoException* dde) { // catch error, maybe table def hasn't existed dde->Delete(); } cout << "Creating new Tabledef\n"; // create node table CreateNodeTable(&db); cout << "Opening Table\n"; // try to open node table rsNode.Open(dbOpenDynaset, CString(_T("Select * From [")) + lpszTableNodeTable + _T("]"), 0); // look if recordset is updateable if (!rsNode.CanUpdate()) { cout << "No Update\n"; } cout << "Closing Table\n"; // close tables rsNode.Close(); cout << "Closing Database\n"; // close database db.Close(); cout << "Deleting Database\n"; DeleteFile(m_Path); } catch (CDaoException* de) { // catch database exception char msg[256]; de->GetErrorMessage(msg, 256); cout << "Error:" << msg; de->Delete(); goto failure_exit; } catch (CMemoryException* me) { // catch memory exception char msg[256]; me->GetErrorMessage(msg, 256); cout << "Error:" << msg; me->Delete(); goto failure_exit; } cout << "OK\n"; return TRUE; failure_exit: // do some cleanup after failure if (rsNode.IsOpen()) rsNode.Close(); if (db.IsOpen()) db.Close(); } cout << "ERROR!!\n"; return nRetCode; }

2 8

no keyboard events in ddraw application.
by Oleg Prokhorov 08 Jan '04

08 Jan '04

Hello wine-devel, I've got a problem with 'Theme Hospital' game application. It requires some keyboard input to start. But the problem is that this application doesn't receive any keyboard events. I've put some checks inside function process_events (dlls/x11drv/event.c) but they show that no keyboard events (KeyPress, KeyRelease) I don't have any experience in this area and ask for you guidance, where to look at. -- Best regards, Oleg mailto:xolegpro@rbcmail.ru

3 3

Re: PATCH: Editing DLL overrides in winecfg
by Alexandre Julliard 07 Jan '04

07 Jan '04

Robert van Herk <robert(a)robertvanherk.nl> writes: > This is a patch that adds a tabsheet to winecfg, that allows the user > to change the dll overrides; both globally and per app. I put this in, but note that there are more possibilities that just builtin or native that will have to be supported too. Altogether there are five possible combinations: "builtin", "native", "builtin,native", "native,builtin", "". -- Alexandre Julliard julliard(a)winehq.com

3 2

#pre5 - comdlg32 MS_VC + PSDK porting
by Steven Edwards 07 Jan '04

07 Jan '04

Hello, I am calling this patch pre5 rather than #5 because it doesnt fully address the rest of the PSDK porting issues and one of my new years resolutions for 2004 is for every patch I send to winehq to be good enough to go right in to CVS. ;) With this patch we can build 90% of comdlg32 on MS_VC with the PSDK except for one major bug and one minor question. 1. Can we please fix winnt.h line 175? This #define NONAMELESSSTRUCT thing is wrong. It breaks building on the PSDK and w32api. I have not be able to find any thing about it in Microsofts documentation or headers. If we removed support for it its going to break GCC 2.8.xx but if someone is on 2.8 its time to upgrade. /me is quoting here from the Microsoft headers under Fair use and all of that...... "// // For compilers that don't support nameless unions // #ifndef DUMMYUNIONNAME #ifdef NONAMELESSUNION #define DUMMYUNIONNAME u #define DUMMYUNIONNAME2 u2 #define DUMMYUNIONNAME3 u3 #define DUMMYUNIONNAME4 u4 #define DUMMYUNIONNAME5 u5 #else #define DUMMYUNIONNAME #define DUMMYUNIONNAME2 #define DUMMYUNIONNAME3 #define DUMMYUNIONNAME4 #define DUMMYUNIONNAME5 #endif #endif // DUMMYUNIONNAME " Thats it. All I can find is the DUMMYUNION stuff in some of the headers. If we just remove support for DUMMYSTRUCT in WINE its going to break a lot of stuff so we will prob'l need to perl script the cleanup. 2. Do you want me to dump printdlg.h now and compleate the cleanup or can it wait untill after the DUMMYSTRUCT thing is fixed? I can move the rest of the structures and internal function declairations to cdlg.h and cdlg16.h now but I want to wait till I can get printdlg.c to compile with out bitching about missing member s1 and u1 blah... Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

3 6

Task Manager for WINE and ReactOS
by Steven Edwards 07 Jan '04

07 Jan '04

Hiya Mike, I have CC'd this to wine-devel in case you are short on time or are no longer interested in taskmgr or if Alexandre even wanted it in CVS. I have updated the license header and removed most of the C++ style comments except in the C++ source files we have not been able to convert yet to C. Work on taskmgr has stalled in ReactOS pending our 0.2 release and its mostly fully functional under Windows anyway. WINE should only require minor tweaks to get it to work. Hi Eric I know your busy with the File Reorg stuff but in case you are still interested I CC'd you. After reading over the Winedbg guide I thought a nice feature for the WINELIB build would be the ablity to add a check box to one of the dialogs to show the Windows Thread ID and Unix Process ID's that each process is mapped to. I didnt apply your last patch because taskmgr worked fine under Windows and I lost it in my inbox. =( Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 2

Re: imm work
by Steven Edwards 07 Jan '04

07 Jan '04

Hiya Aric, --- Aric Stewart <aric(a)codeweavers.com> wrote: > Notes: > I fear this may violate dll separation between Imm32 and X11drv. I > have a very long and bad history of doing that... alot.. so i need to > get better about it. I think it does. We use Imm32 on ReactOS and this wont work for us. Its not the end of the world as we really dont need it atm but we will end up having to rewrite your work down the road. =( Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 2

SEH general info
by Jakob Eriksson 07 Jan '04

07 Jan '04

You all probably know, but maybe this is of interest: http://www.jorgon.freeserve.co.uk/ExceptFrame.htm

1 0

Re: wine/ libs/wine/wine.def libs/wine/loader.c in ...
by Ferenc Wagner 07 Jan '04

07 Jan '04

Alexandre Julliard <julliard(a)winehq.org> writes: > ChangeSet ID: 10547 > Changes by: julliard(a)wine.codeweavers.com 2004/01/02 15:08:05 > > Modified files: > libs/wine : wine.def loader.c > include/wine : library.h > > Log message: > Added wine_dll_get_owner function that retrieves the > 32-bit dll containing a given 16-bit dll by reading > the symlink, so that we don't need to dlopen it. This patch broke cross-compilation, as mingw does not have a readlink function. I have got no idea about the proper way, but can emit a wild shot. Feri. Index: include/wine/port.h =================================================================== RCS file: /home/wine/wine/include/wine/port.h,v retrieving revision 1.45 diff -u -r1.45 port.h --- include/wine/port.h 4 Dec 2003 05:48:03 -0000 1.45 +++ include/wine/port.h 7 Jan 2004 20:49:44 -0000 @@ -113,6 +113,7 @@ #ifndef S_ISLNK # define S_ISLNK(mod) (0) +# define readlink(path,buffer,size) (-1) #endif /* S_ISLNK */ /* So we open files in 64 bit access mode on Linux */

1 0

Re: Comment on new file implementation
by Juan Lang 07 Jan '04

07 Jan '04

Eric, the sooner the better as far as I'm concerned. In my quick read of the patch I didn't see any translating from the Win32 namespace to the NT namespace; do you plan to do anything there? To pick a (bad) example, the name \\server\share\file is valid in the Win32 namespace, but not in the NT namespace; it must be translated to \??\UNC\server\share\file Since you mentioned SMB, I will too: don't worry too much, it's currently broken anyway. As long as the code's cleaner it should be easier to fix (and this looks much cleaner). --Juan __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 1

Comment on new file implementation
by Eric Pouech 07 Jan '04

07 Jan '04

I've been working lately on rehauling the file handling in Wine. The current output is a large patch, available here: http://perso.wanadoo.fr/pouech-eric/ep-file.diff.gz (400 KB uncompressed) It's not completly ready yet for inclusion, however some ongoing discussions could overlap with what I've currently done (like how to configure drive without a config file, SMB handling...). So better discuss it widely (yet another flame war). The benefit of the patch: - all file creation, opening, directory browsing is now done in ntdll instead of kernel32 - file IO management can be cleanly separated between kernel32 and ntdll (1) - files/ directory could be removed (not done in the patch (also nuked include/drive.h and include/file.h) - homogenous drive & device handling (we no longer store those objects in the server). Drive and device are now standard file handles (from a Windows point of view). - a few current Wine bugs have been fixed (see the todo_wine removed in the tests subdirs) - we no longer rely on the Wine config dir for the drive settings - partial NT volume management implementation - most of the volume related information (& ioctl) are done on the real unix device attached to the volume What has been removed (from current implementation): - file system options (all FS are considered case insensitive) - per drive code page (all drives are now handled with the wine specfic UNIXCP code page) What still need some improvement - fix all the introduced bugs (even if all the current tests actually pass) - setting a first default environment (even if tools/winefs provides it - see below) Drives (and all their attributes - mount points, labels...) are defined this way: 1 Volumes & drives ------------------ Every volume on each available volume (partition on a physical disk) on the system will be listed in ${WINEPREFIX}/device directory. This directory will also be populated by other needed devices (serial, parallel, physical disks). Each item in this devices list will be stored as a subdirectory of ${WINEPREFIX}/device. Each subdirectory will contain various files & symlinks related to this device. Every volume will be named volume{XXX} where XXX is the actual unix device name. We're using this syntax so that we can distinguish from other (non-volume) devices and because under windows, volumes are named as Volume{<UID>} where <UID> is the unique identifier of the volume. Every DOS drive letter will be known from a (directory) entry in ${WINEPREFIX}/dosdevices. This directory will also contains entries for VxDs. A drive letter entry will in fact be a symlink to $WINEPREFIX/device/volume{XXX}/mount. This later will be another symlink to the actual mount point of volume XXX. This double indirection is needed: a DOS drive can be mounted either at the root of a volume, or as a subdirectory on that volume. The first symlink (in the dosdevices directory) will point to subdirectory we want to mount on, and the second will hold where the volume itself is mounted. For convenience reasons, we also list, for every DOS drive, the volume on which it is mounted, by creating a symlink between ${WINEPREFIX}/device/x: and ${WINEPREFIX}/device/volume{XXX} 2 Example --------- Unix side: /dev/scd0 on /mnt/cdrom /dev/fd0 on /mnt/floppy /dev/hda1 on /mnt/ntfs /dev/hda5 on /mnt/windows /dev/hda6 on / /dev/hda8 on /opt /dev/hda9 on /home Note, from now on, all paths are relative to ${WINEPREFIX} From this, we will define this hierarchy: device/ volume{fd0}/ device -> /dev/fd0 mount -> /mnt/floppy/ volume{hda1}/ device -> /dev/hda1 mount -> /mnt/ntfs/ volume{hda5}/ device -> /dev/hda5 mount -> /mnt/windows/ volume{hda6}/ device -> /dev/hda6 mount -> / volume{hda8}/ device -> /dev/hda8 mount -> /opt/ volume{hda9}/ device -> /dev/hda9 mount -> /home/ volume{scd0}/ device -> /dev/scd0 mount -> /mnt/cdrom/ This hierarchy doesn't depend on what's actually mounted (both on unix side and windows side), it's just the volume definition. We also define a few more disks related entries: device/ harddisk0/ device -> /dev/hda and some other devices as well: device/ null/ device -> /dev/null parallel0/ device -> /dev/lp0 serial0/ device -> /dev/ttyS0 Now, assume we want to define our DOS drives as follow: a: -> /mnt/fd0/ c: -> /home/eric/.wine/c_copy/ d: -> /opt/winapps/ e: -> /mnt/cdrom/ f: -> /tmp g: -> /home/eric/ m: -> /mnt/windows/ We will create two new symlinks per drive: one in $WINEPREFIX/device which will point to the device of the volume, another one in $WINEPREFIX/dosdevices which will point to the unix root we want for the drive. device/ a: -> volume{fd0} c: -> volume{hda9} d: -> volume{hda8} e: -> volume{scd0} f: -> volume{hda6} g: -> volume{hda9} m: -> volume{hda5} dosdevices/ a: -> ../device/volume{fd0}/mount/ c: -> ../device/volume{hda9}/mount/eric/.wine/c_copy/ d: -> ../device/volume{hda8}/mount/winapps/ e: -> ../device/volume{scd0}/mount/ f: -> ../device/volume{hda6}/mount/tmp/ g: -> ../device/volume{hda9}/mount/eric/ m: -> ../device/volume{hda5}/mount/ We also define some more DOS devices (for the other devices we defined): dosdevices/ com1 -> ../device/serial0/device lpt1 -> ../device/parallel0/device nul -> ../device/null/device physicaldrive0 -> ../device/harddisk0/device 3 More details on volumes ------------------------- In a volume subdirectory in ${WINEPREFIX}/volume{XXX} we can also find some other files used for: - getting volume label. We try to get information in the following order: 1/ read it from device (done for disks with FAT partition, and AUDIO or data CDROM - mixed mode is not supported) 2/ if 1/ fails, read the file .windows-label at (unix) root of volume (handy for hard, floppy disks) 3/ if 2/ fails, read the file label from the file ${WINEPREFIX}/device/volume{XXX}/label - getting volume serial number. We try to get information in the following order: 1/ read it from device (done for disks with FAT partition, and CDROMs) 2/ if 1/ fails, read the file .windows-serial at (unix) root of volume (handy for hard, floppy disks) 3/ if 2/ fails, read the file label from the file ${WINEPREFIX}/device/volume{XXX}/serial - some specific attributes are stored in ${WINEPREFIX}/device/volume{XXX}/flags. This file stores an unsigned value, which high word is the device characteristics, while its low word is the device type (from include/winioctl.h FILE_DEVICE_????). The VxDs and TSRs will be defined as an empty file (which name is VxD or TSR name) in ${WINEPREFIX}/dosdevices. Every filename will be case insensitive (device, VxD, TSR...) as we always do case insensitive matching. 4 Example of the full configuration ----------------------------------- -> is a symlink to <> contains device/ a: -> volume{fd0} c: -> volume{hda9} d: -> volume{hda8} e: -> volume{scd0} f: -> volume{hda6} g: -> volume{hda9} harddisk0/ device -> /dev/hda m: -> volume{hda5} null/ device -> /dev/null parallel0/ device -> /dev/lp0 serial0/ device -> /dev/ttyS0 volume{fd0}/ device -> /dev/fd0 flags <> FILE_DEVICE_DISK + FILE_REMOVABLE_MEDIA|FILE_FLOPPY_DISKETTE mount -> /mnt/floppy/ volume{hda1}/ device -> /dev/hda1 flags <> FILE_DEVICE_DISK mount -> /mnt/ntfs/ volume{hda5}/ device -> /dev/hda5 flags <> FILE_DEVICE_DISK label <> VolumeC mount -> /mnt/windows/ volume{hda6}/ device -> /dev/hda6 flags <> FILE_DEVICE_DISK mount -> / volume{hda8}/ device -> /dev/hda8 flags <> FILE_DEVICE_DISK mount -> /opt/ volume{hda9}/ device -> /dev/hda9 flags <> FILE_DEVICE_DISK mount -> /home/ volume{scd0}/ device -> /dev/scd0 flags <> FILE_DEVICE_CD_ROM + FILE_READ_ONLY_DEVICE|FILE_REMOVABLE_DEVICE mount -> /mnt/cdrom/ dosdevices/ a: -> ../device/volume{fd0}/mount/ afilter awredir aux -> ../dosdevices/com1 bios bios_ext bioshook biosxlat blockdev c: -> ../device/volume{hda9}/mount/eric/.wine/standalone/c_copy/ chbios com1 -> ../device/serial0/device configmg d: -> ../device/volume{hda8}/mount/winapps/ debug debugcmd dosmgr dosnet dragcli dragsrv dsvxd dwcfgmg e: -> ../device/volume{scd0}/mount/ ebios efax efilter eisa emmxxxx0 enable eten f: -> ../device/volume{hda6}/mount/tmp/ ffilter filesec g: -> ../device/volume{hda9}/mount/eric/ hasp95 hpscan ifsmgr int13 irlamp isapnp logger lpt1 -> ../device/parallel0/device m: -> ../device/volume{hda5}/mount/ mca_pos memprobe mmdevldr monodebg.vxd mrci2 msodisup ndis ndis2sup nscl nul -> ../device/null/device nwlink nwredir nwserver nwsup pagefile pageswap parity pccard pci peloader perf physicaldrive0 -> ../device/harddisk0/device ppp reboot scsi scsifd scsimgr$ scsiport secprov server shell splitter spooler stat80 tfilter tsrload v86mmgr vasync vbrowse vcache vcd vcdfsd vcomm vcond vdd vdd2 vdhcp vdmad vfat vfbackup vfd vhbiosd vime vip vkd20 vmcpd vmd vmm vmpoll vmsgd vnb vnbt vnetbios vnetsup vnwlink vpd vpend vpicd vpowerd vppid vprod vredir vsd vshare vtcp vtd vtdapi vtdi vudp vwin32 vxdldr win32s windebug winload winsock wsipx wsock wstcp 5 Configuration --------------- All this configuration is done automatically by a new tool: tools/winefs. This tool : a/ creates (in all cases) from the /etc/fstab entries (and the known VxD and TSR) all possible entries in ~/.wine/device and ~/.wine/dosdevice b/ will try to define the DOS drives depending on various sources You can run it in several fashions: 1/ winefs ~/.wine Will get all possible information from the current ~/.wine/config for Wine drive settings (mount points, device, labels, serial number...) 2/ winefs ~/.wine --bios-assign Will do as previously, but creating the DOS drive assignments as the BIOS would do 3/ winefs ~/.wine --no-assign Will only provide step a/ Beware, rerunning winefs will erase all your previous settings. Have fun !! A+ (1): not entirely true in this patch => the volume management (even if most of the code exists in ntdll) doesn't work as expected from ntdll. So the current kernel32 implementation remains

2 2

Re: Wineconf update, RFC re remote participation
by Ivan Leo Murray-Smith 07 Jan '04

07 Jan '04

> One thing I would like to do is to stream audio This would be a regression, the last wineconf had a video stream. Ivan.

2 1

my patch is in neverland :-)
by Tom 07 Jan '04

07 Jan '04

Hi, I sent a 100k Status Update patch and its been around 18 hours now and its still not showed up. Is the moderator on strike? :)) Tom

5 5

Re: [Fwd: [unixODBC-DEV] - UnixODBC, Wine, Crystal Report -- would appreciate insight]]
by Ulrich Czekalla 07 Jan '04

07 Jan '04

On Wed, Jan 07, 2004 at 07:11:54AM -0800, Bill Medland wrote: > On January 6, 2004 07:35 pm, Dan Kegel wrote: > > Can somebody have a look at this? > > Thanks, > > Dan > > I'll do what I can; everyone else feel free to jump in. > > > > > -------- Original Message -------- > > Subject: [unixODBC-DEV] - UnixODBC, Wine, Crystal Report -- would > > appreciate insight Date: Tue, 06 Jan 2004 15:07:11 -0500 > > From: Aurelien Marchand <aurelien.marchand(a)researchcapital.com> > > Reply-To: unixodbc-dev(a)unixodbc.org > > To: unixodbc-dev(a)easysoft.com > > > > Hi, > > > > I am a bit confused as to who I should send this email. Please let me > > know if this is the wrong place. > > > > I am really, really close to making the whole thing work (I'll show in a > > minute why I think that) but I'm stomped and need some help. > > > > I've dumped my WinNT workstation and replaced it with Linux. So far, I > > can do exactly everything I was able to do (except updating my calendar > > on the Exchange server used where I work), minus using Crystal Report. > > I have installed it using CodeWeavers' CrossOver Office and it installed > > without even a hiccup. > > I've also installed unixODBC and tested the odbc.ini configuration using > > isql. It works great when I try to connect to the company's AS400 > > database. The default library is set to my username and I can query > > other libraries using the dot (.) as a separator (e.g: SELECT * from > > OTHERLIB.OTHERTABLE). > > > > So far so good: UnixODBC works perfectly to talk to IBM's AS400. > > > > Now I need to tell Crystal which drivers to use. I've read on the web > > that Crystal is not a very good student and thus ignores Windows' > > ODBC.ini settings but checks what's in the registry. I've also come to > > understand I must set ODBC.dll = "builtin, native" in my Wine's config > > file so that it will try to use whatever is set for > > LIB_ODBC_DRIVER_MANAGER env variable for Windows' ODBC connections. > > Those instructions were put together in order to get Crystal Reports runtime > working. Do you get anywhere if you change the override to "native"? > This is the way I do it. Switch to native odbc32, install mdac (available with ms office or download from MS site) and then setup the dsns using odbcad32.exe. /Ulrich

1 0

[Fwd: [unixODBC-DEV] - UnixODBC, Wine, Crystal Report -- would appreciate insight]
by Dan Kegel 07 Jan '04

07 Jan '04

Can somebody have a look at this? Thanks, Dan -------- Original Message -------- Subject: [unixODBC-DEV] - UnixODBC, Wine, Crystal Report -- would appreciate insight Date: Tue, 06 Jan 2004 15:07:11 -0500 From: Aurelien Marchand <aurelien.marchand(a)researchcapital.com> Reply-To: unixodbc-dev(a)unixodbc.org To: unixodbc-dev(a)easysoft.com Hi, I am a bit confused as to who I should send this email. Please let me know if this is the wrong place. I am really, really close to making the whole thing work (I'll show in a minute why I think that) but I'm stomped and need some help. I've dumped my WinNT workstation and replaced it with Linux. So far, I can do exactly everything I was able to do (except updating my calendar on the Exchange server used where I work), minus using Crystal Report. I have installed it using CodeWeavers' CrossOver Office and it installed without even a hiccup. I've also installed unixODBC and tested the odbc.ini configuration using isql. It works great when I try to connect to the company's AS400 database. The default library is set to my username and I can query other libraries using the dot (.) as a separator (e.g: SELECT * from OTHERLIB.OTHERTABLE). So far so good: UnixODBC works perfectly to talk to IBM's AS400. Now I need to tell Crystal which drivers to use. I've read on the web that Crystal is not a very good student and thus ignores Windows' ODBC.ini settings but checks what's in the registry. I've also come to understand I must set ODBC.dll = "builtin, native" in my Wine's config file so that it will try to use whatever is set for LIB_ODBC_DRIVER_MANAGER env variable for Windows' ODBC connections. I've come to that point: my system.reg or my user.reg contain one ODBC setting (the same name found on /etc/odbc.ini and ~/.odbc.ini). My wine config file uses "builtin, native" for it's ODBC setting and my ~/.odbc.ini contains proper DSN settings (since I can query from the console using isql). The best part is, when I start Crystal Report, and select ODBC sources, I have in the dropdown that appears all the entries I've put in my ~/.odbc.ini file. As I said earlier, great strides indeed. Now the last missing piece is that it seems Crystal using Wine and unixODBC cannot login properly and retrieve the table list. It just hangs when I expand the "+" box beside a DSN entry. I've enabled sql log (in /etc/odbcinst.ini) but I can't find really relevant information. Let me know if you want to see it. So now I'm stuck. Any ideas on how I can make it work? Note: I've tried to Crystal's DB2 ODBC drivers and also with IBM DB2 ODBC drivers (both for Windows) - although it shouldn't make a difference. Thanks, Aurelien Marchand

2 1

Re: winewrap: fix wrapper linking
by Richard Cohen 07 Jan '04

07 Jan '04

Dimitrie O. Paun wrote: > Richard, > > You patch from Nov 28: > http://www.winehq.org/hypermail/wine-cvs/2003/11/0299.html > says (among other things): > "Compiling with -lwine needs to use the given -L paths." > > In other words, it adds all the -Lxxx libs to the linking step > for the wrapper. I see no reason to do so. At the Windows/DLL > level, we only link with kernel32, and we know exactly where > it is: in DLLDIR. At the Linux/ELF level, we only link with > -lwine, and similarly, we know it resides in LIBDIR. Those libraries only reside there after Wine has been installed. winegcc needs to be able to build programs/* etc. from inside the tree Anyway, it looks like the wrapper will be going away soon ... Richard.

1 0

Notes on implementing mscms.dll - for anybody who's interested in digital colour management
by Mike McCormack 07 Jan '04

07 Jan '04

Hi, For whoever is interested in running Phase One's Capture One software (http://www.phaseone.com/) on Wine, you'll need mscms.dll for Colour Management. Unfortunately Wine has no implementation of it yet. I had a quick look into what is needed to implement mscms.dll (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/icm/icmsta…) It appears the functionality of mscms.dll is mostly defined by the International Color consortium (http://www.color.org), and a free implementation exists(http://www.littlecms.com/, and is available as a (shared?) library on many distros. I think it's feasable to interface that library to an mscms.dll implemented in Wine. I've created a stub library incase anybody wants to have a go at it... mail me if you're interested in working on it. Mike TOPSRCDIR = @top_srcdir@ TOPOBJDIR = ../.. SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = mscms.dll IMPORTS = user32 advapi32 kernel32 ntdll EXTRALIBS = $(LIBUNICODE) $(LIBUUID) EXTRADEFS = -DCOM_NO_WINDOWS_H C_SRCS = \ mscms.c @MAKE_DLL_RULES@ ### Dependencies: /* * Copyright (C) 2004 Mike McCormack for Codeweavers * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include <stdarg.h> #include "windef.h" #include "winbase.h" #include "wingdi.h" #include "icm.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(mscms); BOOL WINAPI SetColorProfileElementSize( HPROFILE hProfile, TAGTYPE tag, DWORD cbSize) { FIXME("%p %08lx %ld\n", hProfile, tag, cbSize); return TRUE; } BOOL WINAPI GetColorProfileElement( HPROFILE hProfile, TAGTYPE tag, DWORD dwOffset, DWORD *pcbSize, PVOID pBuffer, PBOOL pbReference) { FIXME("\n"); return TRUE; } BOOL WINAPI GetCountColorProfileElements( HPROFILE hProfile, PDWORD pnCount) { FIXME("\n"); return TRUE; } BOOL WINAPI SetColorProfileElement( HPROFILE hProfile, TAGTYPE tag, DWORD dwOffset, PDWORD pcbSize, PVOID pBuffer) { FIXME("\n"); return TRUE; } BOOL WINAPI DeleteColorTransform( HTRANSFORM hColorTransform ) { FIXME("\n"); return TRUE; } BOOL WINAPI CloseColorProfile( HPROFILE hProfile ) { FIXME("\n"); return TRUE; } BOOL WINAPI GetColorDirectoryA( LPCSTR pMachineName, LPSTR pBuffer, PDWORD pdwSize ) { FIXME("\n"); return TRUE; } BOOL WINAPI TranslateBitmapBits( HTRANSFORM hColorTransform, PVOID pSrcBits, BMFORMAT bmInput, DWORD dwWidth, DWORD dwHeight, DWORD dwInputStride, PVOID pDestBits, BMFORMAT bmOutput, DWORD dwOutputStride, PBMCALLBACKFN pfnCallback, ULONG ulCallbackData) { FIXME("\n"); return TRUE; } HTRANSFORM WINAPI CreateMultiProfileTransform( PHPROFILE pahProfiles, DWORD nProfiles, DWORD *padwIntent, DWORD nIntents, DWORD dwFlags, DWORD indexPreferredCMM ) { FIXME("\n"); return NULL; } HPROFILE WINAPI OpenColorProfileA( PPROFILE pProfile, DWORD dwDesiredAccess, DWORD dwShareMode, DWORD dwCreationMode) { FIXME("\n"); return NULL; } BOOL WINAPI GetColorProfileElementTag( HPROFILE hProfile, DWORD dwIndex, PTAGTYPE pTag ) { FIXME("\n"); return TRUE; } BOOL WINAPI GetColorProfileHeader( HPROFILE hProfile, PPROFILEHEADER pHeader ) { FIXME("\n"); return TRUE; } @ stdcall SetColorProfileElementSize(ptr long long) @ stdcall GetCountColorProfileElements(ptr ptr) @ stdcall SetColorProfileElement(ptr ptr long ptr ptr) @ stdcall GetColorProfileElement(ptr ptr long ptr ptr ptr) @ stdcall DeleteColorTransform(ptr) @ stdcall CloseColorProfile(ptr) @ stdcall GetColorDirectoryA(str ptr ptr) @ stdcall TranslateBitmapBits(ptr ptr ptr long long long ptr ptr long ptr long) @ stdcall CreateMultiProfileTransform(ptr long ptr long long long) @ stdcall OpenColorProfileA(ptr long long long) @ stdcall GetColorProfileElementTag() @ stdcall GetColorProfileHeader(ptr ptr) /* * Copyright (C) the Wine project * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef __WINE_ICM_H #define __WINE_ICM_H typedef HANDLE HPROFILE; typedef HPROFILE *PHPROFILE; typedef HANDLE HTRANSFORM; typedef DWORD TAGTYPE; typedef TAGTYPE *PTAGTYPE,*LPTAGTYPE; typedef enum { BM_x555RGB = 0x00, BM_565RGB = 0x01, BM_RGBTRIPLETS = 0x02, BM_BGRTRIPLETS = 0x04, BM_xRGBQUADS = 0x08, BM_10b_RGB = 0x09, BM_16b_RGB = 0x0a, BM_xBGRQUADS = 0x10, BM_CMYKQUADS = 0x20, BM_x555XYZ = 0x101, BM_x555Yxz, BM_x555Lab, BM_x555G3CH, BM_XYZTRIPLETS = 0x201, BM_YxyTRIPLETS, BM_LabTRIPLETS, BM_G3CHTRIPLETS, BM_5CHANNEL, BM_6CHANNEL, BM_7CHANNEL, BM_8CHANNEL, BM_GRAY, BM_xXYZQUADS = 0x301, BM_xYxyQUADS, BM_xLabQUADS, BM_xG3CHQUADS, BM_KYMCQUADS, BM_10b_XYZ = 0x401, BM_10b_Yxy, BM_10b_Lab, BM_10b_G3CH, BM_NAMED_INDEX, BM_16b_XYZ = 0x501, BM_16b_Yxy, BM_16b_Lab, BM_16b_G3CH, BM_16b_GRAY, } BMFORMAT; typedef BOOL WINAPI (*PBMCALLBACKFN)(ULONG,ULONG,ULONG); typedef PBMCALLBACKFN LPPBMCALLBACKFN; typedef struct tagPROFILEHEADER { DWORD phSize; DWORD phCMMType; DWORD phVersion; DWORD phClass; DWORD phDataColorSpace; DWORD phConnectionSpace; DWORD phDateTime[3]; DWORD phSignature; DWORD phPlatform; DWORD phProfileFlags; DWORD phManufacturer; DWORD phModel; DWORD phAttributes; DWORD phRenderingIntent; CIEXYZ phIlluminant; DWORD phCreator; BYTE phReserved[44]; } PROFILEHEADER; typedef PROFILEHEADER *PPROFILEHEADER,*LPPROFILEHEADER; typedef struct tagPROFILE { DWORD dwType; PVOID pProfileData; DWORD cbDataSize; } PROFILE; typedef PROFILE *PPROFILE,*LPPROFILE; #endif

1 0

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