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

Winsocket hanging

by Uwe Bonnes

Hallo, some application (jtagserver.exe from Altera Quartus) hangs in Winsock. trace:winsock:DllMain 0x407a0000 0x1 0x1 trace:winsock:DllMain 0x407a0000 0x2 (nil) trace:winsock:WSAStartup verReq=1 trace:winsock:WSAStartup succeeded trace:winsock:WS_socket af=2 type=1 protocol=0 trace:winsock:WSASocketA af=2 type=1 protocol=0 protocol_info=(nil) group=0 flags=0x1 trace:winsock:WSASocketA created 0060 trace:winsock:WS_setsockopt socket: 0060, level 0x6, name 0x1, ptr 406e2c80, len 4 trace:winsock:WS_ioctlsocket socket 0060, cmd 8004667e, ptr 406e2c88 trace:winsock:WS_bind socket 0060, ptr 0x406e2c94, length 16 fixme:winsock:WS_bind Setting WS_SO_REUSEADDR on socket before we binding it trace:winsock:WS_setsockopt socket: 0060, level 0xffff, name 0x4, ptr 406e2c6c, len 4 trace:winsock:WS_listen socket 0060, backlog 10 trace:winsock:__ws_select read 0x406e2bb0, write (nil), excp (nil) timeout 0x406e2cb4 Is this hang expected? More debug information needed? One problem is, that the installer hanged, and I exported only the directory tree from an NT vmware install. As sophisticated NT functionality is used in NT mode (e.g. LockServiceDatabase) I ran with win95 mode in wine. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 13, 2002

LHashValOfNameSysA for 407

by Marcus Meissner

Hi, I have an app here, which uses locale 407, for which we do not implement LHashValOfNameSys yet... It reports: err:ole:LHashValOfNameSysA No hash for LCID 407, returning '0x00424242', please report If someone wants to fix it :) Ciao, Marcus

Dec. 13, 2002

Re: wine/ tools/winebuild/winebuild.man.in tools/w ...

by Francois Gouget

On Fri, 13 Dec 2002, Shachar Shemesh wrote: [...] > If wer'e on the subject, maybe we can enhance the stub files to contain, > for each function, the versions of windows for which it is exported? > > Right now we have a slight anomality where even if we define the windows > version as win95, we still export functions only available under Windows NT. We won't do that. In short it brings a lot of complication and no visible benefit. Besides from the obvious work it represents, for a number of libraries the version of the OS may not be as important as the version of IE that is installed. Furthermore, not exporting certain APIs is just one aspect. Win95 still exports most of the Unicode APIs but all they do is return 'error not implemented'. So 'perfect' emulation would require that we cause these functions to fail in the same way. It would also require that we remove support for various flags like the WAVE_FORMAT_DIRECT flag in winmm, the security related options, 16/32bit coordinates, and adjust countless other details. So this would be pretty complex and it's very doubtful that applications rely on such things. If they did they would not work on NT/200/XP for one thing. And in the many years I have been reading wine-devel, I don't remember anyone hitting this problem. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

Dec. 13, 2002

Re: Wineboot

by Shachar Shemesh

Dimitrie O. Paun wrote: >On December 13, 2002 02:48 am, Shachar Shemesh wrote: > > >>I want to speak out against Dimi's idea. >> >> > >Gee, thanks, that gives me a warm and fuzzy... :) > > > >>The reason is that Run and RunOnce may rely on future events happening. >>I know places where RunOnce was a full fledge GUI program which required >>further user intervention. Do we really want to pop that up when wine >>EXITS? >> >> > >And where exactly did you get this idea from? Please reread my message: > > http://www.winehq.com/hypermail/wine-devel/2002/11/0494.html > >It clearly states "on server startup"... > > > Sorry, my misunderstanding, then. I am not at all familiar with the wineserver (maybe it's time, eh?). I got the impression it will be difficult to perform this task both without race conditions, and in a way that will put the entire power of Win32 at our disposal. If you (or anyone else who has better familiarity with the server) can recommend a specific source file and line number where such a change can be performed, we can start testing right away. Shachar

Dec. 13, 2002

Re: Wineboot

by Shachar Shemesh

I want to speak out against Dimi's idea. It is fine as far as renaming files in Wininit.ini, and maybe performing the delayed RenameFileEx. It is not the right place, however, for performing the Run and RunOnce sections. The reason is that Run and RunOnce may rely on future events happening. I know places where RunOnce was a full fledge GUI program which required further user intervention. Do we really want to pop that up when wine EXITS? Fabian Cenedese wrote: > > If the reboot gets delayed and I just quit the program, is the reboot > still called > at wine exit? Or would it be better if wine checks on every start if > there are > things necessary to complete (copy files...)? Maybe already too late. I think that is the right thing to do. If someone clicked "do not reboot Windows", maybe becasue that's what they are used to have to click, they still expect the windows to be ok the next time. > > bye Fabi > > >

Dec. 13, 2002

Re: Wineboot

by Dimitrie O. Paun

On December 13, 2002 02:48 am, Shachar Shemesh wrote: > I want to speak out against Dimi's idea. Gee, thanks, that gives me a warm and fuzzy... :) > The reason is that Run and RunOnce may rely on future events happening. > I know places where RunOnce was a full fledge GUI program which required > further user intervention. Do we really want to pop that up when wine > EXITS? And where exactly did you get this idea from? Please reread my message: http://www.winehq.com/hypermail/wine-devel/2002/11/0494.html It clearly states "on server startup"... -- Dimi.

Dec. 13, 2002

Re: wine/ tools/winebuild/winebuild.man.in tools/w ...

by Shachar Shemesh

Alexandre Julliard wrote: >Right, it wouldn't work because of the stubs and the relay debugging >support. What I'm thinking of doing at some point is to allow using a >.def as alternative to a .spec, for cases where you don't need the >extra features, like when porting an existing dll to Winelib. But for >Wine itself we'll probably stick to .spec for the time being. > > > If wer'e on the subject, maybe we can enhance the stub files to contain, for each function, the versions of windows for which it is exported? Right now we have a slight anomality where even if we define the windows version as win95, we still export functions only available under Windows NT. Shachar

Dec. 13, 2002

Re: Wineboot

by Fabian Cenedese

> > Personally, I would still prefer an external utility, to mimic the case > > when the installer asks you "do you want me to reboot now?" and you say > > "no, I'll do it later". In that case, I don't want to have file renamed, > > etc... until I decide it's time to perform a reboot (by invoking wineboot). > > So, in my opinion, the wine_need_reboot() function you name in that > > pseudo-code should return TRUE only after one of the reboot functions have > > been called (InitiateSystemShutdown, InitiateSystemShutdownEx, > > ExitWindowsEx). > >So yeah, what you say does not conflict in any way with what I was proposing. >Indeed, the wine_need_reboot() function should behave as you say. In fact, if >we should exit the server of system shutdown for this to work as I see it... If the reboot gets delayed and I just quit the program, is the reboot still called at wine exit? Or would it be better if wine checks on every start if there are things necessary to complete (copy files...)? Maybe already too late. bye Fabi

Dec. 13, 2002

Re: wine/ tools/winebuild/winebuild.man.in tools/w ...

by Greg Turner

wow, I got a novel after all! Thanks for the helpful info. On Thursday 12 December 2002 07:38 pm, Alexandre Julliard wrote: > The main drawback is of course that it's easy for the dll and its > import library to get out of sync and then you are in trouble, > because the functions that you found at link time in the import lib > do not exist at load time in the actual dll. The Unix way of having a > single library is much cleaner, but of course we don't expect > Microsoft to do things the clean way <g> perhaps not... but now I understand how somebody can link a win32 app and run it on all the pseudo-incompatible windows platforms. > The actual implementation is a bit different between Windows and > Wine: under Windows the import library has to be in the standard > library file format that the linker understands (xxx.lib, or libxxx.a > for gcc), and it is generated from the dll .def file. Under Wine we > don't need a real library since everything is done inside winebuild > without involving the Unix linker, so we use the .def file directly > and skip the intermediate step of building a library object file. > > Hope this helps... Indeed it has, thanks. I'll definitely check out some of the source for this -- in particular, the parts that got patched recently, if only to skim and get the overall process memorized, so I don't feel like I'm breaking things everytime I touch the makefiles (and, of course, I will look into those .lib file's, which I've been ignoring for as long as I can remember ;) ) -- gmt

Dec. 13, 2002

New Contributions / Donations page

by Tom Wickline

Hello, The Contrib page at : http://www.winehq.com/about/index.php?contrib is in need of updating and I would like to do this :) I would like to split this page into two pages 1) Contributing to web maintenance, graphics, documentation, testing, bug triaging and coding. 2) Monetary or equipment donations Any one want to Volinteer to help do this ? Tom

Dec. 12, 2002

Re: XIM support patch

by Dimitrie O. Paun

On December 13, 2002 12:30 am, liu spider wrote: > 58a59 > > > WINE_DECLARE_DEBUG_CHANNEL(xim); > > 275a277 > > > extern BOOL XIM_SetIMPos(RECT ); Please send unified diffs. For how to submit patches, please read: http://www.winehq.org/development/#patches http://www.winehq.com/hypermail/wine-devel/2002/09/0127.html -- Dimi.

Dec. 12, 2002

Re: wine/ tools/winebuild/winebuild.man.in tools/w ...

by Alexandre Julliard

Steven Edwards <steven_ed4153(a)yahoo.com> writes: > So are we going to move away from using the *.spec files at some > point and just use def's by themselves? I dont think this would work > because of the stubs functions and I'm sure there is more about the > .spec system I dont understand. Right, it wouldn't work because of the stubs and the relay debugging support. What I'm thinking of doing at some point is to allow using a .def as alternative to a .spec, for cases where you don't need the extra features, like when porting an existing dll to Winelib. But for Wine itself we'll probably stick to .spec for the time being. -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

Re: wine/ tools/winebuild/winebuild.man.in tools/w ...

by Steven Edwards

> The actual implementation is a bit different between Windows and Wine: > under Windows the import library has to be in the standard library > file format that the linker understands (xxx.lib, or libxxx.a for > gcc), and it is generated from the dll .def file. Under Wine we don't > need a real library since everything is done inside winebuild without > involving the Unix linker, so we use the .def file directly and skip > the intermediate step of building a library object file. So are we going to move away from using the *.spec files at some point and just use def's by themselves? I dont think this would work because of the stubs functions and I'm sure there is more about the .spec system I dont understand. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Dec. 12, 2002

Re: wine/ tools/winebuild/winebuild.man.in tools/w ...

by Alexandre Julliard

Greg Turner <gmturner007(a)ameritech.net> writes: > I'm sure it's all quite evident to you and the other old-timers around > here, so sorry to be slow! Also, if I'm asking you to write a novel, > just let me know what I need to read up on. Thanks!! The idea is to mimic the way import libraries work under Windows, so that's what you should look into. Basically the Microsoft linker doesn't know how to link directly against a dll, so to use a dll you have to link against a "stub" static library that contains just a list of the functions exported by the dll. Under Unix the linker knows how to link against the same .so files that the dynamic loader uses at run time, so there is no need for separate import libraries. The benefit of import libraries is that it reduces dependencies in the build process, because you can generate all the import libraries first and then build the dlls in the order you like, since they no longer depend on each other. This also allows circular dependencies between dlls, a misfeature that Microsoft uses unfortunately. The main drawback is of course that it's easy for the dll and its import library to get out of sync and then you are in trouble, because the functions that you found at link time in the import lib do not exist at load time in the actual dll. The Unix way of having a single library is much cleaner, but of course we don't expect Microsoft to do things the clean way <g> The actual implementation is a bit different between Windows and Wine: under Windows the import library has to be in the standard library file format that the linker understands (xxx.lib, or libxxx.a for gcc), and it is generated from the dll .def file. Under Wine we don't need a real library since everything is done inside winebuild without involving the Unix linker, so we use the .def file directly and skip the intermediate step of building a library object file. Hope this helps... -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

WinME conformance tests - 12 Dec 02

by Justin

>From Kevin Podgursky justintyme(a)accesswave.ca Compared to http://fgouget.free.fr/wine/tests-en.shtml Dec 12, 02 Advapi32/registry - crashed - last messages in terminal: registry.c:123: Test failed: type 2 is not REG_SZ registry.c:134: Test failed: expected ERROR_SUCCESS, got 234 registry.c:135: Test failed: val_count set to 20 instead of 4 registry.c:136: Test failed: data_count set to 24 instead of 7 registry.c:137: Test failed: type 2 is not REG_SZ registry.c:138: Test failed: value is 'xxxxxxxxxx' instead of Test registry.c:139: Test failed: data is 'xxxxxxxxxx' instead of foobar registry.c:153: Test failed: expected ERROR_MORE_DATA, got 0 registry.c:155: Test failed: data_count set to 2 instead of 7*sizeof(WCHAR) registry.c:156: Test failed: type 1234 is not REG_SZ registry.c:167: Test failed: expected ERROR_MORE_DATA, got 0 registry.c:169: Test failed: data_count set to 20 instead of 7*sizeof(WCHAR) registry.c:170: Test failed: type 1234 is not REG_SZ registry.c:181: Test failed: expected ERROR_MORE_DATA, got 0 registry.c:182: Test failed: val_count set to 20 instead of 4 registry.c:183: Test failed: data_count set to 2 instead of 7*sizeof(WCHAR) registry.c:184: Test failed: type 1234 is not REG_SZ registry.c:185: Test failed: value is not 'Test' registry.c:196: Test failed: val_count set to 20 instead of 4 registry.c:197: Test failed: data_count set to 20 instead of 7*sizeof(WCHAR) registry.c:198: Test failed: type 1234 is not REG_SZ registry.c:199: Test failed: value is not 'Test' registry.c:200: Test failed: data is not 'foobar' dsound/dsound passed kernel/alloc - same results as for Win95 kernel/atom F:\Temp>kernel32_test.exe atom - hmm does this mean passed or unsupported? atom.c:55:WARNING: Unicode atom APIs are not supported on this platform atom: 163850 tests executed, 0 marked as todo, 0 failures. kernel/codepage F:\Temp>kernel32_test.exe codepage codepage.c:40: Test failed: any negative value should work as strlen() + 1 codepage: 2 tests executed, 0 marked as todo, 1 failure. kernel/directory - passed kernel/drive - passed kernel/environ - passed kernel/file - same comments as Win95 - line numbers different F:\Temp>kernel32_test.exe file file.c:631: Test failed: WriteFile error 183 file.c:632: Test failed: expected number of bytes written 0 file.c:633:Current offset = 0100 file.c:634: Test failed: expected file offset 21 file.c:639: Test failed: WriteFile error 87 file.c:640: Test failed: expected number of bytes written 0 file.c:642: Test failed: expected file offset 517 file.c:656: Test failed: ReadFile error 0 file.c:657: Test failed: expected number of bytes read 0 file.c:658:Current offset = 0000 file.c:659: Test failed: expected file offset 21 file.c:661: Test failed: pattern match failed file: 487224 tests executed, 0 marked as todo, 10 failures. kernel/format_msg Same as for Win95 kernel/generated - passed kernel/locale F:\Temp>kernel32_test.exe locale locale.c:126: Test failed: GetTimeFormat with len=2 got xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxx¦¦ instead of AMxx locale.c:181: Test failed: GetDateFormat got xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxx¦¦- instead of Saxx locale.c:199: Test failed: GetDateFormatW allowed flags and format locale.c:205: Test failed: GetDateFormatW did not detect null buffer pointer. locale.c:208: Test failed: GetDateFormatW did not permit null buffer pointer whe n counting. locale.c:224: Test failed: Day of week correction failed locale.c:312: Test failed: GetNumberFormat with len=2 got xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxx¦¦____W instead of 2,xx locale.c:270: Test failed: GetCurrencyFormat got xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxx¦¦____W instead of $23.53 locale: 54 tests executed, 0 marked as todo, 8 failures. kernel/path F:\Temp>kernel32_test.exe path path.c:738: Test failed: GetLongPathNameA returned 'F:\shortdir\pathtest.pth' in stead of 'C:\shortdir\pathtest.pth' path.c:889:TMP=F:\TEMP path.c:900:TMP=C:\WINDOWS path.c:910:TMP=C:\ path.c:920:TMP=C: path: 1772 tests executed, 0 marked as todo, 1 failure. kernel/process - passed kernel/thread F:\Temp>kernel32_test.exe thread thread.c:273: Test failed: SuspendThread did not obey access restrictions thread.c:275: Test failed: ResumeThread did not obey access restrictions thread.c:323: Test failed: TerminateThread did not obey access restrictions thread.c:393: Test failed: SetThreadPriority did not obey access restrictions thread.c:395: Test failed: GetThreadPriority did not obey access restrictions thread.c:403: Test failed: GetExitCodeThread did not obey access restrictions thread.c:430: Test failed: SetThreadPriorityBoost Failed thread.c:432: Test failed: GetThreadPriorityBoost Failed thread.c:434: Test failed: SetThreadPriorityBoost Failed thread.c:436: Test failed: GetThreadPriorityBoost Failed thread: 103 tests executed, 0 marked as todo, 10 failures. msvcrt/scanf - passed netapi32/access -crash with message box The NETAPI32_TEST.EXE file is linked to missing export NETAPI32.DLL:NetApiBufferSize (Same occurs if just netapi32_test is executed without the access parameter.) netapi32/apibuf - same as above netapi32/wksta - same as above ntdll - no such file in zip oleaut32 - no such file in zip rpcrt4/rpc - passed shell32/generated - passed shell32/shlfileop F:\Temp>shell32_test shlfileop shlfileop.c:286: Test failed: Files are copied to other directory shlfileop.c:287: Test failed: The file is copied shlfileop: 121 tests executed, 0 marked as todo, 2 failures. shlwapi/clist F:\Temp>shlwapi_test clist clist.c:367: Test failed: allowed bad element size clist.c:372: Test failed: allowed adding a container clist: 236 tests executed, 0 marked as todo, 2 failures. shlwapi/generated - passed shlwapi/shreg - crashed F:\Temp>shlwapi_test shreg shreg.c:206: Test failed: (ImARatherLongButIndeedNeededString) shreg.c:207: Test failed: (ImARatherLongButIndeedNeededString) shreg.c:263: Test failed: didn't open copy user32/class - passed user32/generated - passed user32/sysparams - corrupts the environment and properties for command.com user32/win - crashes Last output from terminal win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 00000908 win.c:62: Test failed: Wrong result for GetParent 00000908 expected 00000000 win.c:70: Test failed: Wrong result for GA_ROOTOWNER 000008F8 expected 0000078C win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 00000908 win.c:62: Test failed: Wrong result for GetParent 00000908 expected 00000000 win.c:70: Test failed: Wrong result for GA_ROOTOWNER 000008F8 expected 0000078C win.c:140:created top-level 00000788 win.c:62: Test failed: Wrong result for GetParent 00000000 expected 00000080 win.c:70: Test failed: Wrong result for GA_ROOTOWNER 00000788 expected 00000080 win.c:150:created owned top-level 00000784 win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 000008F8 win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 000008F8 win.c:62: Test failed: Wrong result for GetParent 00000000 expected 000008F8 win.c:70: Test failed: Wrong result for GA_ROOTOWNER 00000784 expected 000008F8 win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 000008F8 win.c:62: Test failed: Wrong result for GetParent 00000000 expected 00000080 win.c:70: Test failed: Wrong result for GA_ROOTOWNER 00000784 expected 00000080 win.c:160:created popup 00000790 win.c:62: Test failed: Wrong result for GetParent 00000000 expected 00000080 win.c:70: Test failed: Wrong result for GA_ROOTOWNER 00000790 expected 00000080 win.c:170:created owned popup 00000794 win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 000008F8 win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 000008F8 win.c:62: Test failed: Wrong result for GetParent 000008F8 expected 00000080 win.c:70: Test failed: Wrong result for GA_ROOTOWNER 000008F8 expected 00000080 win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 000008F8 win.c:62: Test failed: Wrong result for GetParent 000008F8 expected 00000000 win.c:70: Test failed: Wrong result for GA_ROOTOWNER 000008F8 expected 00000794 win.c:180:created top-level owned by child 0000079C win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 000008F8 win.c:186:created popup owned by desktop 000007A0 win.c:192:created popup owned by child 000007AC win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 000008F8 win.c:198:created WS_CHILD popup 000007A8 win.c:204:created owned WS_CHILD popup 000007A4 win.c:60: Test failed: Wrong result for GWL_HWNDPARENT 00000000 expected 000008F8 win.c:209:testing parent changes user32/wsprintf F:\Temp>user32_test wsprintf wsprintf.c:46: Test failed: wsPrintfW length failure wsprintf: 4 tests executed, 0 marked as todo, 1 failure. wininet/generated - passed wininet/http last messages in terminal http.c:78:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0067E808 4 http.c:104:InternetConnectA --> http.c:108:HttpOpenRequestA <-- http.c:78:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0067EA7C 4 http.c:122:HttpOpenRequestA --> http.c:126:HttpSendRequestA --> http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20)0067E8B4 12 http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 0067E890 12 http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000000 0 http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 0067E9A0 4 http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00000000 0 http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 0067E988 4 http.c:133:HttpSendRequestA <-- http.c:140:Option 0x17 -> 1 8 http.c:144:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:149:Option 0x16 -> 1 HTTP/1.1 200 OK Date: Fri, 13 Dec 2002 01:13:16 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4.1.2 X-Powered-By: PHP/4.1.2 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html http.c:154:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:158:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) http.c:163:Option 0x1 -> 1 text/html http.c:166:Entery Query loop http.c:183:ReadFile -> 1 743 http.c:183:ReadFile -> 1 3348 http.c:183:ReadFile -> 1 4380 http.c:183:ReadFile -> 1 1460 http.c:183:ReadFile -> 1 1974 http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_HANDLE_CLOSING(70) 0067EAA8 4 http.c:78:Callback 00CC0008 0xdeadbeef INTERNET_STATUS_HANDLE_CLOSING(70) 0067EAA8 4 http: 24 tests executed, 0 marked as todo, 1 failure. winmm/wave - passed ws2_32/sock - passed hth Kevin

Dec. 12, 2002

Prototype implementation of a shared memory winserver

by Peter Hunnisett

Hi, in the quest for speed parity in multimedia applications TransGaming has investigated a few options in dealing with the nasty overhead of the present wineserver implementation. I have just recently posted a prototype patch for a shared memory wineserver, to the ReWind project, (http://sourceforge.net/mailarchive/forum.php?thread_id=1413925&forum_id=8836) which, in a small benchmarking suite, has shown some remarkable performance gains. The concept for the shm wineserver came about during discussions at the OLS in 2002 and remained a concept until a little while ago we had enough time to create a working prototype. TransGaming is donating this code to the ReWind project in the hopes that it will encourage other Wine developers to continue to share code under the more open BSD/X11 style license and to help overcome the remaining issues with this approach. Rather than make a really long technical email, we decided that a bit of a paper would be more appropriate (it also has links to the patches). The paper can be found at http://www.transgaming.com/papers/shmserver.html Regards, Peter Hunnisett peter(a)transgaming.com

Dec. 12, 2002

Re: wine/ tools/winebuild/winebuild.man.in tools/w ...

by Greg Turner

On Thursday 12 December 2002 10:34 am, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > Alexandre, mind if you explain in a few words the rationale > > for this one? Not that I have a problem with it, but I like > > to know where you're going... :) > > This is for import libraries; basically the import libs (actually the > .def files) need to contain all functions, even the ones we don't > want to import from ELF libraries, because the same files are used > for the Windows libraries. So the check is now done at the time we > import the library, not at the time we generate the import lib. Wow, it's like a whole new wine now! This wave of changes seems to be going over my head a bit, and your explanation doesn't seem to clear the fog for me... perhaps it's time I read some of the "scary parts" of the wine source and got a clue about how the wine compile/link/load sequence actually works? (I should note that, so far, ignorance of these parts of wine has been fine for me; presumably, this wave of changes doesn't make such knowledge any more necessary, but it does pique my curiosity.) For those of us who still don't "get it," could you provide a bit more explanation here? (i.e.: "as if to a child" ;) ) By the above, do you mean, in some sense, that some symbols get resolved at run-time instead of at compile time? What are the expected consequences/benefits of this change? I'm sure it's all quite evident to you and the other old-timers around here, so sorry to be slow! Also, if I'm asking you to write a novel, just let me know what I need to read up on. Thanks!! -- gmt

Dec. 12, 2002

Re: Cross-compiling the tests with MinGW

by Steven Edwards

Francois Gouget wrote: >Changelog: > > * documentation/testing.sgml > > Document how to cross-compile the tests with MinGW > > > When I get the time I will submit mingw on Windows documentation. Could be a few more weeks. Thanks Steven

Dec. 12, 2002

RE: Houston, we have a problem...

by Patrik Stridvall

> On December 12, 2002 02:07 pm, Alexandre Julliard wrote: > > > In which case, shouldn't our includes use <> instead of > ""? Using "" > > > is not 100% correct, let alone non standard. I know, > minor point, but... > > > :) > > > > I guess they should, yes. > > A perfect job for a cool Perl script :) Sure. Will try to look at in the next few days. > I haven't heard much from Patrik lately... <g> You will here more from me soon. I'm going to have a long vacation around christmas where I will have much more time to work with Wine. Of course family and friends usually takes up more time than usual around christmas as well...

Dec. 12, 2002

Re: Wineboot

by Alberto Massari

At 21.16 12/12/2002 +0100, Joerg Mayer wrote: >On Thu, Dec 12, 2002 at 11:14:43AM -0500, Dimitrie O. Paun wrote: > > Hmm, that message is a bit out of contest. It _is_ an external utility that > > does the reboot (it's the wineboot utility), the problem is when to invoke > > it. > >Just wondering: Why is the reboot needed? Just because M$ does it or >are there valid reasons for Wine to reboot as well? What are these reasons? >Can they be fixed? Should they be fixed? The "reboot" in question is not the reboot of the Linux machine, it should be a command that executes the operation done by Windows upon startup. The need comes from APIs like MoveFileEx (when a special flag is used to say "move or delete this file when the system starts, so I am sure this file is not in use"), and from registry settings like Run and RunOnce. Ciao, Alberto > Ciao > Jörg > >-- >Joerg Mayer <jmayer(a)loplof.de> >I found out that "pro" means "instead of" (as in proconsul). Now I know >what proactive means.

Dec. 12, 2002

Re: Win2000 Conformance Test Results...

by Francois Gouget

Hmmm, I meant to send this two days ago... On Tue, 10 Dec 2002, David Fraser wrote: [...] > for kernel32_test path, I got this additional error (before all the others) I have made tons of fixes to the kernel/path test and it should now work much better. I just uploaded the new version of the tests compiled from my sources. One can download them from the usual URL: http://fgouget.free.fr/wine/winetests.zip [...] > >process: 116 tests executed, 0 marked as todo, 4 failures. > > > Exactly the same except I have 10 messages interspersed with these, saying: > tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. > Why these extra messages? Because this executable invokes itself to test CreateProcess. And each time it exits it prints statistics about how many tests passed and failed, although the child processes are not actually performing any test. So these messages can be ignored. > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:218: Test failed: (6) > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:219: Test failed: (6,43) > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:220: Test failed: (3435973836) [...] > Same but I get 0 for all your 3435973836 which is 0xcccccccc. Must be a > debug/release build thing - variable not being initialized. Should not be the case. The code does: dwType = -1; dwRet = SHQueryValueExA( hKey, "Test3", NULL, &dwType, NULL, &dwSize); ok( dwType == REG_SZ, "(%lu)" , dwType); So we should either get -1 or something that makes sense, not 0xcccccccc. This needs to be investigated more. > Should we print out some of these results in hex as well to make life > easier? We should print them in just one format, decimal or hex, whichever makes more sense. > >I will now be concentrating on working out what is wrong with these > >tests :) Yep, I think this is priority number one now. Running the tests on more platforms would only return pretty much the same list of bugs again and again. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Dec. 12, 2002

Re: Wineboot

by Shachar Shemesh

Joerg Mayer wrote: >On Thu, Dec 12, 2002 at 11:14:43AM -0500, Dimitrie O. Paun wrote: > > >>Hmm, that message is a bit out of contest. It _is_ an external utility that >>does the reboot (it's the wineboot utility), the problem is when to invoke >>it. >> >> > >Just wondering: Why is the reboot needed? Just because M$ does it or >are there valid reasons for Wine to reboot as well? What are these reasons? > In a nutshell - some operations are delayed until reboot due to file locks, running processes, services and drivers, and a host of other reasons. The reasons you don't see such things in Unix are: a. Seperate functionality is better seperated into seperate process, thus making restarting a specific aspect of the system easier. b. Files are never locked, and therefor can always be replaced. >Can they be fixed? > Maybe. That's a pretty serious question and one for two minor startups. > Should they be fixed? > I don't think so. Wine restart is far less painful than a Windows restart. Sometime in the future, maybe. > > Ciao > Jörg > >-- >Joerg Mayer <jmayer(a)loplof.de> >I found out that "pro" means "instead of" (as in proconsul). Now I know >what proactive means. > > >

Dec. 12, 2002

Re: wine/tools mingwrap.c

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Then, what happens if a header similar to excpt.h includes a header such > as stdlib.h. It will only work with msvcrt's stdlib.h thus causing > trouble if the user is using the regular C library headers instead. I don't see why it would only work with msvcrt, and if so it should be fixed. People should be able to choose between using the msvcrt headers or the standard Unix ones; if headers that don't exist on Unix are in msvcrt it forces everybody to use msvcrt headers. Now there may well be Windows-only headers like io.h that don't make sense outside of msvcrt, but I certainly don't see any reason to not use excpt.h along with the Unix headers. -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

Re: Obsolete APIs?

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > For instance, GetRunTimes is exported by urlmon on Windows 95 and > NT4, but there is no trace of it in Windows 98, Millenium, 2000 or XP. > There is also no trace of it in the SDK headers. > Some are exported only by NT4. > What should I do with such APIs? Should I add them to Wine's spec > files anyway? No need, unless we find an app that needs them. > Wine sides on XP for this one. Should we not care (after all > Microsoft doesn't), or should we try to match the Windows 95 ordinal? I > would vote for the second otherwise scripts diffing the export lists > will complain about the difference every time we run them. We shouldn't care. Ordinals should be specified only where strictly necessary. If the ordinals differ between Windows versions then the script shouldn't check them. -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

Re: wine/tools mingwrap.c

by Francois Gouget

On 12 Dec 2002, Alexandre Julliard wrote: [...] > Actually there is no excpt.h in the standard unix includes, so it > doesn't need to be in msvcrt/, it can be moved with the normal > includes. I'm not sure it's a good idea to mix the MSVCRT headers with the others. Sure there is no excpt.h header in the standard Unix headers. But there are many headers we cannot move: malloc.h, stdlib.h, string.h, etc. So we'll end up with some headers (conio.h, crtdbg.h, io.h) mixed in with the regular Wine headers, and some others which will be kept separate. Then there is the case of headers such as direct.h that exist on some Unix platforms and not on others. Then, what happens if a header similar to excpt.h includes a header such as stdlib.h. It will only work with msvcrt's stdlib.h thus causing trouble if the user is using the regular C library headers instead. So I'm not convinved that moving excpt.h is any better or cleaner than leaving it in the msvcrt directory. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Dec. 12, 2002

Obsolete APIs?

by Francois Gouget

While checking the differences between the set of APIs exported by Windows dlls and the set of APIs exported by Wine's libraries I found some strange cases: * some APIs are exported on Windows 95 and/or NT4 but are not exported in more recent versions of Windows. For instance, GetRunTimes is exported by urlmon on Windows 95 and NT4, but there is no trace of it in Windows 98, Millenium, 2000 or XP. There is also no trace of it in the SDK headers. Some are exported only by NT4. What should I do with such APIs? Should I add them to Wine's spec files anyway? * Some APIs are exported at a specific ordinal in Windows 95, but are exported 'normally' in more recent versions of Windows. For instance, still in urlmon, on Windows 95 and NT4 I have: api95/urlmon-api.txt: 4 2D 00047D0B IsLoggingEnabledW apint4/urlmon-api.txt: 4 2D 00047E4A IsLoggingEnabledW Clearly the ordinal was manually specified since the ordinal of IsLoggingEnabledA is 46. However in the XP library these are exported in the usual alphabetical order: 49 30 000439E9 IsLoggingEnabledA 50 31 00043AC6 IsLoggingEnabledW Wine sides on XP for this one. Should we not care (after all Microsoft doesn't), or should we try to match the Windows 95 ordinal? I would vote for the second otherwise scripts diffing the export lists will complain about the difference every time we run them. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

Dec. 12, 2002

Re: wine/tools mingwrap.c

by Dimitrie O. Paun

On December 12, 2002 03:24 pm, Alexandre Julliard wrote: > Actually there is no excpt.h in the standard unix includes, so it > doesn't need to be in msvcrt/, it can be moved with the normal > includes. Do patch -p0 < excpt.diff cp include/msvcrt/excpt.h include/excpt.h cvs rm -f include/msvcrt/excpt.h cvs add include/excpt.h ChangeLog Move excpt.h out of include/msvcrt/ as it does not conflict with any standard Unix header. Index: dlls/kernel/computername.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/computername.c,v retrieving revision 1.4 diff -u -r1.4 computername.c --- dlls/kernel/computername.c 27 Nov 2002 21:38:06 -0000 1.4 +++ dlls/kernel/computername.c 12 Dec 2002 20:55:50 -0000 @@ -38,7 +38,7 @@ #include "winternl.h" #include "wine/unicode.h" #include "wine/exception.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "wine/debug.h" #include "file.h" Index: dlls/kernel/console.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/console.c,v retrieving revision 1.11 diff -u -r1.11 console.c --- dlls/kernel/console.c 21 Nov 2002 23:45:31 -0000 1.11 +++ dlls/kernel/console.c 12 Dec 2002 20:55:50 -0000 @@ -46,7 +46,7 @@ #include "wine/exception.h" #include "wine/unicode.h" #include "wine/debug.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "console_private.h" WINE_DEFAULT_DEBUG_CHANNEL(console); Index: dlls/msvcrt/cppexcept.c =================================================================== RCS file: /var/cvs/wine/dlls/msvcrt/cppexcept.c,v retrieving revision 1.4 diff -u -r1.4 cppexcept.c --- dlls/msvcrt/cppexcept.c 1 Nov 2002 01:50:51 -0000 1.4 +++ dlls/msvcrt/cppexcept.c 12 Dec 2002 21:03:34 -0000 @@ -29,7 +29,7 @@ #include "winternl.h" #include "msvcrt.h" #include "wine/exception.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(seh); Index: dlls/msvcrt/except.c =================================================================== RCS file: /var/cvs/wine/dlls/msvcrt/except.c,v retrieving revision 1.22 diff -u -r1.22 except.c --- dlls/msvcrt/except.c 1 Nov 2002 01:50:51 -0000 1.22 +++ dlls/msvcrt/except.c 12 Dec 2002 21:03:21 -0000 @@ -34,7 +34,7 @@ #include "msvcrt.h" #include "msvcrt/setjmp.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "wine/debug.h" Index: dlls/ntdll/debugtools.c =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/debugtools.c,v retrieving revision 1.25 diff -u -r1.25 debugtools.c --- dlls/ntdll/debugtools.c 13 Nov 2002 19:38:17 -0000 1.25 +++ dlls/ntdll/debugtools.c 12 Dec 2002 20:55:51 -0000 @@ -41,7 +41,7 @@ #include "winbase.h" #include "winnt.h" #include "winternl.h" -#include "msvcrt/excpt.h" +#include "excpt.h" WINE_DECLARE_DEBUG_CHANNEL(tid); Index: dlls/ntdll/exception.c =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/exception.c,v retrieving revision 1.50 diff -u -r1.50 exception.c --- dlls/ntdll/exception.c 10 Dec 2002 22:56:45 -0000 1.50 +++ dlls/ntdll/exception.c 12 Dec 2002 20:55:51 -0000 @@ -33,7 +33,7 @@ #include "miscemu.h" #include "wine/server.h" #include "wine/debug.h" -#include "msvcrt/excpt.h" +#include "excpt.h" WINE_DEFAULT_DEBUG_CHANNEL(seh); Index: dlls/ntdll/loader.c =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/loader.c,v retrieving revision 1.7 diff -u -r1.7 loader.c --- dlls/ntdll/loader.c 12 Sep 2002 22:07:03 -0000 1.7 +++ dlls/ntdll/loader.c 12 Dec 2002 20:55:52 -0000 @@ -22,7 +22,7 @@ #include "module.h" #include "wine/exception.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(ntdll); Index: dlls/ntdll/sec.c =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/sec.c,v retrieving revision 1.31 diff -u -r1.31 sec.c --- dlls/ntdll/sec.c 5 Dec 2002 19:56:16 -0000 1.31 +++ dlls/ntdll/sec.c 12 Dec 2002 20:55:51 -0000 @@ -42,7 +42,7 @@ #include "winternl.h" #include "winreg.h" #include "ntdll_misc.h" -#include "msvcrt/excpt.h" +#include "excpt.h" WINE_DEFAULT_DEBUG_CHANNEL(ntdll); Index: dlls/user/lstr.c =================================================================== RCS file: /var/cvs/wine/dlls/user/lstr.c,v retrieving revision 1.24 diff -u -r1.24 lstr.c --- dlls/user/lstr.c 15 Oct 2002 21:00:06 -0000 1.24 +++ dlls/user/lstr.c 12 Dec 2002 20:55:54 -0000 @@ -36,7 +36,7 @@ #include "wine/winbase16.h" #include "wine/winuser16.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "wine/debug.h" Index: dlls/winedos/dosvm.c =================================================================== RCS file: /var/cvs/wine/dlls/winedos/dosvm.c,v retrieving revision 1.31 diff -u -r1.31 dosvm.c --- dlls/winedos/dosvm.c 2 Dec 2002 21:39:58 -0000 1.31 +++ dlls/winedos/dosvm.c 12 Dec 2002 20:55:55 -0000 @@ -52,7 +52,7 @@ #include "dosvm.h" #include "stackframe.h" #include "wine/debug.h" -#include "msvcrt/excpt.h" +#include "excpt.h" WINE_DEFAULT_DEBUG_CHANNEL(int); WINE_DECLARE_DEBUG_CHANNEL(module); Index: dlls/wininet/internet.c =================================================================== RCS file: /var/cvs/wine/dlls/wininet/internet.c,v retrieving revision 1.47 diff -u -r1.47 internet.c --- dlls/wininet/internet.c 5 Dec 2002 19:54:40 -0000 1.47 +++ dlls/wininet/internet.c 12 Dec 2002 20:55:56 -0000 @@ -54,7 +54,7 @@ #include "shlwapi.h" #include "wine/exception.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "internet.h" Index: files/dos_fs.c =================================================================== RCS file: /var/cvs/wine/files/dos_fs.c,v retrieving revision 1.125 diff -u -r1.125 dos_fs.c --- files/dos_fs.c 11 Dec 2002 00:19:56 -0000 1.125 +++ files/dos_fs.c 12 Dec 2002 20:55:57 -0000 @@ -52,7 +52,7 @@ #include "msdos.h" #include "winternl.h" #include "wine/server.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "smb.h" Index: include/windows.h =================================================================== RCS file: /var/cvs/wine/include/windows.h,v retrieving revision 1.55 diff -u -r1.55 windows.h --- include/windows.h 23 Oct 2002 20:16:23 -0000 1.55 +++ include/windows.h 12 Dec 2002 20:55:59 -0000 @@ -33,7 +33,7 @@ #else /* RC_INVOKED && !NOWINRES */ /* All the basic includes */ -#include "msvcrt/excpt.h" +#include "excpt.h" #include "windef.h" #include "winbase.h" #include "wingdi.h" Index: loader/resource.c =================================================================== RCS file: /var/cvs/wine/loader/resource.c,v retrieving revision 1.64 diff -u -r1.64 resource.c --- loader/resource.c 21 Nov 2002 03:45:02 -0000 1.64 +++ loader/resource.c 12 Dec 2002 20:55:59 -0000 @@ -42,7 +42,7 @@ #include "wine/debug.h" #include "winerror.h" #include "winnls.h" -#include "msvcrt/excpt.h" +#include "excpt.h" WINE_DEFAULT_DEBUG_CHANNEL(resource); Index: loader/ne/module.c =================================================================== RCS file: /var/cvs/wine/loader/ne/module.c,v retrieving revision 1.124 diff -u -r1.124 module.c --- loader/ne/module.c 21 Nov 2002 03:45:02 -0000 1.124 +++ loader/ne/module.c 12 Dec 2002 20:55:59 -0000 @@ -42,7 +42,7 @@ #include "snoop.h" #include "builtin16.h" #include "stackframe.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "wine/exception.h" #include "wine/debug.h" Index: memory/global.c =================================================================== RCS file: /var/cvs/wine/memory/global.c,v retrieving revision 1.72 diff -u -r1.72 global.c --- memory/global.c 21 Nov 2002 03:45:02 -0000 1.72 +++ memory/global.c 12 Dec 2002 20:55:59 -0000 @@ -47,7 +47,7 @@ #include "module.h" #include "wine/debug.h" #include "winerror.h" -#include "msvcrt/excpt.h" +#include "excpt.h" WINE_DEFAULT_DEBUG_CHANNEL(global); Index: memory/string.c =================================================================== RCS file: /var/cvs/wine/memory/string.c,v retrieving revision 1.44 diff -u -r1.44 string.c --- memory/string.c 16 Aug 2002 20:00:48 -0000 1.44 +++ memory/string.c 12 Dec 2002 20:55:59 -0000 @@ -29,7 +29,7 @@ #include "wine/unicode.h" #include "winerror.h" #include "winnls.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(string); Index: memory/virtual.c =================================================================== RCS file: /var/cvs/wine/memory/virtual.c,v retrieving revision 1.88 diff -u -r1.88 virtual.c --- memory/virtual.c 4 Nov 2002 22:43:24 -0000 1.88 +++ memory/virtual.c 12 Dec 2002 20:55:59 -0000 @@ -34,7 +34,7 @@ #include "winternl.h" #include "winerror.h" #include "wine/exception.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(virtual); Index: programs/winedbg/dbg.y =================================================================== RCS file: /var/cvs/wine/programs/winedbg/dbg.y,v retrieving revision 1.2 diff -u -r1.2 dbg.y --- programs/winedbg/dbg.y 16 Sep 2002 19:26:48 -0000 1.2 +++ programs/winedbg/dbg.y 12 Dec 2002 21:05:29 -0000 @@ -32,7 +32,7 @@ #include "wine/exception.h" #include "debugger.h" #include "expr.h" -#include "msvcrt/excpt.h" +#include "excpt.h" static void mode_command(int); int yylex(void); Index: programs/winedbg/winedbg.c =================================================================== RCS file: /var/cvs/wine/programs/winedbg/winedbg.c,v retrieving revision 1.2 diff -u -r1.2 winedbg.c --- programs/winedbg/winedbg.c 28 Oct 2002 23:56:58 -0000 1.2 +++ programs/winedbg/winedbg.c 12 Dec 2002 20:56:00 -0000 @@ -31,7 +31,7 @@ #include "winreg.h" #include "wingdi.h" #include "winuser.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "wine/library.h" DBG_PROCESS* DEBUG_CurrProcess = NULL; Index: relay32/snoop.c =================================================================== RCS file: /var/cvs/wine/relay32/snoop.c,v retrieving revision 1.59 diff -u -r1.59 snoop.c --- relay32/snoop.c 21 Nov 2002 03:45:02 -0000 1.59 +++ relay32/snoop.c 12 Dec 2002 20:56:00 -0000 @@ -31,7 +31,7 @@ #include "stackframe.h" #include "wine/debug.h" #include "wine/exception.h" -#include "msvcrt/excpt.h" +#include "excpt.h" WINE_DEFAULT_DEBUG_CHANNEL(snoop); Index: win32/except.c =================================================================== RCS file: /var/cvs/wine/win32/except.c,v retrieving revision 1.62 diff -u -r1.62 except.c --- win32/except.c 21 Nov 2002 03:45:01 -0000 1.62 +++ win32/except.c 12 Dec 2002 20:56:02 -0000 @@ -48,7 +48,7 @@ #include "wine/library.h" #include "thread.h" #include "stackframe.h" -#include "msvcrt/excpt.h" +#include "excpt.h" #include "wine/server.h" #include "wine/unicode.h" #include "wine/debug.h" Index: windows/cursoricon.c =================================================================== RCS file: /var/cvs/wine/windows/cursoricon.c,v retrieving revision 1.61 diff -u -r1.61 cursoricon.c --- windows/cursoricon.c 3 Dec 2002 23:34:53 -0000 1.61 +++ windows/cursoricon.c 12 Dec 2002 20:56:03 -0000 @@ -59,7 +59,7 @@ #include "user.h" #include "message.h" #include "winerror.h" -#include "msvcrt/excpt.h" +#include "excpt.h" WINE_DEFAULT_DEBUG_CHANNEL(cursor); WINE_DECLARE_DEBUG_CHANNEL(icon); -- Dimi.

Dec. 12, 2002

Re: wine/tools mingwrap.c

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > And in the Wine source where we need excpt.h we simply make sure > we do > #include <msvcrt/excpt.h> > > Comments? Actually there is no excpt.h in the standard unix includes, so it doesn't need to be in msvcrt/, it can be moved with the normal includes. -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

Re: Wineboot

by Joerg Mayer

On Thu, Dec 12, 2002 at 11:14:43AM -0500, Dimitrie O. Paun wrote: > Hmm, that message is a bit out of contest. It _is_ an external utility that > does the reboot (it's the wineboot utility), the problem is when to invoke > it. Just wondering: Why is the reboot needed? Just because M$ does it or are there valid reasons for Wine to reboot as well? What are these reasons? Can they be fixed? Should they be fixed? Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Dec. 12, 2002

Re: wine/tools mingwrap.c

by Dimitrie O. Paun

On December 12, 2002 02:07 pm, Alexandre Julliard wrote: > IMO our headers should be fixed, they shouldn't have the msvcrt > prefix. Fine. What about this: include/windows.h:#include "msvcrt/excpt.h" I have a patch removing the msvcrt/ prefix from the msvcrt/*.h files, but in Wine it's a bit tricky as we want to use some msvcrt, and libc. We can do this: #ifndef __WINE__ # include <excpt.h> #endif And in the Wine source where we need excpt.h we simply make sure we do #include <msvcrt/excpt.h> Comments? -- Dimi.

Dec. 12, 2002

Re: Houston, we have a problem...

by Dimitrie O. Paun

On December 12, 2002 02:07 pm, Alexandre Julliard wrote: > > In which case, shouldn't our includes use <> instead of ""? Using "" > > is not 100% correct, let alone non standard. I know, minor point, but... > > :) > > I guess they should, yes. A perfect job for a cool Perl script :) I haven't heard much from Patrik lately... <g> -- Dimi.

Dec. 12, 2002

Re: Houston, we have a problem...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > In which case, shouldn't our includes use <> instead of ""? Using "" > is not 100% correct, let alone non standard. I know, minor point, but... :) I guess they should, yes. -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

Re: wine/tools mingwrap.c

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Either way, we need to fix this somehow. IMO our headers should be fixed, they shouldn't have the msvcrt prefix. -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

Re: Wine conformance testing on native platforms

by Francois Gouget

On Thu, 12 Dec 2002, Dimitrie O. Paun wrote: > On December 12, 2002 10:22 am, Luke Stras wrote: > > It's a bunch of extra work, but what I'm thinking is this: for every > > platform, link back to the appropriate wine-devel message from the > > archives which contains the most recent test results. > > I was actually hoping the Francois monitors this reports, and keeps > his nice page (http://fgouget.free.fr/wine/tests-en.shtml) up to date, > which should be exactly what you need, and a lot nicer than looking > at the raw reports. Yep, I'm trying to keep it up to date. It would be much less work if there were fewer errors btw (hint, hint). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Dec. 12, 2002

Key capturing and dxgrab

by chrismorgan＠rcn.com

If you run with dxgrab on and a game is fullscreen or in a wine desktop window the mouse is stuck there, even though some keystokes can get passed into the window manager and focus can be lost. I was thinking that a solution to this would be to enable dxgrab when the wine window was given focus and to disable dxgrab when the user wanted to change focus using alt-tab(seems like a natural default key combination). This would allow a dxgrab window in a wine desktop window but also let the desktop be useable for other things without requiring the app to be closed before mouse control was returned. Where in wine would should they keystroke interception be perfomed? Does such functionality already exist through windows api calls(I wasn't able to find much info on the web through a google search)? Thanks, Chris

Dec. 12, 2002

Re: wine/tools mingwrap.c

by Dimitrie O. Paun

On December 10, 2002 09:04 pm, Alexandre Julliard wrote: > I think it's reasonable to require the user to specify an explicit > include path if they install Wine in a non-standard directory. This > shouldn't be a common case anyway. Well, this still does not work, because our msvcrt headers have includes like so: #include "msvcrt/wctype.h" and these fail miserably because msvcrt is not in the path. I think we should install msvcrt at the same level as wine (as in my original proposal), the chances of a conflict are virtually NULL. Either way, we need to fix this somehow. -- Dimi.

Dec. 12, 2002

Re: Houston, we have a problem...

by Dimitrie O. Paun

On December 12, 2002 12:51 pm, Alexandre Julliard wrote: > This was changed a long time ago. The only difference now is that > makedep complains if it cannot find a "" include and says nothing for > a <> include, but otherwise they work just the same. In which case, shouldn't our includes use <> instead of ""? Using "" is not 100% correct, let alone non standard. I know, minor point, but... :) -- Dimi.

Dec. 12, 2002

Re: Houston, we have a problem...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Speaking of makedep: we have this non-standard "" vs <> convention > for include files, which is (1) potentially confusing, and (2) can > cause problems in Winelib apps that have private headers that conflict > with names of our headers. This was changed a long time ago. The only difference now is that makedep complains if it cannot find a "" include and says nothing for a <> include, but otherwise they work just the same. -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

Re: Houston, we have a problem...

by Dimitrie O. Paun

On December 12, 2002 11:38 am, Alexandre Julliard wrote: > The depend: target doesn't depend on the tools, because that would > slow things down a lot. makedep doesn't change often enough for this > to be a real problem; and a make clean will fix it anyway. Speaking of makedep: we have this non-standard "" vs <> convention for include files, which is (1) potentially confusing, and (2) can cause problems in Winelib apps that have private headers that conflict with names of our headers. If I understand it correctly, the rationale is to be able to easily segregate the host system headers from the Win32 headers, as we don't want the former included in the dependencies for speed reasons (otherwise we would slow down make). But what about determining these are runtime. A simple stat in our include dir is fast, and should tell us whether we need to include the file in the dependencies or not. -- Dimi.

Dec. 12, 2002

Re: make checklink broken?

by Alexandre Julliard

Greg Turner <gmturner007(a)ameritech.net> writes: > Am I missing something, or is make "checklink" broken? It seems only to > run for a few directories now, whereas the rest show "nothing to do". These days checklink only needs to run for dlls that have 16-bit files, the rest should be caught by the -z defs option. -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

Re: Houston, we have a problem...

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Now I must say that I wonder why this was not done automatically. > Shouldn't the .c.o dependency kick in automatically in > tools/Makefile.in? Maybe you can solve this one? The depend: target doesn't depend on the tools, because that would slow things down a lot. makedep doesn't change often enough for this to be a real problem; and a make clean will fix it anyway. -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

Re: wine/ tools/winebuild/winebuild.man.in tools/w ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Alexandre, mind if you explain in a few words the rationale > for this one? Not that I have a problem with it, but I like > to know where you're going... :) This is for import libraries; basically the import libs (actually the .def files) need to contain all functions, even the ones we don't want to import from ELF libraries, because the same files are used for the Windows libraries. So the check is now done at the time we import the library, not at the time we generate the import lib. -- Alexandre Julliard julliard(a)winehq.com

Dec. 12, 2002

Re: Wineboot

by Alberto Massari

At 10.42 12/12/2002 -0500, you wrote: >On December 11, 2002 03:51 pm, Shachar Shemesh wrote: > > I have vulenteered to do likewise. I have not, however, managed to get > > any statement from Andy regarding the current state, or any other > > replies. If he replies to this email, great. If not, I suggest we work > > on it together. > >I also did not get any response to my (potentially silly) proposal: > http://www.winehq.com/hypermail/wine-devel/2002/11/0494.html Personally, I would still prefer an external utility, to mimic the case when the installer asks you "do you want me to reboot now?" and you say "no, I'll do it later". In that case, I don't want to have file renamed, etc... until I decide it's time to perform a reboot (by invoking wineboot). So, in my opinion, the wine_need_reboot() function you name in that pseudo-code should return TRUE only after one of the reboot functions have been called (InitiateSystemShutdown, InitiateSystemShutdownEx, ExitWindowsEx). Alberto

Dec. 12, 2002

Re: Wineboot

by Dimitrie O. Paun

On December 12, 2002 11:16 am, Alberto Massari wrote: > Personally, I would still prefer an external utility, to mimic the case > when the installer asks you "do you want me to reboot now?" and you say > "no, I'll do it later". In that case, I don't want to have file renamed, > etc... until I decide it's time to perform a reboot (by invoking wineboot). > So, in my opinion, the wine_need_reboot() function you name in that > pseudo-code should return TRUE only after one of the reboot functions have > been called (InitiateSystemShutdown, InitiateSystemShutdownEx, > ExitWindowsEx). Hmm, that message is a bit out of contest. It _is_ an external utility that does the reboot (it's the wineboot utility), the problem is when to invoke it. The reason I proposed to invoke it from the server rather than from the process is because: -- it seems that's the place that's equivalent to rebooting windows -- it avoids a bunch of nasty race conditions -- it is very simple So yeah, what you say does not conflict in any way with what I was proposing. Indeed, the wine_need_reboot() function should behave as you say. In fact, if we should exit the server of system shutdown for this to work as I see it... -- Dimi.

Dec. 12, 2002

Re: Wineboot

by Dimitrie O. Paun

On December 11, 2002 03:51 pm, Shachar Shemesh wrote: > I have vulenteered to do likewise. I have not, however, managed to get > any statement from Andy regarding the current state, or any other > replies. If he replies to this email, great. If not, I suggest we work > on it together. I also did not get any response to my (potentially silly) proposal: http://www.winehq.com/hypermail/wine-devel/2002/11/0494.html -- Dimi.

Dec. 12, 2002

NT conformance update

by Luke Stras

Changes in NT conformance test results from 2002/12/10 to 2002/12/11. Original test results are available at <http://www.winehq.com/hypermail/wine-devel/2002/12/0423.html> dsound_test: - new, passed successfully kernel32_test: - file.c:578 - DeleteFile test now passess successfully - path.c:568, 569, 591, 592, 656, 657 now pass - path.c:242 et. al - check?-? now pass - path.c:822-908 now pass msvcrt_test: - test 'msvcrt' does not exist any more I think that's everything a vgrep returns, anyways. I've put up the test results from both days, as well as a diff, up at: <http://www.utias.toronto.edu/~stras/wine/> I will try to keep this updated regularly, as the available test suite changes. I'm too busy right not to compile my own tests, so I have to rely on Francois to compile tests for me. -- Luke Stras <stras(a)utias.toronto.edu> "The meek can have the Earth; the rest of us have other plans" --Henry Spencer

Dec. 12, 2002

any one have korean XIM support patch?

by liu spider

hello everyone: I just working hard to improve / implement the XIM support in wine based on the work of Mike McCormack. His original patch support Japanese, thus I think mime will work with japanese too. While I heared that there was a patch for korean XIM support, I think I'd better check with it to ensure my patch support korean too. Anyone know / has it? Could you send me a copy? I am Chinese, so now I only test my patch with Chinese input method. thanks liuspider __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Dec. 12, 2002

Fwd: any one have korean XIM support patch?

by liu spider

hello everyone: I just working hard to improve / implement the XIM support in wine based on the work of Mike McCormack. His original patch support Japanese, thus I think mime will work with japanese too. While I heared that there was a patch for korean XIM support, I think I'd better check with it to ensure my patch support korean too. Anyone know / has it? Could you send me a copy? I am Chinese, so now I only test my patch with Chinese input method. thanks liuspider __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Dec. 12, 2002

Re: Wine conformance testing on native platforms

by Dimitrie O. Paun

On December 12, 2002 10:22 am, Luke Stras wrote: > It's a bunch of extra work, but what I'm thinking is this: for every > platform, link back to the appropriate wine-devel message from the > archives which contains the most recent test results. I was actually hoping the Francois monitors this reports, and keeps his nice page (http://fgouget.free.fr/wine/tests-en.shtml) up to date, which should be exactly what you need, and a lot nicer than looking at the raw reports. > [1] Flight vibration test for my baby coming up on Friday! I'm > expecting the worst. Good luck! What is it, BTW? -- Dimi.

Dec. 12, 2002

make checklink broken?

by Greg Turner

Am I missing something, or is make "checklink" broken? It seems only to run for a few directories now, whereas the rest show "nothing to do". Here's a chunk of the output: ... make[2]: Entering directory `/var/src/wine/dlls/winmm/wineoss' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/winmm/wineoss' make[2]: Entering directory `/var/src/wine/dlls/winnls' gcc -o checklink -Wl,-rpath,../../dlls -Wl,-rpath,../../library -Wl,-rpath,../../unicode ../../library/checklink.c winnls32.spec.o winnls.o winnls32.dll.dbg.o -L../../dlls -L../../library -lwine -lm && rm -f checklink make[2]: Leaving directory `/var/src/wine/dlls/winnls' make[2]: Entering directory `/var/src/wine/dlls/winsock' gcc -o checklink -Wl,-rpath,../../dlls -Wl,-rpath,../../library -Wl,-rpath,../../unicode ../../library/checklink.c ws2_32.spec.o async.o socket.o ws2_32.dll.dbg.o -L../../dlls -L../../library -lwine -lm && rm -f checklink make[2]: Leaving directory `/var/src/wine/dlls/winsock' make[2]: Entering directory `/var/src/wine/dlls/winspool' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/winspool' make[2]: Entering directory `/var/src/wine/dlls/wintrust' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/wintrust' make[2]: Entering directory `/var/src/wine/dlls/wow32' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/wow32' make[2]: Entering directory `/var/src/wine/dlls/wsock32' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/wsock32' make[2]: Entering directory `/var/src/wine/dlls/glu32' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/glu32' make[2]: Entering directory `/var/src/wine/dlls/d3d8' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/d3d8' ... -- gmt

Dec. 12, 2002