- wine-devel - winehq.org

complie fails on _set_error_mode(_OUT_TO_STDERR)
by Sean Mitchell 27 Nov '02

27 Nov '02

Hullo All.... I think I've found another missing bit. My compile fails on _set_error_mode(_OUT_TO_STDERR) because it seems that none of the modevals are defined in msvcrt/stdlib.h http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/ vcref_set_error_mode.asp I'll just use an integer for now, but this might warrant looking at... again, is it appropriate for me to open a bug for this? Cheers, Sean +----------------------------------------------------------+ | Sean Mitchell Phoenix Interactive Design | | Software Engineer 137 Dundas St | | smitchell(a)phoenix-interactive.com London, ON | | 519-679-2913 x237 Canada | | 519-679-6773 fax N6A 1E9 | +----------------------------------------------------------+

1 0

Announce: Vstserver, vstlib, vstladspa and k_vst~
by Kjetil S. Matheussen 27 Nov '02

27 Nov '02

VSTServer V0.0.1. ----------------- First release. Beta, but usable. ABOUT Vstserver is a wine program that must be running when using programs using vstlib. Vstlib is a library that can be used by programs to run windows vst audio plugins under linux/freebsd/i386solaris/etc. RUNNING Vstserver is started like this: "wine vstserver.so". You probably want to set the "VST_PATH" environment variable pointing to your plugins first. DEVELOPMENT Vstserver is released under the GPL, and vstlib under LGPL. If there comes many source-contributions, I will probably make it a sourceforge project. To use vstlib in a program, look at the tests/exampleclient program, and various vst plug-in documentation. The interface to the vstlib consists only of two functions (new/delete), the rest is like you would do when programming for windows, macos(X), beos, irix, etc. CURRENT STATUS Vstserver seems to be very stable. I have not found any plug-ins that wont run, and I am not able to hear any latency. And plug-ins does not seem to cause more cpu-power than under windows. No GUI or graphics-support yet. BUGS 1. When running the ladspa "listplugins" program many times in a row, I get the following errors before the server freeze: err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:region:CombineRgn Invalid rgn=0000 err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:region:CombineRgn Invalid rgn=0000 err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:region:CombineRgn Invalid rgn=0000 err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this. I dont know what this is. Its not errors coming from the vstserver program. It seems to be related to X, allthough no graphics is used in the vstserver. I hope its just the buggy libXrender.so library that wine shouts about each time it starts. 2. Shared memory handlig might be faulty. I suspect that it doesnt free resources. (see server/shmhandler.c) 3. I havent read the vst plug-in documentation yet, and dont know everything about it. This especially goes for the "AudioMasterCallback" function, which for now just returns 1. I guess some more work needs to be done in this area, and for the various dispatch opcodes too. 4. The processReplacing function in vstlib should perhaps be made just by calling the process fuction. But I dont understand the difference between processReplacing and processing. FUTURE Add GUI and graphics support to the server (help wanted). And maybe make a DX-plugin server. (would be fun running pi-warp under linux). CREDITS vstserver and vstlib are made by Kjetil S. Matheussen / Notam. k.s.matheussen(a)notam02.no Some programming hints is gathered by looking at the pd vst-object plugin~ source and the jack soundserver source. vst ladspa plugin v0.0.1 - alpha --------------------------------- Makes vst plugins located in $VST_PATH appear as ladspa plugins. I'm not sure how well this one actually works. The northpole plugin seems to work, but others don't. Oh well, its alpha for now. k_vst~, a Pd tilde object for hosting VST plug-ins. --------------------------------------------------- This is really just the plugin~ source made by Jarno Seppänen, but with a few lines changed (very few that is) to make it work with vst-plugins using the vstlib. The name was changed from plugin~ to k_vst~ to avoid nameclash with the plugin~ object running ladspa plugins. This object is for i386 non-windows (ie. linux/freebsd) only. This one works very well! ------------------------- vstserver, ladspavst and k_vst~ are open-source programs made at Notam / Oslo, and can be downloaded from from http://www.notam02.no/arkiv/src/ --

1 1

Help needed - CreateScalableFontResource
by Shachar Shemesh 27 Nov '02

27 Nov '02

Hi list, We have in Israel a lawyer who has cought on to the idea of open source, and is helping "The Cause"(tm) here quite a lot. As part of his activities he is wants to demonstrate a Hebrew law and precedance lookup program at a conference on Dec 2nd using Wine, and he asked for my help. When trying to run the program, I get the following error: sun@sun:~/c/PD_OR/EXE$ LANG=he_IL wine PDWIN G Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.491, setting to 0xdeadbeef fixme:win:stub_USER_490 stub fixme:font:CreateScalableFontResourceA (0,"C:\\PD_OR\\FONTS/AMIR____.FOT","C:\\PD_OR\\FONTS/AMIR____.TTF",(null)): stub fixme:font:CreateScalableFontResourceA (0,"C:\\PD_OR\\FONTS/AMIRBLD_.FOT","C:\\PD_OR\\FONTS/AMIRBLD_.TTF",(null)): stub fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. The application then goes on to display a error message saying (In hebrew) "The fonts for the application could not be found, please reinstall...". The fonts are indeed available in C:\PD_OR\FONTS as TTF files. It seems the application calls CreateScalableFontResource, and then tries to register the fonts. Copying the TTF fonts to the fonts directory did not solve this problem. I am looking for some solution, even a workaround, that will solve this problem for me. I have contact with the application's developers, and they are very interested in getting this to work (not interested enough to actually install Linux, but they are interested enough to answer technical questions about the app). My questions: A. Is there any way I can patch Wine to fool the app into thinking that part succeeds? Or is performing this test necessary, for some strange reason, in order to use the TTF fonts? B. It MAY be possible to ask the developers to actually modify their code to a moderate degree, in order to get this app to work. Is there anything in particular I can ask them? C. Is anyone working on this API? I don't know the first thing about font files and resources, and while I CAN learn, is someone with already existing knowledge can do something about it, it would be much preferable. Thanks, Shachar

3 8

Getting DirectX emulation to work
by David D. Hagood 27 Nov '02

27 Nov '02

Since I can no longer get OpenGL textures to work under Wine, I'd like to try to get the DirectX emulation working. However, when I configure an app to use DirectX, I get a "You have selected a mode your graphics card does not support" message. Since the color depth and resolution are the same as OpenGL settings that work (save for the hosed textures), I would think this should work. Are there some magic registry entries that need to be created?

3 2

RE: Whither SwitchToThread()?
by Sean Mitchell 27 Nov '02

27 Nov '02

> -----Original Message----- > From: Francois Gouget [mailto:fgouget@free.fr] > To: Sean Mitchell > Because someone forgot to update winbase.h, that's all. Use > this patch: Thanks so much! I told my boss that I posted the query last night and had a response with a fix waiting for me this morning. He is lukewarm about Open Source, but when I told him about this he was very, very impressed. He's never seen that sort of response from a commercial vendor except in a few emergency situations. Incidentally, should I open a bug for this, or is it already committed to the tree? Cheers, Sean

2 1

Re: Winelib Apps v0.1
by Mark Hannessen 27 Nov '02

27 Nov '02

very nice site. but there is one ( very ) small i would like to see. i think colors should represent the status of winelibs mozilla has a yellow color ( but does not run ) once a prog runs ( putty ) it should be green ( or some other color ) this way we can easily see what works and what does not perhaps we could include a link to the project website as well ? Mark Hannessen On Tuesday 26 November 2002 06:04, wine-devel-request(a)winehq.com wrote: > Folks, > > Version 0.1 of the Winelib Applications page is available here: > http://www.dssd.ca/wine/Winelib-Apps-0.1.html > > The current version is always available at this address > http://www.dssd.ca/wine/Winelib-Apps.html > > Your comments, and suggestions are highly appreciated.

6 13

IKernel fails
by Uwe Bonnes 27 Nov '02

27 Nov '02

Hallo, Altera's Quartus Web-Edition https://www.altera.com/support/software/download/altera_design/quartus_we/d… (110 MByt Download) fails: fixme:ole:_xread Read only 0 of 4 bytes from 0x50. fixme:ole:_StubReaderThread Failed with hres 80004005 Any help welcome! Are more Info needed? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 3

tools/wpp, ppdebug
by Tapio Kautto 27 Nov '02

27 Nov '02

Hi! I'm trying to compile recent versions of wine with Debian Sid. My compile stops in wpp saying that variable ppdebug is not defined. I added line int ppdebug=1; in wpp.c, and it compiles. Am I missing something, or is this a bug? Thanks, Eleknader

1 0

Re: Coding standards
by David Laight 27 Nov '02

27 Nov '02

> I found a couple that used ~4space indent, and used tabs too (they > seemed to expect 1tab = 8, as the code looked neat in a standard text > editor). Probably vi with autoindent, tabstop=8 and shiftwidth=4 (my preferred indent). More fun can be had arguing over whether to do: if (...) { ... } else { ... } or: if (...) { ... } else { ... } or: if (...) { ... } else { ... } If you have a paper listing you definitely need '} else {' on a single line. Otherwise you lose track of the control flow when reading it. (Never mind that you get many more lines on a page/screen.) Of course the opening '{' for a function MUST be in column 1. A coding standard really ought to discuss namespace usage and pollution. Any reasonable layout is usually ok. (OTOH I much prefer that tab stops be at 8 character intervals.) David -- David Laight: david(a)l8s.co.uk

6 8

Performance issues
by João Alfredo 27 Nov '02

27 Nov '02

Hello people, How can i improve performance in GUI applications under wine? I have a cobol application here made with microfocus netexpress and I can see the button icons reloading every type I refresh the screen. I'm using wine from CVS with a PIII 900Mhz redhat 7.3 box. Thanks in advance! -- João Alfredo G. Batista <joaoalf(a)dotx.com.br> ou <jagbdotx(a)yahoo.com.br> * dotX Consultoria, Serviços e Conectividade * http://www.dotx.com.br * Departamento de Desenvolvimento

1 0

Wine app
by Fabian Cenedese 27 Nov '02

27 Nov '02

Hi I came across this page: http://www.unrealized.com/references/ "Unfortunately we have no information on running UnrealEd in Linux. Perhaps someone has had success running it under WINE? If so, please let us know about it so we can get more information for others trying to run UnrealEd on their Linux box." So I guess they would like to hear if someone had success and would also put a "works with wine" on their page once it's running. bye Fabi

1 0

Run .bat files
by Fabian Cenedese 27 Nov '02

27 Nov '02

Hi I found out that I can't run batch files directly. It gives me "cannot determine executable type". Maybe there is a possibility to start it right away with wcmd or wineconsole. The problem is that it must also work if a running app calls the batch files with CreateThread. Could it be a solution to add a new type to MODULE_GetBinaryType and then start a console with the batch file argument? If this is already too late, is there another possibility inside wine? Would it work if I change the call to CreateThread("cmd file.bat")? But then it has to work on all Windows95, NT and wine (command.com, cmd.exe, wcmd). Thanks bye Fabi

3 3

Problem in winemaker
by Sylvain Petreolle 27 Nov '02

27 Nov '02

Trying to debug the cygwin installer that isn't able to reread where it saves the pakages, I wanted to compiler the installer as Winelib. running 'winemaker .' in setup source dir fails when analysing IOStreamProvider.h, at line 1193 in winemaker. I attached the file. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com /* * Copyright (c) 2002, Robert Collins. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * A copy of the GNU General Public License can be found at * http://www.gnu.org/ * * Written by Robert Collins <rbtcollins(a)hotmail.com> * */ #ifndef _IOSTREAMPROVIDER_H_ #define _IOSTREAMPROVIDER_H_ #include "io_stream.h" #include "String++.h" /* An IOStreamProvider provides the interface for io_stream::open and * related calls to operate. */ class IOStreamProvider { public: virtual int exists (String const &) const = 0; virtual int remove (String const &) const = 0; virtual int mklink (String const &, String const &, io_stream_link_t) const = 0; virtual io_stream *open (String const &,String const &) const = 0; virtual ~IOStreamProvider (){} virtual int move (String const &,String const &) const = 0; virtual int mkdir_p (enum path_type_t isadir, String const &path) const = 0; String key; // Do not set - managed automatically. protected: IOStreamProvider(){} // no base instances IOStreamProvider(IOStreamProvider const &); // no copy cons IOStreamProvider &operator=(IOStreamProvider const &); // no assignment }; #endif /* _IOSTREAMPROVIDER_H_ */

1 0

RE: Some fixes in capabilities
by Medland, Bill 26 Nov '02

26 Nov '02

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin@winehq.com]On > Behalf Of Andreas Mohr > Sent: Tuesday, November 26, 2002 1:48 PM > To: Lionel Ulmer > Cc: Wine Devel > Subject: Re: Some fixes in capabilities > > > On Tue, Nov 26, 2002 at 10:23:55PM +0100, Lionel Ulmer wrote: > > Hi all, > > snip > > Note: is there a way from DLL X to activate relay debugging > ? What happens > > is that SS2 somehow freezes at one point and doing a > relay trace from > > the start is about a 3 GB file... So what I would > like to do is at a > > specific function in the D3D code that I know to be > just before the > > freeze, call 'activate relay' and voila, I have > relaying on :-) (to be > > able to do that for all DLLs would be even better). > > > > But well, considering DLL separation and all that, I > doubt that this > > would be possible :-/ > > Oh pleeeeze... I thought that at least the Wine developers are reading > the wine docu properly... ;-) > > Let's see... first you use completely inacceptable words, and then > you admit to never reading the docu... bad, bad, very bad guy. :) > > Read wine.man. It explains how to do relay logging for a single DLL. > Although I'm afraid that this might actually be broken at the moment > maybe :-\ Unfair. That doesn't help someone who wants a full relay trace because they don't know where the problem is, but doesn't want to start until close to the problem. I have myself wished we had the capability. Admittedly my traces were smaller than 3GB but I would be very happy to get rid of the top 100MB of the trace. > > -- > "My attitude is, everybody should try competing with > Microsoft once in their life. Once." > - Marc Andreessen, former Netscape lead employee, in a > "browser wars" interview > > Bill

2 1

Wrong list for last 3 patches
by Vincent Béron 26 Nov '02

26 Nov '02

Sorry, the last 3 patches were sent to the wrong list. At least they weren't big. Alexandre, do you want me to resend them to wine-patches proper? Vincent

2 1

RE: Working with GDI+
by Patrik Stridvall 26 Nov '02

26 Nov '02

> Having to port System.Windows.Forms and System.Drawing to > Linux, I would like > to know how GDI+ works under Wine and WineLib? It definitely doesn't work with Winelib since there are neither any header files nor any implementation. Whether a GDI+ using application works under Wine I have no idea. My guess probably not. Try and find out. :-)

1 0

Wine bug-testing methodologies
by Saravanakumar Soundarrajan 26 Nov '02

26 Nov '02

Sorry If I am going off the topic, I am a user of wine and I am looking for some information about it. I am doing a research paper on Open Source Software Quality how OSS quality is maintained and Wine is one of topics of discussion. I have been looking for some information on how Wine Bug Testing is done and the methodologies used in Testing Wine(something like how whitebox testing, regression testing, path-testing, etc., are done). I was wondering if anybody knows any website or any information where I can find more on this topic. It will be very helpful for my research. Thanks and Regards, SK. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail

1 0

wine and asyncronous file i/o
by Martin Fuchs 26 Nov '02

26 Nov '02

Hi! I've got an application, which uses an asynchron file stream library. I uses ReadFileEx() and alertable wait with SleepEx(). This doesn't work right with wine. It seems to get caught in an endless loop. Wine and wineserver together use 100 % cpu power. Does anyone already know, what's going wrong here? I had a quick look at the implementation in wine, but couldn't find any hint about missing functionality or some thing like this. Which debug switches wold be usefull to trace this? -- Martin Fuchs martin-fuchs(a)gmx.net

4 16

Fix for a warning in hal.c
by Vincent Béron 26 Nov '02

26 Nov '02

Changelog: Fix for incompatible pointer type in hal.c. Vincent

1 0

Fix for a warning in time.c
by Vincent Béron 26 Nov '02

26 Nov '02

Changelog: Fix for implicit declaration of abs. Vincent

1 0

Fix for a warning in xrender.c
by Vincent Béron 26 Nov '02

26 Nov '02

Changelog: Fix for deprecated use of label at the end of compound statement in xrender.c. Vincent

1 0

Working with GDI+
by François-Denis Gonthier 26 Nov '02

26 Nov '02

Having to port System.Windows.Forms and System.Drawing to Linux, I would like to know how GDI+ works under Wine and WineLib? Anyone tried?

1 0

Winelib Applications
by Dimitrie O. Paun 26 Nov '02

26 Nov '02

Folks, A new page has appeared in the Wine constellation <g>. It is still a work in progress, but I hope to release version 0.1 in the next few days, once I have a change to add what I've done on PuTTY, and Visual-MinGW. Check it out: http://www.dssd.ca/wine/Winelib-Apps.html Comments, suggestions, flames -- all welcome! -- Dimi.

3 6

self-registerable COM server dlls
by John K. Hohm 26 Nov '02

26 Nov '02

I believe I have a workable method for defining the registration data needed to register and unregister self-registerable COM server dlls like ole32 et. al. that is easy enough to maintain and reasonably efficient. The only real objection I can anticipate is that I use char's instead of WCHAR's, and my reason is that the infrequency of use of these functions makes ease of maintenance more important than performance. I have attached (hopefully as text/plain) the header for the regsvr helper, and the comcat_main.c to give a feel for usage. Comments, please? /* * self-registerable dll helper functions * * Copyright (C) 2002 John K. Hohm * * 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 */ /* regsvr_register and regsvr_unregister take a pointer to registration data. The format of that data is as such (in RFC2234 ABNF): reg_data := LWSP "[" *"!" predef_key "\0" [ "=" value "\0" ] *sub_data "]" ; ! means delete (recursively) when unregistering sub_data := key_data / value_data key_data := LWSP "[" *"!" key "\0" [ "=" value "\0" ] *sub_data "]" ; ! means delete (recursively) when unregistering value_data := LWSP *"!" value_name "\0" "=" value "\0" ; ! means delete when unregistering predef_key := "HKCR" ; others could be added as necessary key := +CHAR value_name := +CHAR value := +CHAR */ HRESULT regsvr_register(char const *data); HRESULT regsvr_unregister(char const *data); /* * exported dll functions for comcat.dll * * Copyright (C) 2002 John K. Hohm * * 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 "comcat.h" #include "regsvr.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(ole); DWORD dll_ref = 0; HINSTANCE COMCAT_hInstance = 0; /*********************************************************************** * Global string constant definitions */ const WCHAR clsid_keyname[6] = { 'C', 'L', 'S', 'I', 'D', 0 }; /*********************************************************************** * Registration data */ static char const regsvr_data[] = "[HKCR\0 [CLSID\0 [!{0002E005-0000-0000-C000-000000000046}\0=StdComponentCategoriesMgr\0 [InProcServer32\0=comcat.dll\0 ThreadingModel\0=Both\0 ] ] ] ]"; /*********************************************************************** * DllMain */ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID fImpLoad) { TRACE("%p 0x%lx %p\n", hinstDLL, fdwReason, fImpLoad); switch(fdwReason) { case DLL_PROCESS_ATTACH: COMCAT_hInstance = hinstDLL; break; case DLL_PROCESS_DETACH: COMCAT_hInstance = 0; break; } return TRUE; } /*********************************************************************** * DllGetClassObject (COMCAT.@) */ HRESULT WINAPI COMCAT_DllGetClassObject(REFCLSID rclsid, REFIID iid, LPVOID *ppv) { *ppv = NULL; if (IsEqualGUID(rclsid, &CLSID_StdComponentCategoriesMgr)) { return IClassFactory_QueryInterface((LPCLASSFACTORY)&COMCAT_ClassFactory, iid, ppv); } FIXME("\n\tCLSID:\t%s,\n\tIID:\t%s\n",debugstr_guid(rclsid),debugstr_guid(iid)); return CLASS_E_CLASSNOTAVAILABLE; } /*********************************************************************** * DllCanUnloadNow (COMCAT.@) */ HRESULT WINAPI COMCAT_DllCanUnloadNow() { return dll_ref != 0 ? S_FALSE : S_OK; } /*********************************************************************** * DllRegisterServer (COMCAT.@) */ HRESULT WINAPI COMCAT_DllRegisterServer() { TRACE("\n"); return regsvr_register(regsvr_data); } /*********************************************************************** * DllUnregisterServer (COMCAT.@) */ HRESULT WINAPI COMCAT_DllUnregisterServer() { TRACE("\n"); return regsvr_unregister(regsvr_data); }

1 0

COM and threads
by Fabian Cenedese 26 Nov '02

26 Nov '02

Hi There were some postings recently about CoInitialize and theads: http://www.winehq.com/hypermail/wine-devel/2002/11/0974.html "Sort of, the problem is that Wine doesn't support apartments yet, so it doesn't try to keep track of the threads that has called CoInitialize." I now have a problem that goes maybe in the same direction. I have an ocx which is again embedded in another ocx. In the wrapper are two threads (Msg and worker). I now get an error if the second thread tries to call a function from the embedded ocx. In the wine log I can find only one call to CoInitialize. This is right before the call of the second ocx: 0811c6d0:Call ole32.CoGetMalloc(00000001,4211275c) ret=65352782 0811c6d0:Ret ole32.CoGetMalloc() retval=00000000 ret=65352782 trace:ole:IMalloc_fnAlloc (292) trace:ole:IMallocSpy_fnPreAlloc (0x40a00944)->(292) trace:heap:RtlAllocateHeap (0x40380000,00000002,00000128): returning 403d5308 trace:ole:IMallocSpy_fnPostAlloc (0x40a00944)->(0x403d5308) trace:ole:IMalloc_fnAlloc --(0x403d5308) 0811c6d0:Call kernel32.InterlockedIncrement(403c9ad4) ret=65352c07 0811c6d0:Ret kernel32.InterlockedIncrement() retval=00000002 ret=65352c07 0811c6d0:Call ole32.CoCreateInstanceEx(65343308,00000000,00000000,00000000,00000000,00000000) ret=65352c8d 0811c6d0:Ret ole32.CoCreateInstanceEx() retval=80070057 ret=65352c8d 0811c6d0:Call ole32.CoSetState(653c3f80) ret=653527ec fixme:ole:CoSetState (0x653c3f80),stub! trace:ole:CoSetState -- release 0x653c3f80 now 0811c6d0:Call kernel32.InterlockedDecrement(403c9ad4) ret=65356c7e 0811c6d0:Ret kernel32.InterlockedDecrement() retval=00000001 ret=65356c7e some window, gdi32 and heap functions 08119650:Call gdi32.CreateRectRgnIndirect(406e26bc) ret=4083c19e trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d50c8 trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d5050 08119650:Ret gdi32.CreateRectRgnIndirect() retval=00001842 ret=4083c19e 08119650:Call gdi32.CombineRgn(0000184e,0000184e,00001842,00000001) ret=4083c1b3 trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d4ea0 trace:ole:IMalloc_fnFree (0x403d5308) trace:ole:IMallocSpy_fnPreFree (0x40a00944)->(0x403d5308 1) trace:heap:RtlFreeHeap (0x40380000,00000002,403d5308): returning TRUE trace:ole:IMallocSpy_fnPostFree (0x40a00944)->(1) 0811c6d0:Ret ole32.CoSetState() retval=00000000 ret=653527ec trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x65341543 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=00000010 The exception is right after CoSetState even if it says above that this is only a stub. It's that bad that I don't even have a call stack anymore. The function in the embedded ocx is never reached. But I can use the ocx in a simple VB proggy so I'd say registration is ok. I'm quite sure the problem lies in the two threads because it works better when I use only one thread in the wrapper ocx. Can somebody confirm this? Is there a workaround for this until wine supports COM with several threads? Thanks bye Fabi

2 1

RE: Wintab.dll technical issues.
by Patrik Stridvall 26 Nov '02

26 Nov '02

> Firstly a quick note: > I have opened a bug for implementation of wintab.dll (Bug No. 1160) > > Now the questions: > > 1: Writing stubs. > I'll be taking up Patrik Stridvall's offer to write stubs for > anyone new > to wine development. Yes, I'm working on it right now. Will probably not finish tonight though. > One question about stubs: > What's the wine policy on stub return values? No general policy. It depends. > Should a stub always return an error? Normally stubs should indicate error (return NULL, FALSE or similar) and do SetLastError(ERROR_NOT_IMPLEMENTED). > Should/Can it return success? In some cases indicating success (return TRUE or similar), even though it not strictly correct, might be a good idea. It depends. Lying to the application should be avoided of course but sometimes it is nessary. > 2: Testing wintab.dll in Win98. > wintab.dll is quite complex for what it does. I guess you mean wintab32.dll. wintab.dll is the 16 bit variant AFAICS. > Therefore the only practical way to implement it is > to work on the functions and communication models that are > used by the apps I want it to support. Probably. > To do this, I need some tool that can log the function calls and > parameters to the DLL, while wunning Win98.The logging must > be able to > let the > programmer choose elements from data stuctures in > parameters/retvals to log. > Any ideas???? There are no good tools to do this AFAIK. But if you find any I'm very intrested. > I've attempted to use apis32 and built a wintab.fnl file for > wintab.dll. > Unfortunately apis32 doen't allow the logging of the contents of data > structs. Yes. APIS32 is the best AFAIK and it sucks pretty bad IMHO. > I would also like to know experinces with Spy++. > Wintab can send it's own custom messages, so I'm wondering how good > Spy++ is at detecting custom messages? > > I've used it many times before, but only to examine standard windows > messages. No idea, haven't used it for years. > 3: Coding standards. > I haven't found any coding standards associated with wine. > This is particularly important, as I'll be writing new source files. > Can someone point me to the standards? We have none. Decide for yourself. However please do not choose anything to unlik anything else in Wine.

2 1

Doubleclick in systray (was Pegasus Mail 4.02)
by Duane Clark 26 Nov '02

26 Nov '02

Rick wrote: > The second issue, I've noticed that double-clicking the system tray > icon does not restore Pegasus Mail. I can minimize it so it appears > both on the taskbar and the system tray, but I can't restore the > application from the system tray icon (though I can from the > taskbar). > The problem here appears to be that under WinNT, when double clicking on the systray icon under WinNT, messages are sent for mouse down (message 201), mouse up (message 202), double click (message 203) (the message 200 is extraneous): <00171> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000201 <00172> 0007011E R message:0x19C9 [User-defined:WM_USER+5577] lResult:00000000 <00173> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000202 <00174> 0007011E R message:0x19C9 [User-defined:WM_USER+5577] lResult:00000000 <00175> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000200 <00176> 0007011E R message:0x19C9 [User-defined:WM_USER+5577] lResult:00000000 <00177> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000203 While under Wine, what is sent are two pairs of mouse down, mouse up messages: <00062> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000201 <00063> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000202 <00064> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000201 <00065> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000202 So while I am poking around trying to figure out where that translation should be occuring, if anyone has some hints on where to look, it would be most appreciated...

3 6

RE: Overlapped I/O without an hEvent
by Martin Wilck 26 Nov '02

26 Nov '02

Am Die, 2002-11-26 um 00.33 schrieb Ryan Reading: > I finally got it working, but not by ignoring the hEvent member in the > case that it is NULL. I tried that first (before I understood the > problem better), but it didn't work. The GetOverlappedResult() > implementation was not going to work with hEvent == NULL. Please try this patch, where GetOverlappedResult is modified, too: Index: files/file.c =================================================================== RCS file: /home/wine/wine/files/file.c,v retrieving revision 1.170 diff -u -r1.170 file.c --- files/file.c 21 Nov 2002 03:45:03 -0000 1.170 +++ files/file.c 26 Nov 2002 10:34:21 -0000 @@ -1593,32 +1593,40 @@ ERR("lpOverlapped was null\n"); return FALSE; } - if(!lpOverlapped->hEvent) + if( lpOverlapped->hEvent ) { - ERR("lpOverlapped->hEvent was null\n"); - return FALSE; + if ( bWait ) + { + do { + TRACE("waiting on %p\n",lpOverlapped); + r = WaitForSingleObjectEx(lpOverlapped->hEvent, INFINITE, TRUE); + TRACE("wait on %p returned %ld\n",lpOverlapped,r); + } while (r==STATUS_USER_APC); + } + else if ( lpOverlapped->Internal == STATUS_PENDING ) + { + /* Wait in order to give APCs a chance to run. */ + /* This is cheating, so we must set the event again in case of success - + it may be a non-manual reset event. */ + do { + TRACE("waiting on %p\n",lpOverlapped); + r = WaitForSingleObjectEx(lpOverlapped->hEvent, 0, TRUE); + TRACE("wait on %p returned %ld\n",lpOverlapped,r); + } while (r==STATUS_USER_APC); + if ( r == WAIT_OBJECT_0 ) + NtSetEvent ( lpOverlapped->hEvent, NULL ); + } } - - if ( bWait ) + else { - do { - TRACE("waiting on %p\n",lpOverlapped); - r = WaitForSingleObjectEx(lpOverlapped->hEvent, INFINITE, TRUE); - TRACE("wait on %p returned %ld\n",lpOverlapped,r); - } while (r==STATUS_USER_APC); - } - else if ( lpOverlapped->Internal == STATUS_PENDING ) - { - /* Wait in order to give APCs a chance to run. */ - /* This is cheating, so we must set the event again in case of success - - it may be a non-manual reset event. */ - do { - TRACE("waiting on %p\n",lpOverlapped); - r = WaitForSingleObjectEx(lpOverlapped->hEvent, 0, TRUE); - TRACE("wait on %p returned %ld\n",lpOverlapped,r); - } while (r==STATUS_USER_APC); - if ( r == WAIT_OBJECT_0 ) - NtSetEvent ( lpOverlapped->hEvent, NULL ); + /* hEvent == NULL: we cannot wait. + * FIXME: According to MSDN, NT, Win2k, and XP use the hFile handle for notification + * in this case. */ + if ( bWait ) + { + SetLastError ( ERROR_INVALID_HANDLE ); + return FALSE; + } } if(lpTransferred) @@ -1818,7 +1831,7 @@ if (flags & FD_FLAG_OVERLAPPED) { if (unix_handle == -1) return FALSE; - if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) + if ( (overlapped==NULL) || ( overlapped->hEvent && NtResetEvent( overlapped->hEvent, NULL ) ) ) { TRACE("Overlapped not specified or invalid event flag\n"); close(unix_handle); @@ -2042,7 +2055,7 @@ if (flags & FD_FLAG_OVERLAPPED) { if (unix_handle == -1) return FALSE; - if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) + if ( (overlapped==NULL) || ( overlapped->hEvent && NtResetEvent( overlapped->hEvent, NULL ) ) ) { TRACE("Overlapped not specified or invalid event flag\n"); close(unix_handle); Index: include/async.h =================================================================== RCS file: /home/wine/wine/include/async.h,v retrieving revision 1.5 diff -u -r1.5 async.h --- include/async.h 4 May 2002 18:37:08 -0000 1.5 +++ include/async.h 26 Nov 2002 10:53:28 -0000 @@ -73,7 +73,7 @@ ovp->next = ovp->prev = NULL; close( ovp->fd ); - if( ovp->event != INVALID_HANDLE_VALUE ) + if( ovp->event && ovp->event != INVALID_HANDLE_VALUE ) NtSetEvent( ovp->event, NULL ); if ( ovp->ops->call_completion ) -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: _stati64 (before _fstati64)
by Andreas Mohr 26 Nov '02

26 Nov '02

On Sun, Nov 24, 2002 at 09:35:53PM +0100, Stefan Leichter wrote: > Hello, > > by accident i have send this patch to wine-develop list instead of wine-patches. > This patch needs to be applied before my _fstati64 patch Err... and what had happened to *my* patch from Nov 09 ?? Duplicate work... urks ! :-\ -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview

1 0

Re: [bug 718] Executing dos DPMI programs
by Jukka Heinonen 26 Nov '02

26 Nov '02

> Does someone has success when executing DPMI programs ? > Every program I try to execute at this time fails, > going to the debugger, saying : > > Unhandled exception: privileged instruction in 32-bit code > (0x00000000). > In 32-bit mode. > 0x00000000: int $0x31 DPMI16 programs should work as should simple DPMI32 programs. However, most DPMI32 programs are not even supposed to work because there is no real implementation of 32-bit interrupt handling. It is on my TODO list but I'm currently working on moving interrupt handlers to winedos dll and I shall return to DPMI32 support after this. The problem is that Wine has no support for calling Wine functions from application context whose stack and code pointers use 32-bit segmented model. Wine interrupt emulation currently uses a simple scheme which works with any code pointer but which fails miserably if stack pointer is over 0xffff. The simplest fix would probably be to swap to 16-bit stack on entry to Wine interrupt handler. This would mean that only winedos dll needs to deal with 32-bit segmented stuff. I have a rather good idea on how this can be implemented. Anyway, your error message looks quite interesting because current Wine version emulates *all* interrupt opcodes in real mode, 16-bit protected mode and 32-bit protected mode and thus it should be impossible to get this error message. Are you sure you tried executing using the latest CVS version or at least the latest release? -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 3

Overlapped I/O without an hEvent
by Ryan Reading 26 Nov '02

26 Nov '02

Hi all, This is a follow-up to the message I wrote a message yesterday with the subject "Wine and IrDA via Virtual Com Port", although that wasn't a good subject for the problem. The software that I have is using Overlapped (asynchronous) I/O for communication of an IR port. The software makes WriteFile(), ReadFile(), and GetOverlappedResult() calls. However, before making any of the calls, the software does NOT initialize the hEvent member of the OVERLAPPED structure that is passed to the functions (it just zeroes the entire structure). Apparently the Win32 implementation of this is OK, but it is pretty obvious that the Wine implementation will not work with hEvent == 0. Now, I'm not saying that the Wine implementation is wrong, because based on the MSDN documentation, that value should be set to a valid event handle; however, the behavior is fundamentally different from the native Win32 environment, which in my case, leads to undesirable results. Is this something that I could feasibly fix in Wine, or would it be better to try to change the implementation of the software? Does anyone have any experience with this part of Wine? Thanks. -- Ryan 01010011 01100101 01110010 01100101 01101110 01100100 01101001 01110000 01101001 01110100 01111001 If only all life was just this simple. :)

4 5

Orlando, anyone?
by Fredrick P. Lackey 26 Nov '02

26 Nov '02

Hey, everyone! It's the annoying Microsoft guy again. ;-) Well, I've started to make the move. Now, 1/2 of my laptop is Red Hat. Whoo hoo! Man, I love Linux! =) I am having some problems, and was wondering if anyone in your list knew anyone in or near Orlando. heck, in Florida would be close enough. I'd like to see about hooking up on the phone or in person and trying to get the few issues I'm having worked out. I know that may seem a bit odd, but I'm really pumped to get M$ outta the picture. Thanx, Fred Lackey Orlando, Florida

2 1

Found Something Really Weird here!!
by Rômulo 26 Nov '02

26 Nov '02

I found something reeeally weird here, installing wine, on mandrake, gcc v3.2. ( [lamorack@WNET wine-20021031]$ gcc -v Reading specs from /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)) See this: (...) make[1]: Nada a ser feito para `all'. make[1]: Saindo do diretório `/home/lamorack/wine-20021031/miscemu' make[1]: Entrando no diretório `/home/lamorack/wine-20021031/programs' make[2]: Entrando no diretório `/home/lamorack/wine-20021031/programs/avitools' LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -o aviplay.exe.spec.c -exe aviplay.exe -mgui aviplay.o -L../../dlls -lddraw -lkernel32 could not open .so file for ddraw.dll make[2]: ** [aviplay.exe.spec.c] Erro 1 make[2]: Saindo do diretório `/home/lamorack/wine-20021031/programs/avitools' make[1]: ** [avitools] Erro 2 make[1]: Saindo do diretório `/home/lamorack/wine-20021031/programs' make: ** [programs] Erro 2 And that's it! I really hope u have an idea... 'cause i did not. Send me any E-mail answering, please

2 1

Re: Re: About picture format.
by yf 26 Nov '02

26 Nov '02

> On Mon, Nov 25, 2002 at 01:03:00PM +0800, yf wrote: > > > > It is a Windows application. > > you can download it on http://www.myhexin.com/tw2002/rjxz/download.asp?rjxz=exe1 > > Which program do you start? when running, it complains: fixme:ole:OLEPictureImpl_Load Unknown magic 0010 fixme:ole:OLEPictureImpl_Render type -1 not implemented fixme:ole:OLEPictureImpl_Destroy Unsupported type -1 - unable to delete fixme:ole:OLEPictureImpl_Load Could only read 136 of 1073465 bytes? > > I have a bit of a hard time following the menus, since they appear to be > in an asian language and the characters do not even display ;) I have sended the patch of how to make the Chinese character properly showed before. --- wine-20021031/graphics/x11drv/codepage.c.original 2002-11-16 13:50:31.000000000 +0800 +++ wine-20021031/graphics/x11drv/codepage.c 2002-11-04 17:44:14.000000000 +0800 @@ -279,8 +279,8 @@ { if ( IsLegalDBCSChar_cp936( *str_src, *(str_src+1) ) ) { - str2b_dst->byte1 = *str_src; - str2b_dst->byte2 = *(str_src+1); + str2b_dst->byte1 = *str_src&0x7f; + str2b_dst->byte2 = *(str_src+1)&0x7f; str_src++; } else > > Ciao, Marcus >

3 4

Re: Screwed up textures in OpenGL apps
by David D. Hagood 26 Nov '02

26 Nov '02

Lionel Ulmer wrote: > Out of curiosity after the DoubleBuffered thread.... Does this fix your > problem too ? > > No, I was running DesktopDoubleBuffered = Y already.

1 0

Winelib Apps v0.1
by Dimitrie O. Paun 26 Nov '02

26 Nov '02

Folks, Version 0.1 of the Winelib Applications page is available here: http://www.dssd.ca/wine/Winelib-Apps-0.1.html The current version is always available at this address http://www.dssd.ca/wine/Winelib-Apps.html Your comments, and suggestions are highly appreciated. -- Dimi.

1 1

An opengl regression
by Duane Clark 25 Nov '02

25 Nov '02

The patch for dynamic loading of opengl, http://www.winehq.com/hypermail/wine-cvs/2002/11/0151.html has caused a (apparently minor) regression in the program earthquake http://www.navagent.com/products/earthquake/ That is a small app (250K download) with a spinning globe that shows current earthquakes; actually a pretty cool little app. The regression is that now when the oceans are turned on (via the settings dialog), the land gets flooded.

3 5

Compiling Win32 targets on Linux
by mwood＠gosympatico.ca 25 Nov '02

25 Nov '02

I'm not sure if this is directly related to Wine, but I would like to build win32 exectuables on a Linux machine, with gcc if this is possible. I use Slackware 7.x and 8.x and was wondering what I would need to install to accomplishh this. Mikko Woodroffe

2 1

Wintab.dll technical issues.
by Robert North 25 Nov '02

25 Nov '02

Firstly a quick note: I have opened a bug for implementation of wintab.dll (Bug No. 1160) Now the questions: 1: Writing stubs. I'll be taking up Patrik Stridvall's offer to write stubs for anyone new to wine development. One question about stubs: What's the wine policy on stub return values? Should a stub always return an error? Should/Can it return success? 2: Testing wintab.dll in Win98. wintab.dll is quite complex for what it does. Therefore the only practical way to implement it is to work on the functions and communication models that are used by the apps I want it to support. To do this, I need some tool that can log the function calls and parameters to the DLL, while wunning Win98.The logging must be able to let the programmer choose elements from data stuctures in parameters/retvals to log. Any ideas???? I've attempted to use apis32 and built a wintab.fnl file for wintab.dll. Unfortunately apis32 doen't allow the logging of the contents of data structs. I would also like to know experinces with Spy++. Wintab can send it's own custom messages, so I'm wondering how good Spy++ is at detecting custom messages? I've used it many times before, but only to examine standard windows messages. 3: Coding standards. I haven't found any coding standards associated with wine. This is particularly important, as I'll be writing new source files. Can someone point me to the standards? Hope you guys have the answers -Rob.

5 5

[RFC] pthread emulation on FreeBSD (and Linux)
by Patrik Stridvall 25 Nov '02

25 Nov '02

With the attached patch FreeBSD compiles again even if OpenGL (which need pthreads) is used. Since it is only stubs at present OpenGL can't really work, but Wine and the normal test runs fine ("make test"). Anyway, to answer the first obvious question: Why didn't you just put it in scheduler/pthread.c? Well, the thing is it didn't work. It still generates the same link errors. However that is not very suprising since the pthread_ implementation is in ntdll.dll which is not linked with during the "-Bsymbolic -z defs" step. This begs the question: Does the Linux implementation of pthread really work anyway? The thing is Linux (or rather the GNU C library) always links in pthread suppport. However since some of the symbols are on purpose defined as weak they can be overriden. This is what scheduler/pthread.c does on Linux. Or rather tryies to do. I'm not really sure if works any longer. Note that if I apply the attach patch and compiles on Linux it seems to work with "make test" as well. Anyway be pthreads on Linux working properly as it may, the big question is how do we support pthreads on both Linux and FreeBSD. FreeBSD since it AFAICS have no default overridable implementation seems to require that we have some sort of wine_pthread library to implement pthreads from scratch like outlined in the attached patch. I'm not really very good on how runtime linking on Linux and FreeBSD. So, I would very much like comments from people more knowledgeable than I on that area. Comments? Suggestions? PS. Can somebody test if OpenGL:s pthread locking REALLY works properly on Linux?

3 2

Re: Screwed up textures in OpenGL apps
by David D. Hagood 25 Nov '02

25 Nov '02

Dan Kegel wrote: > Please verify that booting with just one CPU active > doesn't fix the problem. e.g. at lilo prompt, do something like > linux nosmp > It could be that Wine doesn't support SMP yet. > > - Dan > > First thing I tried, and with no change, so I don't think it's a SMP issue. Furthermore, my other apps under Wine work fine, only the OpenGL ones die.

2 2

Visual Basic runtimes?
by Mike Hearn 25 Nov '02

25 Nov '02

Hi, (btw, thanks to ove and alexandre for catching my patch booboo). Anyway, I'm trying to install Tipic IM (tipic.com), and once I figured out how to install .msi files in wine (hint: install ie6 then run msiexec /i foo.msi) I hit the lack of VB runtimes. It appears the MSI file assumes you already have msvbvm50 and msvbvm60 installed, but of course I don't. Tracking these down on the net wasn't too hard, but I'm wondering whether Wine could ship with them included or would it require a cleanroom implementation of these DLLs? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

1 0

RE: [RFC] pthread emulation on FreeBSD (and Linux)
by Patrik Stridvall 25 Nov '02

25 Nov '02

> On Sun, 24 Nov 2002, Patrik Stridvall wrote: > > > Anyway, to answer the first obvious question: > > Why didn't you just put it in scheduler/pthread.c? > > > > Well, the thing is it didn't work. It still generates the > > same link errors. However that is not very suprising since > > the pthread_ implementation is in ntdll.dll which is > > not linked with during the "-Bsymbolic -z defs" step. > > scheduler/pthread.c should be linked into libwine, which is > linked into > everything, at least this is the idea and was the case last time I > checked. It is not so in the current CVS of Wine: scheduler/pthread.c is linked with ntdll not with libwine. However libwine is not an appropriate place for the pthread implementation since the pthread implementation needs to call Windows API functions. libwine is a strictly Unix API library AFAICS. That why I made a new libwine_pthread library. > > This begs the question: > > Does the Linux implementation of pthread really work anyway? > > Works in WineX (though we needed some more hacks in it to > make it interact > well with the nvidia opengl drivers), and it'd surprise me if > it doesn't > still work in Wine, as the OpenGL deployed by most linux > distros wouldn't > work *at all* under Wine if it didn't, and people currently seem to be > working on Wine as if it did work. True. However, while I can't say I really understand how runtime linking work, I still feel that something is wrong. > > The thing is Linux (or rather the GNU C library) always links > > in pthread suppport. However since some of the symbols are > > on purpose defined as weak they can be overriden. This is > > what scheduler/pthread.c does on Linux. Or rather tryies to > > do. I'm not really sure if works any longer. > > It's not the weak symbols that allow overrides, weak symbols > only allow > the pthreads library to *not* be linked in (so your statement > about always > linking it in is untrue). Weak symbols work such that until > the library is > linked in, they are just null pointers, and glibc only calls > them if they > aren't null. Overriding symbols can only be done by linking > things in the > right order (link the wine overrides before the real pthread lib), and > since libwine is loaded before > opengl-linked-against-pthreads, the libwine > pthread implementation is used instead of the pthreads linked > in later, > and this don't need a special kind of symbol to work. OK. Thanks for the explaination. As I said not my area or expertise. > > Note that if I apply the attach patch and compiles on > > Linux it seems to work with "make test" as well. > > > > Anyway be pthreads on Linux working properly as it may, the big > > question is how do we support pthreads on both Linux and FreeBSD. > > I'd say link -lwine in before -lc_r, but then I don't know much about > FreeBSD. It is already done that what eventhough: 1. We current link with -lc not -lc_r, but maybe we should. 2. scheduler/pthread.c is as I said earlier in ntdll not libwine, so I can't see how linking can work and futhermore is doesn't for empirical evidence. > > FreeBSD since it AFAICS have no default overridable implementation > > seems to require that we have some sort of wine_pthread library to > > implement pthreads from scratch like outlined in the attached patch. > > The scheduler/pthread.c is basically the same thing, since it needs to > override every single pthread symbol used by apps, otherwise > the override > fails (or if it would be successful, it would still be incomplete). > > Stupid question: the reason for the missing symbols on FreeBSD isn't > because of the #ifdef __GLIBC__ in scheduler/pthread.c, is it? No, I would have to be VERY tired to make that mistake. :-) But since your premise scheduler/pthread.c in libwine is wrong that might be the answer. However it still doesn't explain why OpenGL seems to work on Linux. Perhaps it is because Linux have weak symbols or whatever concerning pthreads in libc and everything is OK because of this...

1 0

Off Topic: Off-list help needed with SGML Tools please
by Dustin Navea 25 Nov '02

25 Nov '02

For some reason I cant get SGMLTools to compile properly, everything but jade compiles but when it goes to compile that, I get a bunch of errors. I could leave out jade but thats what Im needing to compile to build sgml docs... I have tested this with Slackware 8.1 default GCC and the prepackaged GCC 3.2.1 Source from Slackware-current and neither would compile it. I also tested that its not just Slackware's GCC... Redhat 8.0 would not compile it either with GCC 3.2.1... So if anyone can help me it would be most appreciated.. I still have a couple of other things to try (installing the latest slackware binutils, and trying out CVS sgmltools, if i can ever connect to the cvs server) :/ -Dustin

1 0

Exe, Com and PATH
by Sylvain Petreolle 25 Nov '02

25 Nov '02

Wanting to run msdos debugger, I ran from c:\ : wine debug. the 2 debug that exists on my fake windows are c:\debug.com c:\windows\command\debug.exe My PATH variable is set as "Path" = "c:\\program\ files\\java\\j2re1.4.0_01\\bin;c:\\windows;c:\\windows\\command;c:\\windows\\system32;c:\\windows\\system;e:\\" Currently running wine debug from c:\ runs c:\windows\command\debug.exe,ignoring debug.com in the current directory. This is not the behaviour expected in real windows. These are 2 problems here : - Normally dos looks first in current directory => would load c:\debug.com. There is a problem with PATH here. - Putting 2 files with a .exe and .com with the same name in the same directory loads the .exe first, which shouldn't happen. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Fwd: Problem with network functions
by Sylvain Petreolle 24 Nov '02

24 Nov '02

Does someone has a clue for this / has same issues ? I cant figure how to find what is causing the network errors I have. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Bug #416: Missing Exports in Winsocks
by Andrew John Hughes 24 Nov '02

24 Nov '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch adds stubs for the functions listed in Bug #416, SetService{A,W} and GetTypeByName{A,W}. License: LGPL - - -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE94VftSE/kMce1ABARAipUAJ0ew9mD8eqn+2HrS1Yk72lvy+h4QACfaIeV uPloEX9A/xk4ptC6l0Xl5Z4= =K3YG - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE94VggSE/kMce1ABARAleXAJ40B6etNGsPhlZdm7GoqCrvYpGwpACgiU/o 2chi+d/NOUGg3WhHjj31UwQ= =Za8w -----END PGP SIGNATURE-----

1 0

Re: Some additions to D3D
by Alexandre Julliard 24 Nov '02

24 Nov '02

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > Note (for Alexandre): how would you prefer for us to track dependencies > between patches ? Submit each time a patch agains fresh CVS with all > previous patches sent (with an ever growing changelog) or do you prefer > (like here) a lot of patches dependant one on the others ? > If it's the latter, do we need to do 'letter tracking' as Dimi did ? In general separate patches are better; the exception is if they are fixes to a previous patch then it's better to resend all so I don't have to try to understand the broken version before reading the fix. And yes, in either case please find a way to clearly mark the sequence, don't rely on the submission order because mail doesn't always arrive in the correct order. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: _ fstati64
by Stefan Leichter 24 Nov '02

24 Nov '02

Am Sonntag 24 November 2002 11:11 schrieben Sie: > ChangeLog > ------------- > converted implementation of _fstat to _fstati64 > implemented _fstat by calling _fstati64 > Hello Alexandre, this patch is relative to my patch _stati64 please apply the _stati64 patch before this one. The _stati64 patch went to the worng list by accident. Thanks Stefan

1 0

Screwed up textures in OpenGL apps
by David D. Hagood 24 Nov '02

24 Nov '02

I'd asked this before, but received no response, so I'll ask it again. Does anybody have any suggestions on where to start debugging textures being wrong under OpenGL apps under Wine? Specifically, I am trying to get HalfLife-Blue Shift to run, but all the "static" textures (walls, floors, etc.) are screwed up. The "dynamic" textures on things like people are fine. Now, I USED to have Halflife running great, but then I upgraded my system to a SMP P3 system (I had been running a UMP P3) (the old system died.) All my native apps (Q3A, RTCW, gears, etc.) are just fine. Only Windows apps running under Wine are screwed up. Does anybody have a simple Windows OpenGL app I can use for testing? Or a direction to begin looking in? I do know this - forcing OpenGL to go to indirect rendering does NOT fix the textures - they are still just as screwed up, just a lot slower.

2 1

Re: [Fwd: [Bug 688] - make documentation produces only files as 'x6772.html']
by Tony Lambregts 24 Nov '02

24 Nov '02

Tony Lambregts wrote: > Vincent Béron wrote: > >> Hi guys, >> >> Alexandre just committed my patch concerning the documentation building >> process. Could you verify it works for you? >> >> >> > I am sure it is something on my end but I get the following when I > "make html", "make everything" > > docbook2html -d ./default.dsl -o wine-devel wine-devel.sgml > Using catalogs: /etc/sgml/sgml-docbook-3.1.cat > Using stylesheet: ./default.dsl > Working on: /usr/local/src/wine/documentation/wine-devel.sgml > jade:E: cannot find "./default.dsl"; tried "./default.dsl", > "/usr/share/sgml/./default.dsl" > jade:E: specification document does not have the DSSSL architecture as > a base architecture > ..... > spews out sgml > .... > > It must be something I've done but I have no idea what, since > db2html -d ./faq-plain.dsl wine-faq.sgml > jade:E: cannot find "./faq-plain.dsl"; tried "./faq-plain.dsl", > "/usr/share/sgml/./faq-plain.dsl" > jade:E: specification document does not have the DSSSL architecture as > a base architecture > > > same thing. WTF. > Ok heres what I have found. "db2html -d ../faq-plain.dsl wine-faq.sgml " works, However if I use "db2html -d ./faq-plain.dsl wine-faq.sgml " it blows chunks. as I reported. So the change to two dots works, which makes sense, therfore I changed the Makefile so that SRCDIR = .. and re-ran "make html" and produces the html beautifully. So all that tells me is "There is something wrong here" ./ should work (right?) -- Tony Lambregts

3 5

Re: dosconf move
by Alexandre Julliard 24 Nov '02

24 Nov '02

"György 'Nog' Jeney" <nog(a)sdf.lonestar.org> writes: > Is there any reason why this patch has not been applied? This is essentially > the same as my dosconf try 3 patch but for your convinience I made a new diff > against the current cvs. It's really ugly to export the DOSCONF structure as part of the DOS module interface. I think it's better to wait until that stuff can be moved without having to export it. -- Alexandre Julliard julliard(a)winehq.com

2 2

RE: wintab.dll: Copyright & trademark issues.
by Patrik Stridvall 23 Nov '02

23 Nov '02

> As I mentioned in an e-mail a couple of days back, > I'm about to start implemening a version of wintab.dll. > First I want to ask about legal issues: > > 1. trademark issues. > > wintab is a trademark. > Does this impact on the ability to implement wintab.dll No, I can't see how. Everything we will reasonable do with the name are either unrelated to trademarks or are used in reference to what is protected by the trademark. > 2. API header files. > Please look at the licence for the API files, avaialable at the > following URL: > http://www.pointing.com/Wintab/WTKIT126.ZIP > Does this allow our use of the headers, in Wine? > Does it allow the use of fragments of the headers in Wine? >From the headers: < The text and information contained in this file may be freely used, < copied, or distributed without compensation or licensing restrictions. So the headers are basicly public domain. Specifically it is compatible with the X11 license and the LGPL so no problem. We could include the files as they are without any modification at all as far as copyright is concerned. Presumably we might need some compiler related fixes though. > This is not too much of an issue, as I understand it's OK to re-write > compatible headers "In your own words". True. > 3. I am in the UK, how does this affect the copyright/trademark issues > above? It is not likely to matter very much almost regardless of there you are in the world, copyright and trademark laws are usually not that different. UK is pretty normal AFAIK. > Ok, some background about wintab: > wintab.dll is an "open industry standard" API > developed by a group of tablet manufacturers, and seems to > be currently maintained by the company LCS/Telegraphics. > Web page for wintab: http://www.pointing.com/WINTAB.HTM > LCS/Telegraphics home: http://www.pointing.com/LCS.HTM OK. Seem to contain documentation and other things nessary or useful for implementing. I can see two issues though. 1. It is not an offical Microsoft DLL so should it be part of Wine or not? IMHO yes, it seems to be widely used. However Alexandre decides. 2. How do you expect to implement this presumably very complicted DLL? Does Linux have some special libraries for supporting tablets?

2 1

gcc 2.95.3 breakage
by Johan Gill 23 Nov '02

23 Nov '02

It seems that latest CVS does not work well with gcc 2.95.3. collect2 segfaults when linking user, it seems. Gnarl -- /Johan Gill, johane(a)lysator.liu.se

1 1

[bug 718] Executing dos DPMI programs
by Sylvain Petreolle 23 Nov '02

23 Nov '02

Does someone has success when executing DPMI programs ? Every program I try to execute at this time fails, going to the debugger, saying : Unhandled exception: privileged instruction in 32-bit code (0x00000000). In 32-bit mode. 0x00000000: int $0x31 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: [wine-users] Can't get Unreal to work in opengl mode
by Sylvain Petreolle 23 Nov '02

23 Nov '02

Have exactly the same error when trying to run Max Pane. Tried with --debygmsg +seh, but didn't give any clue. Perhaps weshould file a bugreport on bugs.winehq.com or try wine-devel. Anyone who knows about seh at wine-devel, could you say what makes this happen ? > err:seh:EXC_DefaultHandling Exception frame is not in stack limits => > unable > to dispatch exception. > -------------------------------------------------------------------------- > > Here is how I got it: > > I started Wine from the command line; the resolution changed from > 1024x768 > to 64x480; then I got the Unreal menu; I then selected 'options' and > then > 'advanced options'; Unreal popped-up a window where I chose 'drivers' > then > 'opengl support'; after that I got back to the desktop ('err:seh...' > line). > > Hope it helps. > > N.B. I checked my config.log again; ./tools/wineinstall did > > $ ./configure -C --enable-opengl > > All the opengl items got a 'yes' answer, except this one: > > -------------------------------------------------------------------------- > configure:6918: checking for thread-safe OpenGL version > configure:6938: gcc -o conftest -g -O2 -I/usr/X11R6/include > conftest.c > -L/usr/X11R6/lib -lGL >&5 > /tmp/ccc9a5Qz.o: In function main': > /home/fab/test/wine/configure:6930: undefined reference to > pthread_getspecific' > collect2: ld returned 1 exit status > configure:6941: $? = 1 > configure: failed program was: > #line 6925 "configure" > #include "confdefs.h" > > int > main () > { > pthread_getspecific(); > ; > return 0; > } > configure:6959: result: no > -------------------------------------------------------------------------- > > See you. > > -- > Fabrice DELENTE > E-mail : fabrice.delente(a)free.fr > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-users ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Menu selection algorithm
by Jeff Smith 23 Nov '02

23 Nov '02

Dmitry, I still have win95-osr2 loaded on a machine. Let me know what I need to run the test on that box and I would glad to do so if this would help out. -- Jeff S >From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> >"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > > > So, what's the problem - you ask? While my view of what should happen is > > obviously consistant with that of Wine's - i.e. - the locale should > > select which menu to use, Windows displays the English locale ONLY. The > > only way I could make it display the Hebrew one was by changing the > > language on the English one to something else (French). > >I revived my old test for FindResource and now I see what are you talking >about. >LoadStringA/W and FindResourceA/W under Win2000 do search for language >resource >in the following order: >1. Neutral language with neutral sublanguage >2. LANG_ENGLISH, SUBLANG_DEFAULT >3. LANG_ENGLISH, SUBLANG_NEUTRAL >4. Current locale lang id >5. Current locale lang id with neutral sublanguage >6. Return first in the list > >But that means that the whole our internationalization will not work, if >we will go that way. But the question I have is: had I made an error when >I did the test under Win95OSR2 or MS has changed algorithm since then? > >-- >Dmitry. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

Menu selection algorithm
by Shachar Shemesh 23 Nov '02

23 Nov '02

Hi list, Sorry if this is slightly off topic. I am having some trouble with a sample program I keep changing to death. This program is written in VC on Windows 2000, and being run on Wine as well. I added a Hebrew menu over an already existing English(US) one. My regional settings say that my global settings are Hebrew, as are my local settings. The two menus both have the same ID, and only the language is different between them. When VC's resource editor displays the menus, it displays one with (English U.S) appended, and the Hebrew one without any extension (implying it thinks this is the default one). So, what's the problem - you ask? While my view of what should happen is obviously consistant with that of Wine's - i.e. - the locale should select which menu to use, Windows displays the English locale ONLY. The only way I could make it display the Hebrew one was by changing the language on the English one to something else (French). Wine behaves as expected. running: wine TestApp Yields an english menu, while LANG=he_IL wine TestApp yields a Hebrew one. I wouldn't worry so much, except that since we define a bug in Wine as any inconsistancy with Windows, this is a bug. I'm mostly trying to understand why Windows won't do what it's supposed to do, however. I'm using "RegisterClass" to register a class with the menu identifier passed using "MAKEINTRESOURCE", and then just calling "CreateWindow" to create the window. Anyone has any ideas or suggestions, or just an opinion whether that should worry us at all? Shachar

2 2

Re: [Bug 688] - make documentation produces only files as 'x6772.html'
by Sylvain Petreolle 23 Nov '02

23 Nov '02

I can answer that 'make html' works beautifully and perfectly. Good job ! > ------- Additional Comments From vberon(a)mecano.gme.usherb.ca > 2002-11-22 19:32 ------- > Sylvain, Tony, Dustin, could you confirm that it works correctly now? > Alexandre > just committed my patch. > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Page fault with isspace(*p)
by John K. Hohm 23 Nov '02

23 Nov '02

I am rewriting the regsvr stuff in dlls/comcat to make it practical to extend to ole32 and all the other COM DLLs. I have a nice simple function to skip whitespace and return the next character: static int getc_skipws(char const **p) { while (isspace(*p)) ++*p; return **p; } This gets called with **p == '['. I get a page fault in the implementation of isspace(), where the macro is testing 0x20 against the value for '[' in the __ctype_b array. What gives?

1 1

Re: [Fwd: [Bug 688] - make documentation produces only files as 'x6772.html']
by Dustin Navea 23 Nov '02

23 Nov '02

On Fri, 2002-11-22 at 19:37, Vincent Béron wrote: > Hi guys, > > Alexandre just committed my patch concerning the documentation building > process. Could you verify it works for you? > > Thank you, > Vincent > ---- > > From: wine-bugs(a)winehq.com > To: vberon(a)mecano.gme.usherb.ca > Subject: [Bug 688] - make documentation produces only files as 'x6772.html' > Date: 08 Nov 2002 20:23:34 -0600 > > http://bugs.winehq.com/show_bug.cgi?id=688 > > > > > > ------- Additional Comments From vberon(a)mecano.gme.usherb.ca 2002-11-08 20:23 ------- > Please advise on which of the 2 attachments is the best. > Personnaly, I'd rather go with the second, because with the first one it creates > a directory with images, but those are unused. > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > <http://bugs.winehq.com/show_bug.cgi?id=688>. > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND > INSERTED IN THE BUG DATABASE. Well, I am still working on updating my status, turns out that since I upgraded to Slackware 8.1 the default gcc wont build the jade package of sgmltools properly and so I need to upgrade to the latest slack-prepared build of gcc... Then I will try making it again... and see what happens..

1 0

Wine & Boehm garbage collector
by François-Denis Gonthier 23 Nov '02

23 Nov '02

Hello Wine-Devel I have not filled a bug with this a some of you may already know a solution to this problem. I've a contributor to the Mono project (http://www.go-mono.com) working on the System.Windows.Forms namespace. It has been decided to use Wine to implement this assembly since the S.W.F is rather tightly bound to the Win32 API. But we are facing a nasty problem. Current Mono implementation is using Hans Boehm conservative garbage collector and Wine cannot seems to work happily with that garbage collector. The temporary solution for development is to use Mono without garbage collection. This solution however, should not even be considered when Mono and it's System.Windows.Forms implementation will go mainstream. I've joined a small test case so one can try. Wine just crash at the first call to GC_malloc. Any help or advice is appreciated. François-Denis Gonthier

4 6

where is the code that converts VARIANTS?
by Medland, Bill 23 Nov '02

23 Nov '02

Can anyone tell me where the code is that converts a VARIANT from VT_DECIMAL to VT_BSTR? Bill

2 1

closing handle fails
by steve.lustbader＠philips.com 22 Nov '02

22 Nov '02

I open a handle to a com port with m_hPort = ::CreateFile(_T("COM1"),GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING,FILE_FLAG_OVERLAPPED, 0); Later, when I try to close the handle, the call to CloseHandle(m_hPort) gets stuck when CloseHandle calls NtClose. What trace can I provide here to help? -Steve

1 0

Re: wine/ windows/winproc.c windows/winpos.c windo ...
by Greg Turner 22 Nov '02

22 Nov '02

On Friday 22 November 2002 03:22 pm, Alexandre Julliard wrote: > ChangeSet ID: 6371 > 1.154 1.155 +76 -93 wine/controls/menu.c gcc 3.2 isn't happy with this: make[2]: Entering directory `/var/src/wine/dlls/user' gcc -c -I. -I. -I../../include -I../../include -march=athlon -O1 -pipe -mmmx -m3dnow -gstabs -g3 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_USER32_ -D_WINABLE_ -D_REENTRANT -o ../../controls/menu.o ../../controls/menu.c ../../controls/menu.c: In function `MENU_GetBitmapItemSize': ../../controls/menu.c:722: pointers are not permitted as case values ../../controls/menu.c:729: pointers are not permitted as case values ../../controls/menu.c:730: pointers are not permitted as case values ../../controls/menu.c:731: pointers are not permitted as case values ../../controls/menu.c:732: pointers are not permitted as case values ../../controls/menu.c:733: pointers are not permitted as case values ../../controls/menu.c:737: pointers are not permitted as case values ../../controls/menu.c:738: pointers are not permitted as case values ../../controls/menu.c:739: pointers are not permitted as case values ../../controls/menu.c:740: pointers are not permitted as case values ../../controls/menu.c:741: pointers are not permitted as case values ../../controls/menu.c: In function `MENU_DrawBitmapItem': ../../controls/menu.c:778: pointers are not permitted as case values ../../controls/menu.c:793: pointers are not permitted as case values ../../controls/menu.c:796: pointers are not permitted as case values ../../controls/menu.c:799: pointers are not permitted as case values ../../controls/menu.c:802: pointers are not permitted as case values ../../controls/menu.c:805: pointers are not permitted as case values ../../controls/menu.c:808: pointers are not permitted as case values ../../controls/menu.c:809: pointers are not permitted as case values ../../controls/menu.c:810: pointers are not permitted as case values ../../controls/menu.c:811: pointers are not permitted as case values ../../controls/menu.c:812: pointers are not permitted as case values make[2]: *** [../../controls/menu.o] Error 1 make[2]: Leaving directory `/var/src/wine/dlls/user' make[1]: *** [user] Error 2 make[1]: Leaving directory `/var/src/wine/dlls' make: *** [dlls] Error 2 These are DECLARE_HANDLE'ed values. This seems to fix it: Index: controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.155 diff -u -r1.155 menu.c --- controls/menu.c 22 Nov 2002 21:22:16 -0000 1.155 +++ controls/menu.c 22 Nov 2002 22:13:40 -0000 @@ -719,26 +719,26 @@ { switch(LOWORD(id)) { - case HBMMENU_SYSTEM: + case (WORD)HBMMENU_SYSTEM: if (data) { bmp = (HBITMAP)data; break; } /* fall through */ - case HBMMENU_MBAR_RESTORE: - case HBMMENU_MBAR_MINIMIZE: - case HBMMENU_MBAR_MINIMIZE_D: - case HBMMENU_MBAR_CLOSE: - case HBMMENU_MBAR_CLOSE_D: + case (WORD)HBMMENU_MBAR_RESTORE: + case (WORD)HBMMENU_MBAR_MINIMIZE: + case (WORD)HBMMENU_MBAR_MINIMIZE_D: + case (WORD)HBMMENU_MBAR_CLOSE: + case (WORD)HBMMENU_MBAR_CLOSE_D: size->cx = GetSystemMetrics( SM_CXSIZE ); size->cy = GetSystemMetrics( SM_CYSIZE ); return; - case HBMMENU_CALLBACK: - case HBMMENU_POPUP_CLOSE: - case HBMMENU_POPUP_RESTORE: - case HBMMENU_POPUP_MAXIMIZE: - case HBMMENU_POPUP_MINIMIZE: + case (WORD)HBMMENU_CALLBACK: + case (WORD)HBMMENU_POPUP_CLOSE: + case (WORD)HBMMENU_POPUP_RESTORE: + case (WORD)HBMMENU_POPUP_MAXIMIZE: + case (WORD)HBMMENU_POPUP_MINIMIZE: default: FIXME("Magic 0x%08x not implemented\n", id); return; @@ -775,7 +775,7 @@ switch(LOWORD(lpitem->text)) { - case HBMMENU_SYSTEM: + case (WORD)HBMMENU_SYSTEM: if (lpitem->dwItemData) { bmp = (HBITMAP)lpitem->dwItemData; @@ -790,26 +790,26 @@ bm.bmWidth -= bmp_xoffset; } goto got_bitmap; - case HBMMENU_MBAR_RESTORE: + case (WORD)HBMMENU_MBAR_RESTORE: flags = DFCS_CAPTIONRESTORE; break; - case HBMMENU_MBAR_MINIMIZE: + case (WORD)HBMMENU_MBAR_MINIMIZE: flags = DFCS_CAPTIONMIN; break; - case HBMMENU_MBAR_MINIMIZE_D: + case (WORD)HBMMENU_MBAR_MINIMIZE_D: flags = DFCS_CAPTIONMIN | DFCS_INACTIVE; break; - case HBMMENU_MBAR_CLOSE: + case (WORD)HBMMENU_MBAR_CLOSE: flags = DFCS_CAPTIONCLOSE; break; - case HBMMENU_MBAR_CLOSE_D: + case (WORD)HBMMENU_MBAR_CLOSE_D: flags = DFCS_CAPTIONCLOSE | DFCS_INACTIVE; break; - case HBMMENU_CALLBACK: - case HBMMENU_POPUP_CLOSE: - case HBMMENU_POPUP_RESTORE: - case HBMMENU_POPUP_MAXIMIZE: - case HBMMENU_POPUP_MINIMIZE: + case (WORD)HBMMENU_CALLBACK: + case (WORD)HBMMENU_POPUP_CLOSE: + case (WORD)HBMMENU_POPUP_RESTORE: + case (WORD)HBMMENU_POPUP_MAXIMIZE: + case (WORD)HBMMENU_POPUP_MINIMIZE: default: FIXME("Magic 0x%08x not implemented\n", LOWORD(lpitem->text)); return; -- gmt "War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself." -- John Stuart Mill

1 0

wintab.dll: Copyright & trademark issues.
by Robert North 22 Nov '02

22 Nov '02

As I mentioned in an e-mail a couple of days back, I'm about to start implemening a version of wintab.dll. First I want to ask about legal issues: 1. trademark issues. wintab is a trademark. Does this impact on the ability to implement wintab.dll 2. API header files. Please look at the licence for the API files, avaialable at the following URL: http://www.pointing.com/Wintab/WTKIT126.ZIP Does this allow our use of the headers, in Wine? Does it allow the use of fragments of the headers in Wine? This is not too much of an issue, as I understand it's OK to re-write compatible headers "In your own words". 3. I am in the UK, how does this affect the copyright/trademark issues above? Ok, some background about wintab: wintab.dll is an "open industry standard" API developed by a group of tablet manufacturers, and seems to be currently maintained by the company LCS/Telegraphics. Web page for wintab: http://www.pointing.com/WINTAB.HTM LCS/Telegraphics home: http://www.pointing.com/LCS.HTM I also found this organiation that LCS belongs to interesting: http://www.interop.org/ Many thanks -Rob.

1 0

Re: wine and asyncronous file i/o
by Martin Fuchs 22 Nov '02

22 Nov '02

Thanks, Martin! > EOF conditions are nasty. Seems we got it wrong... Please try the > following patch (it should solve your problem). However I guess it needs > regression testing because it changes overlapped ReadFile() semantics > drastically. If this condition turns out to be right, we may actually be > able to get rid of the special treatment of sockets in > FILE_AsyncReadService(). Yes, the file read routine seems to work now. However the application doesn't run completely yet. But that's another problem, I think... -- Martin Fuchs martin-fuchs(a)gmx.net

1 0

wm_mousehover bug fix.....
by Mike Hearn 22 Nov '02

22 Nov '02

Sorry to kind of spam, it was much easier to fix it than I thought it would be. Hacking wine isn't so hard after all...... input.c line 970 should be: PostMessageA(TrackingList[i].tme.hwndTrack, WM_MOUSEHOVER, get_key_state() , (pos.y << 8) + (pos.x)); I didn't think it was worth sending to wine-patches as it's just a 1 line fix and I didn't do it against wine cvs, but the last tarball release. That solves all my mouse handling issues with the ASV, so I'm a happy person once more. If somebody could apply that patch that'd be fab. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

4 3

RFC: console & curses
by Eric Pouech 22 Nov '02

22 Nov '02

I did send a couple of days ago a first patch about the (n)curses backend to wineconsole Alexandre commented a few implementation issues in it, which may change a bit what I started with and how the wineconsole should behave: console creation can be invoked from different contexts: 1/ the program calls AllocConsole 2/ the user starts wine thru wineconsole for his/her (favorite) CUI app (using from command line something like 'wineconsole foo') 3/ (N1) the program forks a child with CREATE_NEW_CONSOLE flags set in CreateProcess 4/ the program doesn't request anything on the other hand, wineconsole is now able to handle two types of backend for the user interface: A/ USER: the one already in place B/ Curses: the new one using (n)curses and a regular term for display (N2) C/ no wineconsole support => by default, the windows input & output streams are hooked to stdin and stdout, but we don't provide full console support - cursor motion, screen reading... now the final question, how to choose between A, B and C. the proposal is to fix the choice with: 1 => A 2 => B 3 => A 4 => C why such a directive proposal ? 4 => C is rather natural and doesn't need further explanation (one day, we could envisage to support it no longer, but that's another story) 1 => A greatly facilitates the console creation (ncurses requires both terminal control and moreover to keep the process group leader running as long as all the children - hooked to the same terminal - are running). Very few programs use AllocConsole (and even use it). The only issue may be with winedbg which may allocate its own console on startup (N3) 2 => B we could easily add 2 => A too (with some wineconsole parameters). Moreover, if the user wants to have the console in a specific xterm, it's doable with xterm -e 'wineconsole blablabla' 3 => A here again it's easier to deal with. if trying to run a curses backend, we should ensure that two different wineconsoles are not currently hooked to the same terminal If you have any comments, speak up now !! A+ N1: 3/ can be seen from various aspects as a specific case of 1/, but implementation could implement it as 2/) N2: one could try running wineconsole USER backend with ttydrv instead of x11drv, but that's out of the scope of this (maybe for Dimi's fun projects list N3: IMO what's missing is that winedbg should check if has inheried a real console. If so, it should detach from it and recreate a new one.

3 16

Re: Rosetta, wine, sound bug?
by Jeff Smith 22 Nov '02

22 Nov '02

>From: Sylvain Petreolle <spetreolle(a)yahoo.fr> > > > bash-2.05a$ wine -debugmsg +winmm,+wave,+dsound Rosetta.exe > > trace:winmm:WINMM_LibMain 0x41630000 0x1 (nil) > > trace:winmm:WINMM_CreateIData Created IData (0x403f0ef8) > > trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N); > > trace:winmm:MMDRV_Install Got 32 bit func 'auxMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'mixMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'midMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'modMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'widMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage' > > trace:winmm:MMDRV_GetDescription32 Can't find file wineoss.drv > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Shouldn't happen. > > trace:winmm:MMDRV_Install wineoss.drv => No description I get similar errors with MMDRV_GetDescription32. I assumed they were happening because the actual file wineoss.drv does not exist. Further, I assumed that MMDRV_GetDescription32 tries to get the description from locating the relevant record in the actual file. Please note that I have not had a chance to verify any of this. I have just recently taken an interest in wine's sound libraries, and would be glad to help out where I can. -- Jeff S _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Rosetta, wine, winex bug?
by ladies_man＠earthlink.net 22 Nov '02

22 Nov '02

I have a problem with wine, and everyone says that it is a bug, so I suppose that it would have some relevance here. Any help or solutions would be helpful. I have three programs, wine, winex, and Rosetta. When I combine winex with Rosetta sound works fine, but then the display is royally messed up. When I use wine with Rosetta, the sound fails but everything else works beautifully. Computer Information: Make: Dell Inspiron 3800 Laptop Processor: 700mhz Celeron Ram: 128mb Distribution: Gentoo Linux, stage 1, highly optimized and custom compiled. Video Card: ATI Rage Mobility Sound Card: ESS Maestro3 Devices: /dev/mixer /dev/dsp /dev/cdroms/cdrom0 Here is my Wine config file: [Drive C] "Path" = "${HOME}/.wine/fake_windows" "Type" = "hd" "Label" = "MS-DOS" "Filesystem" = "win95" ;;[Drive D] ;;"Path" = "/path/to/drive_d" ;;"Type" = "hd" ;;"Label" = "LABEL" ;;"Filesystem" = "win95" [Drive E] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Label" = "CD-Rom" "Filesystem" = "win95" "Device" = "/dev/cdroms/cdrom0" [Drive F] "Path" = "/tmp" "Type" = "hd" "Label" = "Tmp Drive" "Filesystem" = "win95" [Drive H] "Path" = "${HOME}" "Type" = "network" "Label" = "Home" "Filesystem" = "win95" [Drive Z] "Path" = "/" "Type" = "network" "Label" = "Root" "Filesystem" = "win95" [wine] "Windows" = "c:\\Windows" "System" = "c:\\Windows\\System" "Temp" = "f:\\" "Path" = "c:\\Windows;c:\\Windows\\System;f:\\;h:\\;z:\\" "Profile" = "c:\\Windows\\Profiles\\Administrator" "GraphicsDriver" = "x11drv" ; Wine doesn't pass directory symlinks to Windows programs by default. ; Enabling this may crash some programs that do recursive lookups of a whole ; subdir tree in case of a symlink pointing back to itself. ;"ShowDirSymlinks" = "1" "ShellLinker" = "wineshelllink" # <wineconf> [Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31)" }, ;"Windows" = "win98" ; DOS version to imitate ;"DOS" = "6.22" ; Be careful here, wrong DllOverrides settings have the potential ; to pretty much kill your setup. [DllOverrides] "rpcrt4" = "builtin, native" "oleaut32" = "builtin, native" "ole32" = "builtin, native" "commdlg" = "builtin, native" "comdlg32" = "builtin, native" "ver" = "builtin, native" "version" = "builtin, native" "shell" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "lzexpand" = "builtin, native" "lz32" = "builtin, native" "comctl32" = "builtin, native" "commctrl" = "builtin, native" "advapi32" = "builtin, native" "crtdll" = "builtin, native" "mpr" = "builtin, native" "winspool.drv" = "builtin, native" "ddraw" = "builtin, native" "dinput" = "builtin, native" "dsound" = "builtin, native" "opengl32" = "builtin, native" "msvcrt" = "native, builtin" "msvideo" = "builtin, native" "msvfw32" = "builtin, native" "mcicda.drv" = "builtin, native" "mciseq.drv" = "builtin, native" "mciwave.drv" = "builtin, native" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msacm.drv" = "builtin, native" "msacm" = "builtin, native" "msacm32" = "builtin, native" "midimap.drv" = "builtin, native" ; you can specify applications too "notepad.exe" = "native, builtin" ; default for all other dlls "*" = "native, builtin" [x11drv] ; Number of colors to allocate from the system palette "AllocSystemColors" = "100" ; Use a private color map "PrivateColorMap" = "N" ; Favor correctness over speed in some graphics operations "PerfectGraphics" = "N" ; Color depth to use on multi-depth screens ;;"ScreenDepth" = "16" ; Name of X11 display to use ;;"Display" = ":0.0" ; Allow the window manager to manage created windows "Managed" = "N" ; Use a desktop window of 640x480 for Wine "Desktop" = "640x480" ; Use XFree86 DGA extension if present ; (make sure /dev/mem is accessible by you !) "UseDGA" = "Y" ; Use XShm extension if present "UseXShm" = "Y" ; Use XVidMode extension if present "UseXVidMode" = "Y" ; Enable DirectX mouse grab "DXGrab" = "N" ; Create the desktop window with a double-buffered visual ; (useful to play OpenGL games) "DesktopDoubleBuffered" = "N" ; Code page used for captions in managed mode ; 0 means default ANSI code page (CP_ACP == 0) "TextCP" = "0" ; Use this if you have more than one port for video on your setup ; (Wine uses for now the first 'input image' it finds). ;; "XVideoPort" = "43" ; Run in synchronous mode (useful for debugging X11 problems) ;;"Synchronous" = "Y" [fonts] ;Read the Fonts topic in the Wine User Guide before adding aliases ;See a couple of examples for russian users below "Resolution" = "96" "Default" = "-adobe-helvetica-" "DefaultFixed" = "fixed" "DefaultSerif" = "-adobe-times-" "DefaultSansSerif" = "-adobe-helvetica-" ;; default TrueType fonts with russian koi8-r encoding ;"Default" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultFixed" = "-monotype-courier new-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultSerif" = "-monotype-times new roman-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultSansSerif" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" ;; default cyrillic bitmap X fonts ;"Default" = "-cronyx-helvetica-" ;"DefaultFixed" = "fixed" ;"DefaultSerif" = "-cronyx-times-" ;"DefaultSansSerif" = "-cronyx-helvetica-" ; the TrueType font dirs you want to make accessible to wine [FontDirs] ;"dir1" = "/usr/X11R6/lib/X11/fonts/TrueType" ;"dir2" = "/usr/share/fonts/truetype" ;"dir3" = "/usr/X11R6/lib/X11/fonts/TT" ;"dir4" = "/usr/share/fonts/TT" [serialports] "Com1" = "/dev/ttyS0" "Com2" = "/dev/ttyS1" "Com3" = "/dev/ttyS2" "Com4" = "/dev/modem" [parallelports] "Lpt1" = "/dev/lp0" [ppdev] ;; key: io-base of the emulated port ;; value : parport-device{,timeout} ;; timeout for auto closing an open device ( not yet implemented) ;"378" = "/dev/parport0" ;"278" = "/dev/parport1" ;"3bc" = "/dev/parport2" [spooler] "FILE:" = "tmp.ps" "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" [ports] ;"read" = "0x779,0x379,0x280-0x2a0" ;"write" = "0x779,0x379,0x280-0x2a0" [Debug] ;"RelayExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection" ;"RelayInclude" = "user32.CreateWindowA" ;"SnoopExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection" ;"SpyExclude" = "WM_SIZE;WM_TIMER;" [registry] ;These are all booleans. Y/y/T/t/1 are true, N/n/F/f/0 are false. ;Defaults are read all, write to Home ; Global registries (stored in /etc) "LoadGlobalRegistryFiles" = "Y" ; Home registries (stored in ~user/.wine/) "LoadHomeRegistryFiles" = "Y" ; Load Windows registries from the Windows directory "LoadWindowsRegistryFiles" = "Y" ; TRY to write all changes to home registries "WritetoHomeRegistryFiles" = "Y" ; Registry periodic save timeout in seconds ; "PeriodicSave" = "600" ; Save only modified keys "SaveOnlyUpdatedKeys" = "Y" [Tweak.Layout] ;; supported styles are 'Win31'(default), 'Win95', 'Win98' ;; this has *nothing* to do with the windows version Wine returns: ;; set the "Windows" value in the [Version] section if you want that. "WineLook" = "Win95" [Console] ;"Drivers" = "tty" ;"XtermProg" = "nxterm" ;"InitialRows" = "25" ;"InitialColumns" = "80" ;"TerminalType" = "nxterm" [Clipboard] "ClearAllSelections" = "0" "PersistentSelection" = "1" ; List of all directories directly contain .AFM files [afmdirs] "1" = "/usr/share/ghostscript/fonts" "2" = "/usr/share/a2ps/afm" "3" = "/usr/share/enscript" "4" = "/usr/X11R6/lib/X11/fonts/Type1" [WinMM] "Drivers" = "wineoss.drv" #"Drivers" = "winearts.drv" "WaveMapper" = "msacm.drv" "MidiMapper" = "midimap.drv" [dsound] ;; HEL only: Number of waveOut fragments ahead to mix in new buffers. ;"HELmargin" = "5" ;; HEL only: Number of waveOut fragments ahead to queue to driver. ;"HELqueue" = "5" ;; Max number of fragments to prebuffer ;"SndQueueMax" = "28" ;; Min number of fragments to prebuffer ;"SndQueueMin" = "12" ;; Kazaa Lite [AppDefaults\\Kazaa.exe\\DllOverrides] "shdocvw" = "native" "shlwapi" = "native" "urlmon" = "native" # </wineconf> Here is the output from the wine command: bash-2.05a$ wine -debugmsg +warn,+winmm,+winoss,+err,+fixme .wine/fake_windows/Program\ Files/The\ Rosetta\ Stone/The\ Rosetta\ Stone/Rosetta.exe trace:winmm:WINMM_LibMain 0x41630000 0x1 (nil) trace:winmm:WINMM_CreateIData Created IData (0x403f10a8) trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N); trace:winmm:MMDRV_Install Got 32 bit func 'auxMessage' trace:winmm:MMDRV_Install Got 32 bit func 'mixMessage' trace:winmm:MMDRV_Install Got 32 bit func 'midMessage' trace:winmm:MMDRV_Install Got 32 bit func 'modMessage' trace:winmm:MMDRV_Install Got 32 bit func 'widMessage' trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage' trace:winmm:MMDRV_GetDescription32 Can't find file wineoss.drv trace:winmm:MMDRV_Install wineoss.drv => No description trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 6 dev for (wineoss.drv:Aux) trace:winmm:MMDRV_InitPerType Setting min=0 max=6 (ttop=6) for (wineoss.drv:Aux)trace:winmm:MMDRV_InitPerType Aux:Trans[0] -> w ineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[1] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[2] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[3] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[4] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[5] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wineoss.drv:Mixer) trace:winmm:MMDRV_InitPerType Setting min=0 max=1 (ttop=1) for (wineoss.drv:Mixer) trace:winmm:MMDRV_InitPerType Mixer:Trans[0] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 0 dev for (wineoss.drv:MidiIn) trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 0 dev for (wineoss.drv:MidiOut) trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wineoss.drv:WaveIn) trace:winmm:MMDRV_InitPerType Setting min=0 max=1 (ttop=1) for (wineoss.drv:WaveIn) trace:winmm:MMDRV_InitPerType WaveIn:Trans[0] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wineoss.drv:WaveOut) trace:winmm:MMDRV_InitPerType Setting min=0 max=1 (ttop=1) for (wineoss.drv:WaveOut) trace:winmm:MMDRV_InitPerType WaveOut:Trans[0] -> wineoss.drv trace:winmm:MMDRV_Install ('wavemapper', 'msacm.drv', mapper=Y); trace:winmm:MMDRV_Install Got 32 bit func 'widMessage' trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage' trace:winmm:MMDRV_GetDescription32 Can't find file msacm.drv trace:winmm:MMDRV_Install msacm.drv => No description trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wavemapper:WaveIn) trace:winmm:MMDRV_InitPerType Setting min=0 max=0 (ttop=1) for (wavemapper:WaveIn) trace:winmm:MMDRV_InitPerType WaveIn:Trans[-1] -> wavemapper trace:winmm:MMDRV_InitPerType WaveIn:Trans[0] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wavemapper:WaveOut) trace:winmm:MMDRV_InitPerType Setting min=0 max=0 (ttop=1) for (wavemapper:WaveOut) trace:winmm:MMDRV_InitPerType WaveOut:Trans[-1] -> wavemapper trace:winmm:MMDRV_InitPerType WaveOut:Trans[0] -> wineoss.drv trace:winmm:MMDRV_Install ('midimapper', 'midimap.drv', mapper=Y); trace:winmm:MMDRV_Install Got 32 bit func 'modMessage' trace:winmm:MMDRV_GetDescription32 Can't find file midimap.drv trace:winmm:MMDRV_Install midimap.drv => No description trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (midimapper:MidiOut) trace:winmm:MMDRV_InitPerType Setting min=0 max=0 (ttop=0) for (midimapper:MidiOut) trace:winmm:MMDRV_InitPerType MidiOut:Trans[-1] -> midimapper trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:waveOutGetDevCapsA (0 0x406b22c4 52)! trace:winmm:MMDRV_Message (WaveOut 0 4 0x00000000 0x406b22c4 0x00000034 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=4 usr=0x00000000 p1=0x406b22c4 p2=0x00000034 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutMessage ((nil), 2058, 1080763140, 0) trace:winmm:MMDRV_PhysicalFeatures (0x403f2594, 080a, 406b2304, 00000000) trace:winmm:MMDRV_Message (WaveOut 0 2058 0x00000000 0x406b2304 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=2058 usr=0x00000000 p1=0x406b2304 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open (0x4043334c, 0, Out, 0x40433338, 43630D38, 404330B0, 00030080, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=22050, nAvgBytesPerSec=44100, nBlockAlign=2, wBitsPerSample=8, cbSize=0 trace:winmm:WAVE_Open cb=43630d38 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b21a0 0x406b2220 0x00030080 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b21a0 p1=0x406b2220 p2=0x00030080 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutSetVolume (0000, ffffffff); trace:winmm:MMDRV_Message (WaveOut 0 17 0x00000000 0xffffffff 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=17 usr=0x00000000 p1=0xffffffff p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b21c8 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b21c8 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutGetDevCapsA (4294967294 0x406b1f2c 52)! trace:winmm:waveOutGetDevCapsA (0 0x406b2068 52)! trace:winmm:MMDRV_Message (WaveOut 0 4 0x00000000 0x406b2068 0x00000034 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=4 usr=0x00000000 p1=0x406b2068 p2=0x00000034 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open ((nil), 0, Out, 0x40430808, 00000000, 00000000, 00000001, 32); trace:winmm:WAVE_Open WAVE_FORMAT_QUERY requested ! trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b1fb4 0x406b2034 0x00000001 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b1fb4 p1=0x406b2034 p2=0x00000001 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=(nil) trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b1fac 0x406b202c 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b1fac p1=0x406b202c p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutGetVolume (8000, 404307f8); trace:winmm:MMDRV_Message (WaveOut 0 16 0x406b1fd4 0x404307f8 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=16 usr=0x406b1fd4 p1=0x404307f8 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b1fd4 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b1fd4 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b2210 0x406b2290 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b2210 p1=0x406b2290 p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutGetVolume (8000, 406b233c); trace:winmm:MMDRV_Message (WaveOut 0 16 0x406b2238 0x406b233c 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=16 usr=0x406b2238 p1=0x406b233c p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b2238 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b2238 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b1ec0 0x406b1f40 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b1ec0 p1=0x406b1f40 p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutPrepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:waveOutWrite (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutReset (0x8000); trace:winmm:MMDRV_Message (WaveOut 0 12 0x406b1ee8 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=12 usr=0x406b1ee8 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b1ee8 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b1ee8 p1=0x00000000 p2=0x00000000 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b22b8 0x406b2338 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b22b8 p1=0x406b2338 p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutPrepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:waveOutWrite (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutReset (0x8000); trace:winmm:MMDRV_Message (WaveOut 0 12 0x406b22e0 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=12 usr=0x406b22e0 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b22e0 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b22e0 p1=0x00000000 p2=0x00000000 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:waveOutSetVolume (0000, ffffffff); trace:winmm:MMDRV_Message (WaveOut 0 17 0x00000000 0xffffffff 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=17 usr=0x00000000 p1=0xffffffff p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutSetVolume (0000, ffffffff); trace:winmm:MMDRV_Message (WaveOut 0 17 0x00000000 0xffffffff 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=17 usr=0x00000000 p1=0xffffffff p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x0 0x1 bash-2.05a$ Now I have no clue what the problem is, many people have been working on this and none of them can figure it out. Both winex 20020807 and the 2.2.1 version have used the oss.drv's and they work. If anyone can help solve this problem I would greatly appreciate it, and if it is a bug, I hope you can fix it quickly. -- ---------------------------------- E-Mail: ladies_man(a)earthlink.net Date: 20-Nov-2002 Time: 15:54:44 This message was sent by XFMail ---------------------------------- -- ---------------------------------- E-Mail: ladies_man(a)earthlink.net Date: 20-Nov-2002 Time: 15:59:39 This message was sent by XFMail ----------------------------------

4 7

winspool.drv again
by Dimitrie O. Paun 22 Nov '02

22 Nov '02

Alexandre, The winspool.drv issue is a lot more serious than the in-tree execution. This one screws things up badly for the PuTTY build system. Should we modify winebuild to try to link with winspool.drv, and if that fails with winspool.dll when -lwinspool is given? (or the other way around, I don't know) I'd really appreciate help on this one, so I can send the patch out. -- Dimi.

4 4

Wine and IrDA via Virtual Com Port
by Ryan Reading 22 Nov '02

22 Nov '02

Hi all, This is my first time on this list. I've been playing around with Wine with quite a bit of success, but I've ran into a problem when trying to get an old program that uses IR to work correctly. I've already post on comp.emulators.ms-windows.wine and they referred my problem here. Here is the info that I have... For the record, I am running Wine 20021031. The program is based on the commercial Greenleaf Comm++ libraries. It is designed to be utilized in Windows on top of a *virtual* Com port running IrDA. The software itself knows nothing of IrDA, it's the *virtual* Com port's responsibility to provide that. Apparently it uses IrCOMM and TinyTP, but I'm just learning exactly what that means. I setup Linux to run IrDA through /dev/ttyS0 (the physical IR serial device) on /dev/ircomm0 (the IrDA device). I set "Com4" = "/dev/ircomm0". in the wine config file. I run the software with "--debugmsg +comm,+file" and look at the output. The software gets to a point where it performs some basic Serial port setup (SetupComm(), GetCommState(), SetCommState(), etc) and then I get the following... <snip> trace:file:Writefile 192 0x420b1190 14 0x4230a200 0x430a1530 trace:file:Writefile Overlapped not specified or invalid event flag <-- this is the interesting line trace:ClearCommError handle 0xc0 cbInQue = 0 cbOutQue = 0 ... last line repeated until timeout </snip> ( big apologies for not having a larger dump ) The pointer to the OVERLAPPED structure in this function is not set to NULL, but the hEvent member of that struct is set to ZERO (0), which seems to be the problem. I don't know why that member variable is set to ZERO (0), but that obviously keeps me from actually writing anything to the IR port. So my question involves how to approach this problem. I actually modified the Wine code to "overlook" the bad hEvent variable in WriteFile(), ReadFile(), and GetOverlappedResult() just for kicks to see what would happen. When I do that, it actually sends stuff over the IR connection and processes more ( additional ReadFile[Ex](), WriteFile[Ex](), GetOverlappedResult() calls ), but obviously the handshaking doesn't complete correctly since I'm ignoring the error checking. Could my problem be in the way IrDA is setup ( i.e. what is the correct way to emulate a Windows *virtual* COM port running IrDA in Wine )?? Any advice or information on this problem would be really appreciated. Thanks. -- Ryan

2 1

Debugging mouse messages
by Mike Hearn 22 Nov '02

22 Nov '02

Hi, After setting up my dual crossover/winehq (last tarball release) installation, I tried doing some traces on IE with the adobe svg plugin. I can't figure out why I am getting this: trace:msg:MSG_peek_message got type 5 msg 113 hwnd 0 wp 8 lp 41380d58 trace:cursor:X11DRV_GetCursorPos pointer at (661,442) trace:msg:MSG_peek_message got type 5 msg 2a1 hwnd 10042 wp 0 lp 0 trace:msg:GetKeyState key (0x12) -> 0 trace:msg:WINPROC_CallProc32ATo32W func 0x413e9024 (hwnd=00010039,msg=WM_USER+000b,wp=00000000,lp=00000000) over and over again when the mouse is not moving. It appears that IE (the constant polling for the cursor position occurs when showing a 404 screen too) has different mouse behaviour to other apps, for instance in WebFerret the X11DRIV_GetCursorPos function is only called when the mouse actually moves. In IE, it's called seemingly on a timer (i'd guess every .25 or .5 seconds) even when the cursor is over a toolbar (though not the address bar oddly). I'm also confused by the reference to WINPROC_CallProc32ATo32W, is this normal? Google says it's used as part of 32bit<->16bit thunking, but there is no 16bit code here as far as I'm aware. Any ideas? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

2 3

Re: Screenshots
by Brian Vincent 22 Nov '02

22 Nov '02

I've been meaning to put something together for a few days here.. > shots to Brian isn't the best way to go about it as nobody knows who has > sent what. Have you actually got any yet Brian? First, take a look at: http://www.theshell.com/~vinn/ss Quite a few folks have sent stuff in. Now, after looking at so many screenshots and trying to evaluate them for content I've realized a few things.. 1) We're absolutely going to have to insist on 800x600 resolution. Thanks for all the ones so far, but really the only usable ones are the 800x600. (There are exceptions, such as Mike's Quicktime one that can be resized nicely.) 2) Screenshots of an application doing something are the way to go. For instance, the one Mike just sent me showing Adobe's SVG plug-in in IE is WAY cool. Unfortunately it's not usable because of the resolution. Even a pull-down menu being pulled down is enough. 3) Cluttered desktops suck. You don't need to have 3 terminal windows, Mozilla, and everything else in the background. For the most part I think the screenshots have followed that rule closely. Okay, here's the deal.. Thomas Wickline volunteered to do screenshots of these apps: Office 2000 and everything in it lotus notes Quicken Quick Books visio Carlos Lozano did shots for the "gold" list apps. I'm going to ask him for some more here in the future.. (unbeknowst to him) The following would be nice to see: any game the exact same screenshot Mike Hearn sent of IE/SVG except at 800x600 Adobe Photoshop Anything else is fair game. I'll put screenshots on that URL above, so check there before doing any. -brian

6 5

Interesting control samples
by Mehmet YASAR 22 Nov '02

22 Nov '02

Hi, I just found http://www.codejock.com/, they seems to provide a Toolkit to enhance any app (giving Microsoft's new UI look), the most interesting for Wine is that you can download 40 basic samples of different controls. Few notes : - A quick test shows that Wine can't launch any exe. - No source code is included I thought it may be a good test case ... Here is the list of samples included in XTSetupSamples_1931.exe : AccelDemo.exe BrowseDialog.exe BrowseEdit.exe Button.exe CaptionBar.exe CheckListBox.exe ColorPicker.exe CommonControls.exe CoolMenu.exe DockingDemo.exe EditListBox.exe FlatCombo.exe FlatHeader.exe FlatTabCtrl.exe FlatTabView.exe GUI_Explorer.exe GUI_Outlook.exe GUI_VisualStudio.exe GUI_WinZip.exe HexEdit.exe HyperLink.exe ListCtrl.exe MaskEdit.exe MDITabWindows.exe MultiFrameDocking.exe OutlookBar.exe Pager.exe PrintPreview.exe SearchOptions.exe SplitterWindow.exe StatusBar.exe TabbedView.exe TabCtrlBar.exe TabCtrl.exe TipOfTheDay.exe TipWindow.exe TrayIconDemo.exe TrayIconDlg.exe TreeCtrl.exe WindowPos.exe Mehmet

1 0

winewrapper
by Dimitrie O. Paun 22 Nov '02

22 Nov '02

Folks, Another problem developing Winelibs app while using your Wine tree. Say you have the following: -- a Winelib app you're working on -- a Wine tree you're working on -- you compile wine out-of-tree Now, say you build your myapp.exe.so OK, and you now want to create a symlink myapp -> winewrapper so you can start your Winelib app. Problem is that winewrapper resides in the source tree, and there is no way for it to figure out where the build tree is, and it needs that. Possible solution: -- have winewrapper somehow in the Wine build tree. One way to do that is to rename winewrapper to winewrapper.in, and generate winewrapper at build time -- link to the winewrapper in the build tree -- modify winewrapper slightly so that it looks where is resides, and if it's in the wine tree, is should try to use that to run the app. Alexandre, what do you say? -- Dimi.

4 13

Re: wine/tools wineinstall
by Dustin Navea 22 Nov '02

22 Nov '02

On Thu, 2002-11-21 at 17:46, Alexandre Julliard wrote: > ChangeSet ID: 6362 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/11/21 17:46:06 > > Modified files: > tools : wineinstall > > Log message: > Matthew Davison <m.davison(a)virgin.net> > Remove obsolete --enable-opengl. > > Patch: http://cvs.winehq.com/patch.py?id=6362 > > Old revision New revision Changes Path > 1.47 1.48 +1 -1 wine/tools/wineinstall > > > I'm not totally sure that this should be done as my wine install comes with opengl disabled due to relying on libpthread for thread safety. If we remove the --enable-opengl from wineinstall FLC's will not know how to enable it... -Dustin

2 1

__int64
by Dimitrie O. Paun 22 Nov '02

22 Nov '02

Hmm, Another header problem. When compiling Putty with Wine's headers, I get this errors: In file included from /home/dimi/dev/wine/wine.src/include/msvcrt/wchar.h:12, from wcwidth.c:9: /home/dimi/dev/wine/wine.src/include/msvcrt/io.h:42: parse error before "__int64" /home/dimi/dev/wine/wine.src/include/msvcrt/io.h:42: warning: no semicolon at end of struct or union /home/dimi/dev/wine/wine.src/include/msvcrt/io.h:44: parse error before '}' token /home/dimi/dev/wine/wine.src/include/msvcrt/io.h:60: parse error before "__int64" ... Reason is that __int64 is not defined. Now, this happens when I compile a file that has only one include: #include <wchar.h> As a quick hack, I've added this: typedef long long __int64; to include/msvcrt/sys/types.h, but it doesn't look like the right fix. We define __int64 in here: include/basetsd.h:#define __int64 long long but why a define and not a typedef? Should we include this file from one of the msvcrt header files? I really don't like doing that, but than again, I don't know much about the organization of our headers, or most importantly, the way MS does it... -- Dimi.

4 7

PuTTY update
by Dimitrie O. Paun 21 Nov '02

21 Nov '02

Folks, Here's a quick status update on PuTTY as a Winelib app: 1. It compiles, links, and runs perfectly (Yay!) 2. I've talked to the PuTTY folks, and they agreed to add Winelib as one of their targets in their build process (provided I do the patch :)) 3. I've modified they Makefile-generation Perl scrip to do just that. What is missing: 1. The winspool issue I've sent earlier is bugging me. They link against -lwinspool, we require -lwinspool.drv This is very awkward to implement, and my patch would become a lot more intrusive (and maybe unacceptable). We need to fix this on our end, so we're compatible. 2. The winewrapper thing I've just sent out. I can't send them a bunch (they generate like 7 apps) of silly wrapper scrips, that'd be ridiculous. Help in resolving these issues would be greatly appreciated. I'd like to send them the patch sooner rather than later, so that (1) they don't change their mind, and (2) I don't forget what I was doing! :) -- Dimi.

2 2

Seperating winelibs from main wine ( was "Winelib support" )
by Mark Hannessen 21 Nov '02

21 Nov '02

Mmmm.. Doesn't sound like a basic windows app. I do not know any windows program that uses putty and there are plenty linux/unix alternatives. but it might be usefull to some people. ( i don't know anyone ) perhaps it is time to seperate all the winelib progs from the main wine package and create a winelib package. just how knows what people in the future might write. paint / control panel / media player / calculator / etc... comments please Mark Hannessen On Thursday 21 November 2002 10:50, wine-devel-request(a)winehq.com wrote: > Hi folks, > > I'm one of the Wine (http://www.winehq.org) developers, > and I just managed to build Putty under Winelib. That > is, Putty now runs as a native Linux application. > > The interesting part is that I've managed to do so with > virtually no changes to the source code, just a few > changes to the makefile.cyg file. > > Now, my question to you: are you interested in supporting > Putty under Wine, as a Winelib app? If so, I can clean up > my changes, and send you a patch for the build system to > incorporate in your tree.

7 13

[Fwd: Re: Wine developers want Pegasus Mail as a 'Gold' app]
by Rick Romero 21 Nov '02

21 Nov '02

I contacted David Harris, author of Pegasus Mail, and here's what he had to say. I am totally lost when it comes to the windowing stuff, I'm not sure what's X and what's Windows. Hopefully that can help a little.. I know the patches thread was really self-explanatory, but was centered on the app being iconified. I don't know that this is really any different, but it just seems more of a 'hiding the taskbar' and not iconifying the app. Or am I just stubborn/thick-headed? (well, I am :) The "Setup Wizard" was something I thought would be good to have, but at this point, I think David would have to remove the actual file open code from Pegasus for it to work. HTH. Rick -----Forwarded Message----- From: David Harris <David.Harris(a)pmail.gen.nz> To: Rick Romero <rick(a)valeoinc.com> Subject: Re: Wine developers want Pegasus Mail as a 'Gold' app Date: 22 Nov 2002 10:52:12 +1300 On 21 Nov 2002 at 11:59, Rick Romero wrote: > I apologize for the direct email, I had hoped that a Win-PM list posting > would be sufficient, but it unfortunately hasn't been. Alas, I don't read any of the public lists any more - with more than 300 messages a day to deal with just on the local accounts, I simply don't have time. > But let me get right down the the issues. I was hoping you could give > me some insight into the workings of Pegasus Mail so that the Wine guys > could easily implement any Windows API's that you might be using, that > are missing from Wine. Please consider my mailbox open at any time of the day for this - both yourself and any Wine developer who would like to contact me directly. Given that I simply don't have the resources to produce my own Linux version of Pegasus Mail at this stage, Wine assumes considerable importance for me, so any collaboration offers clear mutual benefits. > The first, critical issue, has to do with hiding the taskbar entry. > The option: "Hide the Pegasus Mail taskbar entry when minimized" which > is on by default, causes Wine to not refresh the window after > minimizing, or changing virtual desktops. A one-line fix for Wine DOES > exist, (Essentially, the flag WS_VISIBLE is not checked within Wine) but > I was hoping you could give us a little more info on what flag you may > set on that checkbox, or if it's just a flag at all, or a quick couple > lines of code.. It's not as clean or tidy as a couple of lines of code - there are some messages involved, but overall it's pretty simple. When Pegasus Mail gets a WM_SIZE message with wParam set to SIZE_MINIMIZED, it simply calls ShowWindow (hWndFrame, SW_HIDE); where "hWndFrame" is the main WinPMail frame window. There's a little other cruft in there as well, but nothing that would affect this. Under Windows, the effect of this is to remove the application from the taskbar. That's really all there is to it. The preferences checkbox merely sets a preference field which is queried later when the application is actually minimized - it has no other immediate function when it is checked. > The second issue is just for user convienance. We've found that Pmail > checks for a physical winsock.dll (wsock32.dll for Wine), and if that > exists, it enables TCP/IP. What still doesn't occur though, is the > Internet Setup Wizard. A fresh install, with wsock32.dll existing, (We > assume) should start the Wizard upon startup. That doesn't happen, > Pegasus works just fine, but doesn't start the wizard for the new user. > Are there any other checks you make to start that wizard up? Looking through the code, it appears to me that the following conditions need to be true before the Internet Setup Wizard will run: 1: It must be the first time the program has ever run for this user (i.e, there needs to have been no PMAIL.INI file present in the mailbox when the program started). 2: The commandline -Z (flags) switch must not have bit 0 set (i.e, it cannot have "1" as one of its bit members) - this disables TCP/IP altogether. 3: The User's POP3 server, POP3 username and POP3 password must all be zero-length (i.e, not yet defined) internally. 4: The bit member 0x20000 must not be set in the -Z (flags) commandline switch (this bit simply disables the setup wizard). 5: The program must be able to locate WSOCK32.DLL in any of the usual places where LoadLibrary would look (the Windows System directory, the Windows directory, the path, the current directory). Note that the check in step 5 is unintentionally quite extensive - the file not only has to be present, but Pegasus Mail actually has to be able to open it for reading (this is because I have a general-purpose file existence checking routine that attempts to make sure that the file not only exists, but can be opened, and I use that as part of the process of searching for a DLL). Aside from (all) that, I can't see anything else in there that might cause the setup wizard not to run. -- If there were some reliable way that I could determine that I was running under Wine, I would be *happy* to add code to the program that gave it specific behaviours in that environment - all you need to do is tell me what behaviours you need modified, and how I can detect Wine. Cheers! -- David -- ------------------ David Harris -+- Pegasus Mail ---------------------- Box 5451, Dunedin, New Zealand | e-mail: David.Harris(a)pmail.gen.nz Phone: +64 3 453-6880 | Fax: +64 3 453-6612 Real newspaper headlines from U.S. papers: MAN HELD OVER GIANT L.A. BRUSH FIRE -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

1 0

Minor AIM bug
by Dustin Navea 21 Nov '02

21 Nov '02

Hey now that I got AIM running, (have to copy from a windows install and force wine to use that winver) I noticed 2 small bugs.. Both are related to comctl32 AFAICT... 1) When going to sign on, the controls think that the left mouse button is pushed always, and so when you move the mouse over the screen name it selects it, that is more of a feature IMO, as it makes it easier to switch screen names 2) When resizing the chat windows, there is a significant amount of lag moving the controls, like you resize the window, but the controls all move a lot slower than the window does, hard to describe but if anyone wants a screenshot I can post one somewhere... -Dustin

1 0

PostMessage and NULL HWND's
by steve.lustbader＠philips.com 21 Nov '02

21 Nov '02

PostMessage fails if you pass in NULL as the HWND argument. According to the MSDN, a NULL HWND means "The function behaves like a call to PostThreadMessage with the dwThreadId parameter set to the identifier of the current thread." Currently, PostMessage tries to get the thread id of the hwnd, which of course fails since it's NULL in this case, and of course the error is Invalid Window Handle. It seems like a simple fix is a test if hwnd is NULL and calling PostThreadMessage with the right thread ID, but I don't know how to get the current thread's ID. Any ideas/suggestions? -Steve

2 1

RE: Adding -lc when linking?
by Patrik Stridvall 21 Nov '02

21 Nov '02

> Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes: > > > How should this be solved (in a portable way)? > > Adding -lc seems the right way. In fact I committed that fix last > night ;-) Yes I noticed. :-) However, it doesn't seem to be the 100% correct fix. DLLs using pthreads like the ones depending on OpenGL needs to link with -lc_r instead of -lc on FreeBSD. ---8<--- gcc -shared -Wl,-Bsymbolic,-z,defs d3d8.spec.o basetexture.o cubetexture.o d3d8_main.o device.o directx.o indexbuffer.o resource.o surface.o swapchain.o texture.o vertexbuffer.o volume.o volumetexture.o d3d8.dll.dbg.o -o d3d8.dll.so -L../../dlls -L../../library -lwine -L../../ole -lwine_uuid -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -lm -lc /usr/lib/libgcc.a(_eh.o): In function `__empty': _eh.o(.text+0x9e): undefined reference to `pthread_setspecific' /usr/lib/libgcc.a(_eh.o): In function `__get_eh_info': _eh.o(.text+0xec): undefined reference to `pthread_key_create' _eh.o(.text+0x1b9): undefined reference to `pthread_getspecific' _eh.o(.text+0x1d8): undefined reference to `pthread_setspecific' /usr/lib/libgcc.a(frame.o)(.text+0x44b): undefined reference to `pthread_mutex_lock' /usr/lib/libgcc.a(frame.o)(.text+0x492): undefined reference to `pthread_mutex_unlock' /usr/lib/libgcc.a(frame.o): In function `__register_frame_info': frame.o(.text+0x8d9): undefined reference to `pthread_mutex_lock' frame.o(.text+0x900): undefined reference to `pthread_mutex_unlock' /usr/lib/libgcc.a(frame.o): In function `__register_frame_info_table': frame.o(.text+0x969): undefined reference to `pthread_mutex_lock' frame.o(.text+0x990): undefined reference to `pthread_mutex_unlock' /usr/lib/libgcc.a(frame.o): In function `__deregister_frame_info': frame.o(.text+0x9dc): undefined reference to `pthread_mutex_lock' frame.o(.text+0xa27): undefined reference to `pthread_mutex_unlock' frame.o(.text+0xa4d): undefined reference to `pthread_mutex_unlock' *** Error code 1

3 2

Re: COM Enhancement patch
by John K. Hohm 21 Nov '02

21 Nov '02

> Well, I was hoping some of the COM experts would comment on that. If > I understand it right you are avoiding writing some thunking routines > for older interfaces, at the cost of an extra pointer access in every > function. I'm not convinced it's a good trade-off, but I'd like to > hear other opinions. I might not exactly be an expert, but I don't like the extra work being done everywhere with the extra pointer. If writing the thunk functions is really so cumbersome, perhaps a macro for generating the thunk functions is in order.

3 2

re: RFC: console & curses
by Dan Kegel 21 Nov '02

21 Nov '02

Eric wrote: > N2: one could try running wineconsole USER backend with ttydrv instead > of x11drv, but that's out of the scope of this (maybe for Dimi's fun > projects list ttydrv is not as far out as all that. I use ttydrv now to run commandline windows programs that output to stdout. I *cannot* use the current Debian wine, because *it uses curses*. Curses renders commandline windows programs useless. Imagine a program that outputs two lines of text. With Wine switching to the alternate text screen on entry, and switching back on exit, *you never see those lines of text, ever*. And with those escape characters gunking up the output, you certainly can't pipe the output of wine running that console program to a file and get anything sensible. Please help make wine safe for running commandline programs from the unix shell - let us select 'ttydrv, no curses' easily somehow! I'm tired of having a separate .wine directory for console programs, and I'm tired of debian's wine (and possibly also the main tree) breaking commandline programs so badly. - Dan

3 4

winspool
by Dimitrie O. Paun 21 Nov '02

21 Nov '02

Folks, On windows people link to winspool as such: -lwinspool In Wine, we need to do: -lwinspool.drv Obviously, this causes problems. Should we create a winspool -> winspool.drv link in dlls/? -- Dimi.

1 0

Visual-MinGW
by Dimitrie O. Paun 21 Nov '02

21 Nov '02

Folks, After a bit of hacking, I've got the Visual-MinGW project to compile, and link just fine. Problem is that it does not run. Dies right away with a segmentation fault, so I think I've messed something up with the building part. So, to help you help me, I've included the following: -- the command lines used to build the darn thing -- the script I've created to start the program -- an attempt to run it -- the last lines of a strace on the program Help with this would be greatly appreciated. BUILDING ======== I've not included the makefile, it's irrelevant I think, as long as the actual gcc invocations are here, right? [dimi@dimi src]$ make g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o CList.o CList.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o editor.o editor.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o main.o main.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o process.o process.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o project.o project.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o winui.o winui.cpp winui.cpp: In constructor `CShellDlg::CShellDlg()': winui.cpp:2062: warning: comparison between signed and unsigned integer expressions /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lntdll -lmsvcrt gcc -W -Wall -fPIC -DSTRICT -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm SCRIPT ====== #!/bin/sh appdir="/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src" winedir="/home/dimi/dev/wine/wine" LD_LIBRARY_PATH="$winedir/dlls:$winedir/library:$winedir/unicode:$LD_LIBRARY_PATH" WINEDLLPATH="$winedir/dlls" WINESERVER="$winedir/server/wineserver" WINELOADER="$winedir/miscemu/wine" export LD_LIBRARY_PATH WINEDLLPATH WINESERVER WINELOADER # and run the application exec "$WINELOADER" "$appdir/$0.exe.so" "$@" RUNNING ======= Not very exciting, is it? :( [dimi@dimi src]$ ./visual-mingw Segmentation fault STRACE ====== open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw", O_RDONLY|O_LARGEFILE) = 9 ioctl(9, VFAT_IOCTL_READDIR_BOTH, 0xbfffe6d0) = -1 ENOTTY (Inappropriate ioctl for device) close(9) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9 fstat64(9, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 280 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 0 close(9) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src", O_RDONLY|O_LARGEFILE) = 9 ioctl(9, VFAT_IOCTL_READDIR_BOTH, 0xbfffe6d0) = -1 ENOTTY (Inappropriate ioctl for device) close(9) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9 fstat64(9, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 1160 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 0 close(9) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [RTMIN], 8) = 0 write(4, "\24\0\0\0\0\0\0\0\0\0\0\0\30\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 close(6) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src/visual-mingw.exe.so", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\300\0"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0775, st_size=284747, ...}) = 0 old_mmap(NULL, 265292, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x40560000 mprotect(0x40596000, 44108, PROT_NONE) = 0 old_mmap(0x40596000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x36000) = 0x40596000 old_mmap(0x4059d000, 15436, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4059d000 close(6) = 0 open("/home/dimi/dev/wine/wine/dlls/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/library/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/unicode/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0644, st_size=76534, ...}) = 0 old_mmap(NULL, 76534, PROT_READ, MAP_PRIVATE, 6, 0) = 0x40205000 close(6) = 0 open("/usr/lib/libstdc++.so.5", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\246"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0755, st_size=4181584, ...}) = 0 old_mmap(NULL, 727004, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x405a1000 mprotect(0x40639000, 104412, PROT_NONE) = 0 old_mmap(0x40639000, 86016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x98000) = 0x40639000 old_mmap(0x4064e000, 18396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4064e000 close(6) = 0 open("/home/dimi/dev/wine/wine/dlls/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/library/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/unicode/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libgcc_s.so.1", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\10\23\0"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0755, st_size=854160, ...}) = 0 old_mmap(NULL, 32288, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x40248000 mprotect(0x4024f000, 3616, PROT_NONE) = 0 old_mmap(0x4024f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x7000) = 0x4024f000 close(6) = 0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ -- Dimi.

4 16

RE: Adding -lc when linking?
by Patrik Stridvall 21 Nov '02

21 Nov '02

> When compiling Wine on FreeBSD, there are tons of warnings of the > following kind (and have been that way since I can remember) which > regularily cause confusion and support requests by people building > our port: [snip] Yes, I have noticed. :-) > Alfred (Cc:ed) verified that these warnings can be eliminated by > > o getting rid of the -Wl,-Bsymbolic option (which you probably want > to keep to actually get warnings linking symbols are hosed), or > > o explicitly adding -lc. > > Would you mind making one of these changes (neither should break > GNU/Linux)? If not, how should this problem be addressed? It it is also fixed by adding --allow-shlib-undefined after -Wl,-Bsymbolic Like: -Wl,-Bsymbolic,--allow-shlib-undefined I submitted a fix doing this to Alexandre but it was rejected (or forgotten). I'm personnally not sure what is correct --allow-shlib-undefined just suppresses the warnings AFAIK. > PS: Please Cc: Alfred and me when replying, as we are not on > this list. Sure.

3 2

Disabled OpenGL (???)
by Dustin Navea 21 Nov '02

21 Nov '02

*** Warning: the OpenGL version you have installed relies on libpthread for *** thread-safety. To prevent crashes, OpenGL support has been disabled. *** A fix for glibc 2.1.3 that seems to work is included in this version of Wine, *** start configure with '--enable-opengl' to force OpenGL support. Configure finished. Do 'make depend && make' to compile Wine. I re-ran configure and forced OpenGL, but I would like to know how to get a non-libpthread version of OpenGL if at all possible.. -Dustin

2 1

Compiling wine problem: redhat 8 libperl-devel?
by Mike Hearn 21 Nov '02

21 Nov '02

Hi, As the prospect of having to go back to XP is looming if I can't get the adobe svg plugin working properly, I'm trying to build my own Wine, and then point CrossOver to it so stuff like IE will (hopefully) continue to work well. Unfortunately the compile dies when it tries to build winetest, as I think it needs the libperl development headers. Unfortunately I can't find an RPM of these headers anywhere, does anybody know where I could find them? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

3 3

Pegasus Mail 4.02 ('Silver' App)
by Rick Romero 21 Nov '02

21 Nov '02

Hey all, I'm currently testing out Pegasus Mail, and I've noticed three issues that I would like to help with debugging. One issue I've found is a window refesh issue. By default Pegasus Mail will minimize to the system tray, not the taskbar. This doesn't work. Once you've minimized Pmail, or merely changed to another virtual desktop, the app window no longer responds. (the default ison - must turn off). With the window open, Pegasus Mail IS on the taskbar, only the option is checked for that to disappear if the app is minimized. After you turn the 'taskbar' setting back on, everything works fine. The second issue, I've noticed that double-clicking the system tray icon does notrestore Pegasus Mail. I can minimize it so it appears both on the taskbar and the system tray, but I can't restore the application from the system tray icon (though I can from the taskbar). You CAN right-click, and get a menu. The two menu options sort of work: New Mail information, opens a new window that has the number of new messages. Works fine. The third issue the the systray icon's 2nd menu item: Start a New Mail Message, does just that, but the window starts shrunk down. All you can see is the "Message(F8)" Tab of that window. Once you resize the window, it appears to work fine. I'm not sure if all these issues can be covered with one trace, let me know what steps you want me to take to try and resolve these issues. Thanks! Rick -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

3 7

winsock.h problem
by Dimitrie O. Paun 21 Nov '02

21 Nov '02

Guys, I've got the following problem: #include <winsock.h> #include <windows.h> fails miserably in Wine (but apparently works in Windows), whereas: #include <windows.h> #include <winsock.h> works, no problem. The errors I get are: In file included from /home/dimi/dev/wine/wine.src/include/windows.h:62, from /home/dimi/dev/wine/wine.src/include/winsock.h:33, from winnet.c:46: /home/dimi/dev/wine/wine.src/include/winsock2.h:401: warning: type defaults to `int' in declaration of `SOCKET' /home/dimi/dev/wine/wine.src/include/winsock2.h:401: warning: `__stdcall__' attribute only applies to function types /home/dimi/dev/wine/wine.src/include/winsock2.h:401: parse error before "WSAAccept" /home/dimi/dev/wine/wine.src/include/winsock2.h:402: parse error before "DWORD" /home/dimi/dev/wine/wine.src/include/winsock2.h:403: parse error before "DWORD" /home/dimi/dev/wine/wine.src/include/winsock2.h:406: parse error before "const" /home/dimi/dev/wine/wine.src/include/winsock2.h:412: parse error before "HANDLE" /home/dimi/dev/wine/wine.src/include/winsock2.h:416: parse error before "HANDLE" /home/dimi/dev/wine/wine.src/include/winsock2.h:417: parse error before "LPWSAOVERLAPPED" /home/dimi/dev/wine/wine.src/include/winsock2.h:423: parse error before '*' token /home/dimi/dev/wine/wine.src/include/winsock2.h:424: parse error before '*' token /home/dimi/dev/wine/wine.src/include/winsock2.h:428: parse error before "DWORD" /home/dimi/dev/wine/wine.src/include/winsock2.h:435: parse error before '*' token /home/dimi/dev/wine/wine.src/include/winsock2.h:436: parse error before '*' token /home/dimi/dev/wine/wine.src/include/winsock2.h:438: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:439: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:440: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:443: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:444: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:445: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:449: warning: type defaults to `int' in declaration of `SOCKET' /home/dimi/dev/wine/wine.src/include/winsock2.h:449: warning: `__stdcall__' attribute only applies to function types /home/dimi/dev/wine/wine.src/include/winsock2.h:449: parse error before "WSASocketA" /home/dimi/dev/wine/wine.src/include/winsock2.h:450: warning: type defaults to `int' in declaration of `SOCKET' /home/dimi/dev/wine/wine.src/include/winsock2.h:450: warning: `__stdcall__' attribute only applies to function types /home/dimi/dev/wine/wine.src/include/winsock2.h:450: parse error before "WSASocketW" /home/dimi/dev/wine/wine.src/include/winsock2.h:451: parse error before "LPSOCKADDR" /home/dimi/dev/wine/wine.src/include/winsock2.h:452: parse error before "LPSOCKADDR" In file included from winnet.c:46: /home/dimi/dev/wine/wine.src/include/winsock.h:327: `SOCKET' redeclared as different kind of symbol /home/dimi/dev/wine/wine.src/include/winsock2.h:450: previous declaration of `SOCKET' -- Dimi.

2 2

Re: Office '97 install problems
by Dan Schwarz 21 Nov '02

21 Nov '02

Boris <boris(a)thinovations.com> wrote: > I cant seem to get Office '97 installed. Setup starts up and when it > says "Searching for installed components", It says "Setup cannot > continue". What could be causing that? You're trying to install an upgrade-only version of Office '97. This version will scan your hard drive for an existing Office '95 or '97 installation, and it will abort if it doesn't find one. Satisfy this precondition or find a full version of Office '97 and you should be fine. -Dan

1 0

RE: About picture format.
by Patrik Stridvall 21 Nov '02

21 Nov '02

> ÔÚ 2002-11-20 Èý µÄ 15:27£¬ Marcus Meissner Ð´µÀ£º > > On Tue, Nov 19, 2002 at 09:20:40PM +0800, yf wrote: > > > I'm using a application that using 0x0010 picture format. > I found that > > > wine only support Bitmap and JPEG picture format. Where > can I get some > > > info about it. I want to implement it. Pls give me some > hints about it. > > > > Where is it trying to use that picture format? In which API call? > fixme:ole:OLEPictureImpl_Load Unknown magic 0010 > > that is wine-20021031/dlls/oleaut32/olepicture.c OK. This only means that the first two bytes in the file is 0x10 0x00. I don't know what file format that is. But if you know what file it is trying to load you can run the Unix command file on it, perhaps it will tell what type of file it is. Otherwise you have add code in olepicture.c to handle the case 0x0010 and some code for dumping the file from there.

3 2

Office '97 and Office XP
by Boris 21 Nov '02

21 Nov '02

I cant seem to get Office '97 installed. Setup starts up and when it says "Searching for installed components", It says "Setup cannot continue". What could be causing that? I can install Office 2000 properly but '97 wont install? Also after tinkering around with my wine configuration, [Best results is when I say im running Winme] but it tries installing but then has a problem. It would be great getting the Office '97 and XP installation working easily.

1 0

Re: Get rid of W->A calls: LoadImageW
by Huw D M Davies 21 Nov '02

21 Nov '02

On Tue, Nov 19, 2002 at 09:10:31PM +0100, Stefan Leichter wrote: > Changelog > ------------ > replaced CreateDCA by CreateDCW in LoadImageW to Get rid of W->A calls > > Index: wine/windows/cursoricon.c > =================================================================== > RCS file: /home/wine/wine/windows/cursoricon.c,v > retrieving revision 1.56 > diff -u -r1.56 cursoricon.c > --- wine/windows/cursoricon.c 13 Nov 2002 19:43:53 -0000 1.56 > +++ wine/windows/cursoricon.c 18 Nov 2002 21:38:42 -0000 > @@ -72,6 +72,8 @@ > > static HDC screen_dc; > > +static WCHAR DISPLAYW[] = {'D','I','S','P','L','A','Y',0}; > + > /********************************************************************** > * ICONCACHE for cursors/icons loaded with LR_SHARED. > * > @@ -2052,7 +2054,7 @@ > return BITMAP_Load( hinst, name, loadflags ); > > case IMAGE_ICON: > - if (!screen_dc) screen_dc = CreateDCA( "DISPLAY", NULL, NULL, NULL ); > + if (!screen_dc) screen_dc = CreateDCW( DISPLAYW, NULL, NULL, NULL ); > if (screen_dc) > { > UINT palEnts = GetSystemPaletteEntries(screen_dc, 0, 0, NULL); > I don't see the point of this at all. Why does it matter that we're calling CreateDCA here? it's not as if we're losing information by converting a Unicode to an Ascii string. Huw.

2 1

Winelib support
by Dimitrie O. Paun 21 Nov '02

21 Nov '02

Hi folks, I'm one of the Wine (http://www.winehq.org) developers, and I just managed to build Putty under Winelib. That is, Putty now runs as a native Linux application. The interesting part is that I've managed to do so with virtually no changes to the source code, just a few changes to the makefile.cyg file. Now, my question to you: are you interested in supporting Putty under Wine, as a Winelib app? If so, I can clean up my changes, and send you a patch for the build system to incorporate in your tree. BTW, the resulting executable is about 500K, so it's not that large, compared to the Windows one at 360K. -- Dimi.

1 0

Wine Doc
by Dustin Navea 21 Nov '02

21 Nov '02

When I go to make wine docs with make html, I still receive the files that someone was getting before, looks like random numbers and letters for the filename in /wine/documentation/wine-doc... -Dustin

3 3

Re: wine/ include/x11drv.h include/config.h.in gra ...
by Michael Stefaniuc 20 Nov '02

20 Nov '02

Hello, it seems that this patch introduced a nasty bug (at least for me). With "DesktopDoubleBuffered" = "N" wine get's a SIGSEGV, tries to start the debugger, next SIGSEGV looping forever. The SIGSEGV happens in DefaultScreenOfDisplay (X function) called from X11DRV_GDI_Initialize and that one is called by process_attach (x11drv_main.c) . Setting "DesktopDoubleBuffered" = "Y" 'fixes' the bug. Any idea? bye michael P.S.: i'll open a bug report but at the moment i'm too tired. On Thu, Nov 14, 2002 at 10:16:39PM -0600, Alexandre Julliard wrote: > ChangeSet ID: 6301 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/11/14 22:16:39 > > Modified files: > include : x11drv.h config.h.in > graphics/x11drv: opengl.c > dlls/x11drv : x11drv_main.c > dlls/opengl32 : Makefile.in > dlls/glu32 : Makefile.in > dlls/ddraw : Makefile.in > dlls/d3d8 : Makefile.in > . : configure.ac configure > > Log message: > Lionel Ulmer <lionel.ulmer(a)free.fr> > Load OpenGL library dynamically from x11drv. > > Patch: http://cvs.winehq.com/patch.py?id=6301 > > Old revision New revision Changes Path > 1.117 1.118 +3 -1 wine/include/x11drv.h > 1.132 1.133 +3 -0 wine/include/config.h.in > 1.12 1.13 +79 -22 wine/graphics/x11drv/opengl.c > 1.64 1.65 +8 -9 wine/dlls/x11drv/x11drv_main.c > 1.12 1.13 +1 -1 wine/dlls/opengl32/Makefile.in > 1.3 1.4 +1 -1 wine/dlls/glu32/Makefile.in > 1.26 1.27 +1 -1 wine/dlls/ddraw/Makefile.in > 1.3 1.4 +1 -1 wine/dlls/d3d8/Makefile.in > 1.95 1.96 +6 -3 wine/configure.ac > 1.361 1.362 +67 -4 wine/configure -- 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

2 2

Installing office apps
by Anant Kabra 20 Nov '02

20 Nov '02

Hi, I've got a windows free install of wine (Debian daily build package). I'm trying to install office apps (Office 2k - word, excel, ms project 2k), but for each I get the following behavior I go through the license key and customize installation sections fine, then it starts verifying install tasks, this gets about half way through then I get a dialog saying Internal error 2761: Contact product support for assistance. I click OK and the install terminates. Any ideas what's going on? Can I do anything else to provide more information? Thanks, -- Anant Kabra email: anant(a)yash.com phone: (210) 379-0338 (mobile)

1 0

_itoa
by Dimitrie O. Paun 20 Nov '02

20 Nov '02

Folks, msvcrt has this in its spec file: dlls/msvcrt/msvcrt.spec:@ forward -noimport _itoa ntdll._itoa Yet at link time, I get an undefined reference error: /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lmsvcrt gcc -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm project.o: In function `CProject::Open(char*, unsigned short)': project.o(.text+0x20e5): undefined reference to `_itoa' winui.o: In function `CStatusBar::WriteLong(long, int)': winui.o(.text+0x1d9a): undefined reference to `_itoa' winui.o: In function `CMessageBox::DisplayLong(long)': winui.o(.text+0x30a2): undefined reference to `_itoa' However, if I also link in ntdll, it works: /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lntdll -lmsvcrt gcc -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm [dimi@dimi src]$ Question is, is this correct? Do I need to link ntdll into the app as well? -- Dimi.

3 3

Imporving support for graphics tablets in wine (wintab.dll)
by Robert North 20 Nov '02

20 Nov '02

Modern graphics tablets also provide pressure and tilt information, essential for quality graphics editors such as Painter & Photoshop. Currently graphics tablets are treated as mice in wine, and so cannot provide this information to a Win16/32 app. To access pressure & tilt info in Windows, a programmer would use the wintab.dll. Has anyone attempted to build a wintab.dll for Wine? I'm interested in attempting an extremely limited implementation for Painter & Photoshop, but don't want to reinvent the wheel. Assuming nobody has done this what's the first step? Raise a bug, and accept it? Bye -Rob.

4 4

Re: Win32s cleanups
by Dimitrie O. Paun 20 Nov '02

20 Nov '02

On November 19, 2002 12:30 pm, Jukka Heinonen wrote: > File msdos/vxd.c and files dlls/win32s/* should now be the > only files which contain Win32s specific code. We should just nuke it altogether. As Ulrich explained, it's only useful for running the Win32s *subsystem* that came with some older apps. Again, that's useful not for the apps, but for the silly Win32 MS subsystem. And it's most likely broken anyway. Now, why anyone do that? What's to gain? It doesn't help anyone, it just adds bloat and confusion to the tree. And waists valuable developer time. Like yours for dealing with it, or Ulrich for explaining, or mine, or anyone following this thread. And thing is, in 2-3 months people will forget, and this will come back to haunt us. And more time will be wasted. And so on. Just get rid of it, everybody wins. -- Dimi.

2 2

RE: About picture format.
by Patrik Stridvall 20 Nov '02

20 Nov '02

> ÔÚ 2002-11-20 Èý µÄ 18:13£¬ Patrik Stridvall Ð´µÀ£º > > > 0^80?3 2002-11-20 0?60<5 0...80?2 15:270"50...1 > Marcus Meissner 0^40...70...80?80"50?2 > > > > On Tue, Nov 19, 2002 at 09:20:40PM +0800, yf wrote: > > > > > I'm using a application that using 0x0010 picture format. > > > I found that > > > > > wine only support Bitmap and JPEG picture format. Where > > > can I get some > > > > > info about it. I want to implement it. Pls give me some > > > hints about it. > > > > > > > > Where is it trying to use that picture format? In which > API call? > > > fixme:ole:OLEPictureImpl_Load Unknown magic 0010 > > > > > > that is wine-20021031/dlls/oleaut32/olepicture.c > > > > OK. This only means that the first two bytes in the file is > 0x10 0x00. > > > > I don't know what file format that is. > > > > But if you know what file it is trying to load you can run the > > Unix command file on it, perhaps it will tell what type of file > > it is. > I used, but file tell: "data". That means it don't know yet. > Maybe it is > not a pic format, but why OLEPictureImpl_Load handle it, I wonder? I don't know. You need to send some sort of trace of your application if it is to be possible to determine that.

1 0

Problem with network functions
by Sylvain Petreolle 20 Nov '02

20 Nov '02

Doing a cvs update made some programs unable to access the network. Cygwin installer and Yahoo Messenger 5.5 say both they can't initialize the network If usefull, I pasted a log of the cygwin installer with --debugmsg +wininet. trace:wininet:DllMain 0x41e40000,1,(nil) fixme:wininet:InternetAttemptConnect Stub trace:wininet:InternetOpenA trace:wininet:InternetCrackUrlA trace:wininet:GetInternetScheme trace:wininet:SetUrlComponentValue http://sources.redhat.com/cygwin/mirrors.lst (4) trace:wininet:SetUrlComponentValue (null) (0) trace:wininet:SetUrlComponentValue (null) (0) trace:wininet:SetUrlComponentValue sources.redhat.com/cygwin/mirrors.lst (18) trace:wininet:SetUrlComponentValue /cygwin/mirrors.lst (19) trace:wininet:InternetCrackUrlA http://sources.redhat.com/cygwin/mirrors.lst: host(sources.redhat.com) path(/cygwin/mirrors.lst) extra() trace:wininet:InternetConnectA ServerPort 80 trace:wininet:HTTP_Connect --> trace:wininet:HTTP_Connect <-- trace:wininet:HttpOpenRequestA trace:wininet:InternetCloseHandle 0x402d4db8 trace:wininet:HTTP_CloseHTTPSessionHandle trace:wininet:SendAsyncCallback Send Callback 70 trace:wininet:InternetQueryOptionA 0x00000009 trace:wininet:DllMain 0x41e40000,3,(nil) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Cygwin/Wine : status update
by Sylvain Petreolle 20 Nov '02

20 Nov '02

Cygwin bash currently fails to execute due to OpenProcessToken. Looking in source, I see that advapi32.OpenProcessToken calls ntdll.NtOpenProcessToken. This functions is a stub that returns always false today. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 3

Screenshots
by Mike Hearn 20 Nov '02

20 Nov '02

Hi, I'm happy to put together some screenshots on my RedHat 8 box at work (pretty much default install albiet with a slightly customised gnome2 layout). However it strikes me that having people just randomly send shots to Brian isn't the best way to go about it as nobody knows who has sent what. Have you actually got any yet Brian? If not, are there any apps you'd like to me make screenshots of? I currently have IE6 and WinZip installed, but can go install more if they are freely available on the net. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

1 0

About picture format.
by yf 20 Nov '02

20 Nov '02

I'm using a application that using 0x0010 picture format. I found that wine only support Bitmap and JPEG picture format. Where can I get some info about it. I want to implement it. Pls give me some hints about it.

2 2

Re: the dreaded rpcss patch (rpc_J_PL0)
by Alexandre Julliard 20 Nov '02

20 Nov '02

Greg Turner <gmturner007(a)ameritech.net> writes: > * configure; > configure.ac; > dlls/rpcrt4: .cvsignore, Makefile.in, rpc_binding.h, rpcrt4.spec, > rpcrt4_main.c, rpc_epmap.c (new); > include: rpcdce.h, rpcdcep.h, rpcndr.h, winbase.h; > include/wine: rpcss_shared.h (new); > programs: Makefile.in; > programs/rpcss (new dir): .cvsignore (new), Makefile.in (new), > README (new), atomicity.c (new), epmap_server.c (new), > named_pipe_kludge_client.c (new), named_pipe_kludge_server.c (new), > rpcss.h (new), rpcss_main.c (new): > Greg Turner <gmturner007(a)ameritech.net>, > Ove Kåven <ovek(a)transgaming.com> > - a preliminary implementation of endpoint-mapping via a new > on-demand server-ish process ("rpcss.exe.so") > - more header fixups > - (re)implement RpcEpRegisterA, RpcEpUnregister, and RpcEpResolveBinding > using the new rpcss functionality > - update the todo list in rpcrt4_main.c a bit A few things: - Please don't name files 'kludge_something'; this makes it impossible to implement things properly without renaming files. - Don't share C files between rpcrt4 and rpcss, just copy the stuff you need (and at least atomicity.c doesn't seem necessary at all, you could just as well make mutex calls directly). - Please get rid of the various #ifdefs. - It would be better to put the README documentation directly in rpcss_main.c, people don't notice README files in subdirectories. -- Alexandre Julliard julliard(a)winehq.com

2 4

Diablo II fails after a recent cvs update..
by Dustin Navea 20 Nov '02

20 Nov '02

Going to start Diablo II after an update last night (after not updating for a couple of days) causes a crash. What debugmsgs would be needed to fix this I dunno, but I suppose I could do a regression test.. Anyone wanna take a look after I post the results of the regression test (probably some time thursday)? -Dustin

1 0

Wine merge required: COM/OLE header changes
by Ove Kaaven 20 Nov '02

20 Nov '02

These patches are against ReWind and requires some merging work in order to apply to Wine. Could someone (hm... Greg?) do that for me? The fundamental idea here is to make sure that no files except unknwn.h ever include wine/obj_base.h directly, because the IUnknown interface definition will soon move to unknwn.h, and the API function prototypes will move to objbase.h (which indirectly includes unknwn.h through objidl.h). While I was at it, I also made sure that a couple of common to-be-IDL-generated files aren't included directly, as the headers in question have wrapper headers that are supposed to contain related API function prototypes - these prototypes will also be moved later, so I thought I might as well ensure that the wrapper headers are used now. The attached comhdr1.diff contains header changes and #ifdef guards that force a compilation error if any of these "forbidden" headers are included directly. It seems to apply to Wine as-is. (And I think the #ifdef guards should be applied to Wine even if #ifdefs aren't popular around here, because it protects against introduction of new bad code in Wine while the conversion is in progress; and when a particular header has been successfully converted, its respective #ifdef guard will of course be removed again.) The attached comhdr2.diff seems to fix all the resulting compilation errors in ReWind, and is what needs "merging". Apply as much of it as you can and fix the compilation errors that remain in Wine. Thanks.

2 1

RE: Configure question
by Patrik Stridvall 19 Nov '02

19 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Still I think the code should verify that any assumptions > > made str really true, if possible. Like: > > > > #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || > > defined(HAVE_GETPWENT) > > # if !(defined(HAVE_GETPWUID) && defined(HAVE_GETPWNAM) && > > defined(HAVE_GETPWENT)) > > # error All or none of the functions getpwuid, getpwnam > and getpwent are > > assumed to exist > > # endif > > #endif > > There is absolutely no reason to do that, because we shouldn't assume > anything like that. As I said, if you use getpwnam() you check for > HAVE_GETPWNAM; whether getpwuid() also exists or not is completely > irrelevant. Well, the problem is it is possible that you in order to fail gracefully needs to do different things depending on whether some other function exists or not. OK, the functions meantioned above are not likely to have side effect or something else that effect the other functions in any relevant way. But there might be function pairs, tripples etc that does. Sure you can say that since any function might fail any code should always be able to handle a missing function as well since it in some abstract meaning it sufficiently similar to a normal failure. But regardless, I think it is good to make it clear that he or she who wrote expects certain things to be true and things might not work if they are not true. I somebody hits the "assertion" they can audit the code and if it seems that it doesn't matter they can modify the "assertion" to whatever is proper in the light of the new different enviroment. If it does matter they will modify the code accordingly... Somehow this seems much better than just hoping that the orginal programmer handled all error cases correctly...

1 0

RE: Configure question
by Patrik Stridvall 19 Nov '02

19 Nov '02

> Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > > > Very true. Perhaps the practical way would be to assume > > HAVE_GETPWUID == HAVE_GETPWNAM and see whether someone with > > a really strange platform complains (but see below). > > There's no reason to do that, it's trivial to check for both. If you > use getpwnam() check for HAVE_GETPWNAM, if you use getpwuid() check > for HAVE_GETPWUID. Simple, logical, and works even on strange > platforms. Of course. It was so obvious that I missed it. :-) Still I think the code should verify that any assumptions made str really true, if possible. Like: #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || defined(HAVE_GETPWENT) # if !(defined(HAVE_GETPWUID) && defined(HAVE_GETPWNAM) && defined(HAVE_GETPWENT)) # error All or none of the functions getpwuid, getpwnam and getpwent are assumed to exist # endif #endif

2 1

RE: Stub implementation of CABINET.DLL
by Patrik Stridvall 19 Nov '02

19 Nov '02

> >However, when I saw that not much happend despite > >getting code from cabextrect under LGPL I thought > >that perhaps people were having trouble on how > >to create a new DLL in Wine and how to extract > >the declarations from the Microsoft header without > >creating a derived work. I have done it many > >times before so thought why not do it... > > > >So I very happy that somebody is intrested in continuing. > > > >PS. If anybody have some other DLL that they wish to implement > >but don't now how to do it, don't hesitate to ask me to > >create a stub DLL with related headers. > > If it is not too much effort, could you elaborate on the > derived work issue. I have been thinking about trying to > stub out, then work at implementing, a particular component. > Rather than have someone else do the work, I am more > interested in learning about doing it myself, and about > any issues (legal and technical) involved. > I am not asking for a complete howto here, but even a > summary of the highlights would be quite valuable (to me > at least). First of all copyright doesn't protection facts or ideas only a specific (and unique) expression of facts and ideas. This is normally called a work. Specifically it doesn't protect any underlying functionally inherent or derivable from the work. This is normally called the implementation of the functionallity. Even more specifically it doesn't protect the way interaction with any functionallity, that is possible to derived from the work, is done. This is normally called the interface to the functionallity. Header files for the most part defines interfaces; more specifically constant declarations (read: defines), function declarations, type declarations and. So all such things are free for taking. However netherless the less, the header file is not entirely free of possible protected expression. Specifically: 1. Formatting 2. Comments 3. Inline functions and complex macros I will address each them in turn. Formatting is not normally any problem since there are not that many way to format C declarations, none of which is likely to be unique to Microsoft, let alone expressive. Still I always format the new file in a way I personally like, just in case. Comments are are probably the largest proplem. They are not strictly part of the interface so if you are unsure you can just remove them. In most cases, in fact the intresting cases, however they contains facts about the interface. Note however I said _contains_ facts not are facts. Part of them might be protected expression so we have to be careful here. Again, note that in order to be protected an expression have to unique as well as expressive. Most short sentences are neither unique, nor are they expressive, they just explain the facts in some straight forward way. Still if the not formulated in a way I as well would use the express myself I rewrite them. As for longer sentences and specificially multi sentence paragraphs. I usually delete or reformulate and often shorten it using my own words. The comments are, as I said, not strictly needed in for the header file to work. Inline function and complex macros can be a little tricky. However they are usually rare so rewriting them in a way I would have written it is not that much work and functinallity in itself is I said explain above not protected by copyright.

1 0

RE: Get rid of W->A calls: LoadImageW
by Patrik Stridvall 19 Nov '02

19 Nov '02

> > Index: wine/windows/cursoricon.c [snip] > > - if (!screen_dc) screen_dc = CreateDCA( "DISPLAY", > NULL, NULL, NULL ); > > + if (!screen_dc) screen_dc = CreateDCW( DISPLAYW, [snip] > I don't see the point of this at all. Why does it matter that we're > calling CreateDCA here? it's not as if we're losing information by > converting a Unicode to an Ascii string. Policy reason: "No Unicode function should call an ASCII function if a Unicode variant of that function exists." But sure semantically speaking it might not make any difference in this case.

1 0

Re: problem with treeview
by steve.lustbader＠philips.com 19 Nov '02

19 Nov '02

Here's the output from +treeview: <App starting up> trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register <I press button to open dialog containing treeview> trace:treeview:TREEVIEW_Create wnd 0x2006a, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_Create wnd 0x20068, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_InsertItemA parent 0x41230a98 position 0xffff0002: '<callback>' trace:treeview:TREEVIEW_DoSetItem setting callback, item 0x41232060 trace:treeview:TREEVIEW_InsertItemA new item 0x41232060; parent 0x41230a98, mask 5 trace:treeview:TREEVIEW_GetNextItem flags:3, item 0x41232060;returns (nil) wine: Unhandled exception, starting debugger... "Dustin Navea" <Speeddymon@ev1. To: Steve Lustbader/ANR/MS/PHILIPS@AMEC net> <wine-devel(a)winehq.org> cc: 11/19/2002 03:35 Subject: Re: problem with treeview PM Classification: Try running wine with --debugmsg +treeview and post that somewhere to look at.. -Dustin ----- Original Message ----- From: <steve.lustbader(a)philips.com> To: <wine-devel(a)winehq.org> Sent: Tuesday, November 19, 2002 1:51 PM Subject: problem with treeview > My app calls TreeView_InsertItem, which leads to a crash in ntdll.dll. > A backtrace is available at http://www.lustbader.net/bt.txt, and I can > provide any other debug output if anyone thinks it will help. > TreeView_InsertItem is called like this: > > TVITEM tviFoo; > tviFoo.mask = TVIF_TEXT | TVIF_PARAM; > tviFoo.pszText = LPSTR_TEXTCALLBACK; > tviFoo.lParam = (LPARAM)pFoo; //pFoo is guaranteed to be non-NULL > TVINSERTSTRUCT tvinsFoo; > tvinsFoo.hParent = TVI_ROOT; > tvinsFoo.hInsertAfter = TVI_LAST; > tvinsFoo.item = tviFoo; > HTREEITEM hTreeFoo = TreeView_InsertItem(m_hWndUserTree, &tvinsFoo); > > Any ideas? > > -Steve > > >

1 0

RE: Configure question
by Patrik Stridvall 19 Nov '02

19 Nov '02

> Am Die, 2002-11-19 um 15.17 schrieb Patrik Stridvall: > > > One thing that you shouldn't assume is for example that > > if a function exists its reentrant variant exists as well. > Sure, got that. > > > And yes, you really should use the > > reentrent variant if present as well as having an > > alternative implementation if not. > > Hmm - really really always? This generates messy code, > and a lot of effort for very rare cases. Bad formulation. What I meant is that the code shouldn't depend on the existance of the reentrant function since it is not that unlikely that some platforms might only have the non reentrent one only. Still, I think we might need such a strict policy regardless. > I think we need a compromise, something in the line of either > > - a) use non-reentrant functions, protecting them with a critical > section (IMO ok for rarely called functions) or That is potentially slow since it uses locks. Not that likely to be a problem with the getpw* functions though but still... > - b) use only reentrant and treat the case where these aren't > available like the case where the respective functions aren't > available at all. No, not a good solution. There are rational reasons to not have the reentrent variants. > Of course b) would only be viable if a sufficiently large portion of > systems that support the non-reentrant variant support the > reentrant one > as well. I have no idea whether that's the case for the getpwXYZ > functions. If are on a embedded platform it is not entirely unlikely that it is possible to configure and compile the C library to not handle reentrancy issues in order to optimize for space. In fact it might make sense be able compile Winelib as not supporting reentrency either. It is a post 1.0 issue IMHO, but we should have a policy planning for that possiblity nether the less. So strictly speaking, we should IMHO do #ifdef HAVE_GETPWUID_R /* Use getpwuid_r */ #elsif defined(HAVE_GETPWUID) # ifdef _REENTRANT /* Lock. Use getpwuid. Unlock */ # else /* Use getpwuid */ # endif #else /* Fail gracefully */ #endif However adding the #ifdef _REENTRANT is a post 1.0 issue IMHO. > > As to the implict existance question: I'm not sure. > > First of all, to answer the related question: > > Should you have a alternative implementation for > > defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? > > > > IMHO the answer is no. It is not worth the effort to > > support hypotetical platforms unless we can verify the > > existance of one. > > Very true. Perhaps the practical way would be to assume > HAVE_GETPWUID == HAVE_GETPWNAM and see whether someone with > a really strange platform complains (but see below). Assume yes, however I think the should also verify as below. > > I suggest that we should detect the presence or absence > > of ALL function we use that is verified not to exist on > > some platform and have for example code like > > > > #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || > > defined(HAVE_GETPWENT) > > # if (defined(HAVE_GETPWUID) + defined(HAVE_GETPWNAM) + > > defined(HAVE_GETPWENT)) == 3 > > # define __HAVE_GETPW > > # else > > # error All or none of the functions getpwuid, getpwnam > and getpwent are > > assumed to exist > > # endif > > #endif > > > > in order to formalize the assumptions and generate a common > define to use in > > the code. > > Well I'd say that for a start we could simply do something like > > /* CAUTION: If there turns out to be some insane platform that has > * getpwuid() but not getpwnam() and getpwent(), this must be > * improved. > */ > #define __HAVE_GETPW HAVE_GETPWUID > > This would keep bloat out of configure in the first place, while > providing a generic __HAVE_GETPW macro for possible later use. As Alexandre said, having a special define is completely unnessary. Just test for existance of whatever function when you call it.

1 0

problem with treeview
by steve.lustbader＠philips.com 19 Nov '02

19 Nov '02

My app calls TreeView_InsertItem, which leads to a crash in ntdll.dll. A backtrace is available at http://www.lustbader.net/bt.txt, and I can provide any other debug output if anyone thinks it will help. TreeView_InsertItem is called like this: TVITEM tviFoo; tviFoo.mask = TVIF_TEXT | TVIF_PARAM; tviFoo.pszText = LPSTR_TEXTCALLBACK; tviFoo.lParam = (LPARAM)pFoo; //pFoo is guaranteed to be non-NULL TVINSERTSTRUCT tvinsFoo; tvinsFoo.hParent = TVI_ROOT; tvinsFoo.hInsertAfter = TVI_LAST; tvinsFoo.item = tviFoo; HTREEITEM hTreeFoo = TreeView_InsertItem(m_hWndUserTree, &tvinsFoo); Any ideas? -Steve

2 1

dlls/cabinet : CVS repository problem ?
by Sylvain Petreolle 19 Nov '02

19 Nov '02

When I updated my cvs tree (update -APd), I had problems with dlls/cabinet. It didn't add the files created by this patch : http://www.winehq.com/hypermail/wine-cvs/2002/11/0179.html The directory itself is unknown in the repository : [syl@snoop dlls]$ cvs update 2>&1 |tee cvslog ? cabinet ? cvslog cvs server: Updating . M Makefile.in cvs server: Updating advapi32 cvs server: Updating advapi32/tests ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 2

msvcrt vs std incl
by Dimitrie O. Paun 19 Nov '02

19 Nov '02

Hi guys, Here's a small test program: #include <windows.h> #include <stdio.h> #include <stdlib.h> #include <assert.h> int main() { printf("sizeof(wchar_t)=%d\n", sizeof(wchar_t)); return 0; } And I want to compile this with our msvcrt headers. Look what happens: [dimi@dimi wine]$ gcc -nostdinc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c In file included from /home/dimi/dev/wine/wine.src/include/windows.h:38, from test.c:1: /home/dimi/dev/wine/wine.src/include/winbase.h:23:20: stdarg.h: No such file or directory In file included from /home/dimi/dev/wine/wine.src/include/windows.h:38, from test.c:1: /home/dimi/dev/wine/wine.src/include/winbase.h:1257: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/winbase.h:1258: parse error before "va_list" In file included from /home/dimi/dev/wine/wine.src/include/windows.h:40, from test.c:1: /home/dimi/dev/wine/wine.src/include/winuser.h:23:20: stdarg.h: No such file or directory In file included from /home/dimi/dev/wine/wine.src/include/windows.h:40, from test.c:1: /home/dimi/dev/wine/wine.src/include/winuser.h:4459: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/winuser.h:4460: parse error before "va_list" In file included from test.c:2: /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:13:20: stdarg.h: No such file or directory In file included from test.c:2: /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:135: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:175: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:176: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:177: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:184: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:211: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:212: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:213: parse error before "va_list" test.c:4:20: assert.h: No such file or directory test.c: In function `main': test.c:8: `wchar_t' undeclared (first use in this function) test.c:8: (Each undeclared identifier is reported only once test.c:8: for each function it appears in.) [dimi@dimi wine]$ First off, are we supposed to die on the va_list stuff? Second, why is wchar_t undeclared? -- Dimi. P.S. Please do not ask why so many includes, I know they are not needed, but it should work, right?

5 11

Question: domain name
by Martin Wilck 19 Nov '02

19 Nov '02

Using a default domain name in Wine would be beneficial for certain Netapi functions. While it's no big deal to add a config option for that, there is the Windows registry value DefaultDomainName in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon which could be used for exactly that purpose. Is it better to - use a Wine config key, - use the above MS key, - or use both, the Wine key overriding the MS one if set? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

RE: Configure question
by Patrik Stridvall 19 Nov '02

19 Nov '02

> I am thinking about some netapi32 improvements where I'd need to call > the functions of the getpw/getgr family: getpwnam(), getpwent(), > getgrent(), etc. > > Configure checks for the "pwd.h" header and getpwuid(). Must > I add more > checks for all the functions I use, or is it ok to assume that > getpwuid() presence implies getpwnam() presence? Good question. I'm don't think we have any policy concerning this. Perhaps we should have. One thing that you shouldn't assume is for example that if a function exists its reentrant variant exists as well. For example that fact getpwnam exists doesn't imply that getpwnam_r exists. And yes, you really should use the reentrent variant if present as well as having an alternative implementation if not. As to the implict existance question: I'm not sure. First of all, to answer the related question: Should you have a alternative implementation for defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? IMHO the answer is no. It is not worth the effort to support hypotetical platforms unless we can verify the existance of one. To return to the original question: I suggest that we should detect the presence or absence of ALL function we use that is verified not to exist on some platform and have for example code like #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || defined(HAVE_GETPWENT) # if (defined(HAVE_GETPWUID) + defined(HAVE_GETPWNAM) + defined(HAVE_GETPWENT)) == 3 # define __HAVE_GETPW # else # error All or none of the functions getpwuid, getpwnam and getpwent are assumed to exist # endif #endif in order to formalize the assumptions and generate a common define to use in the code. Comments? Suggestions?

3 2

Re: CoInitialize
by steve.lustbader＠philips.com 19 Nov '02

19 Nov '02

>> On 13 Nov 2002 at 14:39, steve.lustbader(a)philips.com wrote: >> >> > One of the threads in my app calls CoInitialize, expecting it >> > to return S_OK (in fact, it's followed by an assert statement >> > requiring that it returns S_OK). When I run it in Wine, however, >> > CoInitialize returns S_FALSE, implying that this thread has >> > already initialized the COM library. Other threads call >> > CoInitialize, but this is the first time that this thread calls it. >> > Does Wine initialize COM differently from Windows? Are the other >> > threads' calls to CoInitialize screwing up this thread's call? > >Sort of, the problem is that Wine doesn't support apartments yet, so it >doesn't try to keep track of the threads that has called CoInitialize. > Does this mean that COM isn't being initialized properly for the calling thread, or only that it appears not to be initialized properly? -Steve

2 1

RE: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/)
by Kye Lewis 19 Nov '02

19 Nov '02

Hi, Has started working again for me - but I am still Puzzled as to what the problem was! Thanks, Kye Lewis kyethespy(a)liquid2k.com -----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin@winehq.com] On Behalf Of Gustavo Junior Alves Sent: Tuesday, November 19, 2002 9:49 PM To: Keith Matthews Cc: wine devel < Subject: Re: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/) The command LPRT is used for ipv6 over FTP, but I don't know any FTP servers that allow this command, maybe oftpd. Keith Matthews wrote: >On Tue, 19 Nov 2002 16:29:09 +1100 >"Kye Lewis" <kyethespy(a)liquid2k.com> wrote: > > > >>Hi, >> >>While trying to connect to the wineHQ ftp site, I am getting the >>following error with IE6: >> >>200 Type set to A. >>500 Illegal PORT command. >>500 LPRT not understood >> >> >> > >Don't know about the last error, but the illegal PORT is typically seen >when trying to use active FTP from behind a firewall that does not >support it. > >Command-line MS FTP clients don't support passive mode and I have heard >reports that IE does not also. If that is the problem you'll have to >switch to a Linux box or find a windows FTP client that supports >passive. > >

2 1

RE: Stub implementation of CABINET.DLL
by Jeff Smith 19 Nov '02

19 Nov '02

>From: Patrik Stridvall <ps(a)leissner.se> >To: "'Greg Turner'" <gmturner007(a)ameritech.net>, wine-devel(a)winehq.com > > > On Friday 15 November 2002 12:47 pm, Patrik Stridvall wrote: > > > Now that we have the permission to use cabextract > > > under the LGPL it would be useful to have stubs > > > for CABINET.DLL so intrested people can work > > > with implementing it with fewer "infrastructure" > > > problems. >[snip] > > Anyone working on this? If not I'd be glad to take it on, > > seems like it > > should be easy. > >I personally doesn't currently have that much time to work with it. > >However, when I saw that not much happend despite >getting code from cabextrect under LGPL I thought >that perhaps people were having trouble on how >to create a new DLL in Wine and how to extract >the declarations from the Microsoft header without >creating a derived work. I have done it many >times before so thought why not do it... > >So I very happy that somebody is intrested in continuing. > >PS. If anybody have some other DLL that they wish to implement >but don't now how to do it, don't hesitate to ask me to >create a stub DLL with related headers. If it is not too much effort, could you elaborate on the derived work issue. I have been thinking about trying to stub out, then work at implementing, a particular component. Rather than have someone else do the work, I am more interested in learning about doing it myself, and about any issues (legal and technical) involved. I am not asking for a complete howto here, but even a summary of the highlights would be quite valuable (to me at least). -- Thanks -- Jeff S. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

Configure question
by Martin Wilck 19 Nov '02

19 Nov '02

I am thinking about some netapi32 improvements where I'd need to call the functions of the getpw/getgr family: getpwnam(), getpwent(), getgrent(), etc. Configure checks for the "pwd.h" header and getpwuid(). Must I add more checks for all the functions I use, or is it ok to assume that getpwuid() presence implies getpwnam() presence? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

windres vs. wrc
by Dimitrie O. Paun 19 Nov '02

19 Nov '02

Folks, I've just discovered (DUH!) another free resource compiler: http://www.redhat.com/docs/manuals/gnupro/GNUPro-Toolkit-98r2/5_ut/c_Usingb… This one is part of binutils. Now, like any good hacker, I hate such code duplication. Granted, I haven't looked through the code of windres, so I can't say if it's any good. However, here are some points to ponder: -- all Win32 free software projects out there use windres, not wrc -- for this reason, it is like it's more generic / better maintained -- do we want eventually to phase one of them out? -- their command line arguments are incompatible. This causes problems when trying to build portable Makefiles. Should we try to be command line compatible with windres, so we are a drop in replacement (for the .rc/.res -> .o conversion)? Any windres experiences? Comments? -- Dimi.

3 4

RE: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/)
by Kye Lewis 19 Nov '02

19 Nov '02

Hi, It just seems odd, as this FTP site worked fine with internet explorer before. - no errors at all. Thanks, Kye Lewis kyethespy(a)liquid2k.com -----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin@winehq.com] On Behalf Of Keith Matthews Sent: Tuesday, November 19, 2002 8:32 PM To: wine devel < Subject: Re: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/) On Tue, 19 Nov 2002 16:29:09 +1100 "Kye Lewis" <kyethespy(a)liquid2k.com> wrote: > Hi, > > While trying to connect to the wineHQ ftp site, I am getting the > following error with IE6: > > 200 Type set to A. > 500 Illegal PORT command. > 500 LPRT not understood > Don't know about the last error, but the illegal PORT is typically seen when trying to use active FTP from behind a firewall that does not support it. Command-line MS FTP clients don't support passive mode and I have heard reports that IE does not also. If that is the problem you'll have to switch to a Linux box or find a windows FTP client that supports passive.

1 0

RE: vxdcall calling convention
by Patrik Stridvall 18 Nov '02

18 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > In any case I think Vincent and Marcus is right, it should be have a > > WINAPI like in Vincent patch because otherwise the "DWORD service" > > parameter is not popped from the stack AFAICS. > > No, it makes no difference whatsoever, the stack is restored from the > context structure in any case. Ah, OK. Wrong solution. But still, shouldn't the "DWORD service" parameter be popped somewhere? I can't see any place where it is. > The only use of WINAPI would be to make > winapi_check happy, but it would probably be better to teach it to not > do that check for register functions. VxDCall is the only register function that violates stdcall => WINAPI. But sure turning the check off in winapi_check is easy.

3 2

Wine (Debian) problems
by Anant Kabra 18 Nov '02

18 Nov '02

Hi, I've been having the following problems with wine for the last couple of days. I'm using the daily cvs snapshot builds from http://people.debian.org/~andreas/debian Here's the output (this happens with every thing that I try with wine). Any suggestions? fixme:win32:PE_CreateModule Security directory ignored err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/wine/x11drv.dll.so: undefined symbol: X11DRV_OpenGL_Init Could not load graphics driver 'x11drv' err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/wine/x11drv.dll.so: undefined symbol: X11DRV_OpenGL_Init Could not load graphics driver 'x11drv' fixme:process:CreateProcessA (X:\IXP000.TMP\ie6wzd.exe,...): NORMAL_PRIORITY_CLASS ignored err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/wine/x11drv.dll.so: undefined symbol: X11DRV_OpenGL_Init Could not load graphics driver 'x11drv' err:heap:HEAP_GetPtr Invalid heap 00000000! Wine exited with a successful status -- Anant Kabra <anant(a)yash.com>

3 2

Patch for Bug 1145 - Compile ntdll with -DSTRICT
by Andrew John Hughes 18 Nov '02

18 Nov '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Should fix all warnings - -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE92WZWSE/kMce1ABARApuoAJ49FI04qMlgt5dJvaG6ShzRdPthKACeOLmQ UhjYFSZ6RYkpCxyEzPiAG3Q= =Vykj -----END PGP SIGNATURE-----

1 0

Possibly my last question... for a while. ;-)
by Fredrick P. Lackey 18 Nov '02

18 Nov '02

Gentlemen, I feel really bad bothering a developers list with such basic questions, but. well. you all ARE the most responsive of everyone I've met so far. And, since you seem to hold the key to getting my @$$ of Micrsoshaft, then. well. I guess I'm sorry but I'm not. ;-) (By the way, if there is every anything I can do to repay you for your assistance and patience, consider it done.) As much as it pains me to ask, has anyone tried installing VMWare v3.x (either the Linux or Windows version) into Red Hat v8.0? If so, did you get it work? And, if so, then how? Again, my goal most definitely is to use Wine and Wine alone, however, I can't even consider moving forward unless I can use my environment for ALL of my current tasks (which includes development for M$, unfortunately). Thanx, either way. And, again, thank you for all of your help. R/S Fred www.fredlackey.com

2 1

RE: vxdcall calling convention
by Patrik Stridvall 18 Nov '02

18 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > However, I don't think it is enough. It will work for the > > implemented VxDCall that pops the stack itself, however it will not > > work for unimplemented VxDCalls since they will not clean up the > > stack correctly AFAICS. > > The problem is you don't know how many args to pop. In theory the name > of the function tells you that, but in practice apps don't call the > right version, and VxDCall pops the number of args the specific call > requires no matter which version of the function is called. So this is > how we do it too. Ah. Microsoft. :-( In any case I think Vincent and Marcus is right, it should be have a WINAPI like in Vincent patch because otherwise the "DWORD service" parameter is not popped from the stack AFAICS.

2 1

wine commandline options
by Rick Romero 18 Nov '02

18 Nov '02

I was playing with Pegasus Mail (silver list) to see what I could get working. It looks like it doesn't detect winsock.dll using it's own 'search algorythm, so the TCP/IP options don't get enabled - hence the (paraphrased) 'wtf?' in the silver list description. So, I tried to force Pegasus Mail to load winsock explicitly using the -Z 128 option: $wine winpm-32 -Z 128 but wine comes back with 'Unknown option -Z'. I'm not quite sure how these are getting parsed, but I see in misc/options.c parse_options() if (*p++ != '-') continue; /* not an option */ Should exit if the 2nd char isn't a - (am I right?) BUT, when parse_options returns to OPTIONS_ParseOptions() The following: /* check if any option remains */ for (i = 1; argv[i]; i++) { if (!strcmp( argv[i], "--" )) { remove_options( argv, i, 1, 0 ); break; } if (argv[i][0] == '-') { MESSAGE( "Unknown option '%s'\n\n", argv[i] ); // OPTIONS_Usage(); } } Still picks up '-' as an invalid option. My first thought would be to stop checking for options after the 1st and 2nd chars are not '-' (ie. after the Win32 program name), but I'm not sure if that's correct. Any thoughts? (FYI, no, the option didn't make Pmail work.) Rick -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

5 6

Dual boot solves everything?
by Fredrick P. Lackey 18 Nov '02

18 Nov '02

Gentlemen, First of all, thanks to everyone with your input so far. I've now been able to get IE v6.0 up and running as well as a few other less important applications. Which brings me to a few more questions. 1. Since it is possible to use native DLLs with applications, can one assume that on a dual boot machine with Win98 SE2 and Red Hat v8.0 that it would only be necessary to install the desired application under Windows, then add native DLLs to the Wine config file to get [almost] *any* Windows application to function? 2. Each time I launch a program, a black window appears that seems to make up the "shell" (for lack of a better term) for that instance of the application. This window is always somewhere around 800x600 pixels. Is there any way to not show this window and/or get the size to be something else? I am running in 1600x1200 resolution and only using half of the screen is frustrating. 3. Is there an easy way within Linux/Wine to determine what native DLLs the application should/could use? Thanx again, Fred Lackey Orlando, Florida

6 5

Progress report wine faq
by Tony Lambregts 18 Nov '02

18 Nov '02

Vincent Berone has provided me with a dsl that works on my system and I am able to build the html so that it looks like it should. link to html built from sgml: http://www.telusplanet.net/public/lambregt/index.html link to original html: http://www.dssd.ca/wine/Wine-FAQ.html Please test this with your browser and let me know of any problems. We have already tested with Mozilla (1.0 and 1.0.1) and IE 5.5 -- Tony Lambregts

3 4

Fun Projects on Slashdot
by Dimitrie O. Paun 18 Nov '02

18 Nov '02

Hehe, It's hard to keep these things 'secret' :))) http://developers.slashdot.org/developers/02/11/17/1648220.shtml?tid=125 -- Dimi.

3 3

wine-devel@winehq.com
by Mark Hannessen 18 Nov '02

18 Nov '02

> I know I sound like a broken record, but just so it's out there: > Visual Foxpro 5 and 6 IDE's DO run under Wine, BUT, left mouse clicks in > child windows are broken. I've compiled and run VFP apps under wine, > but it's a pain in the butt to go kybd only in a Visual IDE :P are you volontairing ? > Sorry not to answer your main questions, but some ideas on this ... > We use gcc, wxWindows and mingw. Not sure how much you _need_ .NET > but we migrated our (fairly complex) app from Visual C++/MFC to wxWindows > and it was definitely worth it. Also we can use gcc to cross-compile > from Linux for Windows, so basically although our software is currently used > exclusively on Windows, I can develop it all on Linux (obviously some > testing to be done on Windows as well, but basically it works). And it's all > free, open-source software. I'd recommend checking it out. this combined with mono might give you just enough to develop .NET progs under linux. Mark Hannessen

2 1

RE: vxdcall calling convention
by Patrik Stridvall 18 Nov '02

18 Nov '02

> On Mon, Nov 18, 2002 at 04:21:37PM +0100, Patrik Stridvall wrote: > > > Le lun 18/11/2002 à 02:51, Patrik Stridvall a écrit : > > > > > Corrects this line in winapi_check: > > > > > win32/device.c:544: kernel32: void > > > VxDCall(DWORD,CONTEXT86 *): calling > > > > > convention mismatch: cdecl != stdcall > > > > > > > > I'm not 100% sure this really is a bug. > > > > Don't trust winapi_check too much it is very ad hoc. :-) > > > > > > > > It might however be a bug but I never got around to test it > > > properly. > > > > > > > > So, have you verified that this really is correct? > > > > > > Well, kernel32.spec references them by "stdcall -register -i386". > > > Another API referenced the same way is CommonUnimpStub, and > > > in thunk.c, > > > it is declared as "void WINAPI". > > > > > > Is it sufficient checking? > > > > I'm not sure, it might be the other API(s) that are wrong > > or that VxDCall is a special case. That why I haven't dared > > changed anything. > > I think it needs to be WINAPI, the __wine_call_from_32_regs > assembler thunk > does not remove arguments from stack. Yes, I'm leaning in that direction as well the more I think about it. However, I don't think it is enough. It will work for the implemented VxDCall that pops the stack itself, however it will not work for unimplemented VxDCalls since they will not clean up the stack correctly AFAICS. Anyway, if so it has been wrong a long time (so long that I don't notice the warning from winapi_check any longer :-), so I wonder why it wasn't noticed by anybody else running an application using VxD calls.

2 1

RE: vxdcall calling convention
by Patrik Stridvall 18 Nov '02

18 Nov '02

> Le lun 18/11/2002 à 02:51, Patrik Stridvall a écrit : > > > Corrects this line in winapi_check: > > > win32/device.c:544: kernel32: void > VxDCall(DWORD,CONTEXT86 *): calling > > > convention mismatch: cdecl != stdcall > > > > I'm not 100% sure this really is a bug. > > Don't trust winapi_check too much it is very ad hoc. :-) > > > > It might however be a bug but I never got around to test it > properly. > > > > So, have you verified that this really is correct? > > Well, kernel32.spec references them by "stdcall -register -i386". > Another API referenced the same way is CommonUnimpStub, and > in thunk.c, > it is declared as "void WINAPI". > > Is it sufficient checking? I'm not sure, it might be the other API(s) that are wrong or that VxDCall is a special case. That why I haven't dared changed anything. The problem with VxDCall is that is have multiple entries under different external names. ./dlls/kernel/kernel32.spec: 1 stdcall -register -i386 VxDCall0(long) VxDCall ./dlls/kernel/kernel32.spec: 2 stdcall -register -i386 VxDCall1(long) VxDCall ./dlls/kernel/kernel32.spec: 3 stdcall -register -i386 VxDCall2(long) VxDCall ./dlls/kernel/kernel32.spec: 4 stdcall -register -i386 VxDCall3(long) VxDCall ./dlls/kernel/kernel32.spec: 5 stdcall -register -i386 VxDCall4(long) VxDCall /dlls/kernel/kernel32.spec: 6 stdcall -register -i386 VxDCall5(long) VxDCall ./dlls/kernel/kernel32.spec: 7 stdcall -register -i386 VxDCall6(long) VxDCall ./dlls/kernel/kernel32.spec: 8 stdcall -register -i386 VxDCall7(long) VxDCall ./dlls/kernel/kernel32.spec: 9 stdcall -register -i386 VxDCall8(long) VxDCall Searching on the Internet reveals this page: http://www.mbs.spb.ru/kb/w32mbr.htm According to this page VxDCall[0-8] really should be stdcall. ---8<--- /* Kernel32 W32-caller prototypes */ DWORD WINAPI VxDCall0(DWORD service); DWORD WINAPI VxDCall1(DWORD service, DWORD); DWORD WINAPI VxDCall2(DWORD service, DWORD, DWORD); DWORD WINAPI VxDCall3(DWORD service, DWORD, DWORD, DWORD); DWORD WINAPI VxDCall4(DWORD service, DWORD, DWORD, DWORD, DWORD); DWORD WINAPI VxDCall5(DWORD service, DWORD, DWORD, DWORD, DWORD, DWORD); DWORD WINAPI VxDCall6(DWORD service, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD); DWORD WINAPI VxDCall7(DWORD service, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD); DWORD WINAPI VxDCall8(DWORD service, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD); ---8<--- and this ---8<--- vxdcall.def LIBRARY KERNEL32 EXPORTS VxDCall0@0 @1 VxDCall1@8 @2 VxDCall2@12 @3 VxDCall3@16 @4 VxDCall4@20 @5 VxDCall5@24 @6 VxDCall6@28 @7 VxDCall7@32 @8 VxDCall8@36 @9 ---8<--- However something with VxDCall is wrong nether the less. WINAPI functions (read: __stdcall) functions expects that the callee cleans up the argument stack and the number of arguments is different depending on which function is called. Looking at VxDCall (and what it calls) in win32/device.c I see that the implemented VxDCall pops the stack. However the unimplemented VxDCalls doesn't even though they might have gotten some arguments. This means AFAICS that VxDCall corrupts the stack in such cases... So I'm pretty convinced that something is wrong however I don't think you patch is the solution to the problem. It might possible be part of a solution though... Any suggestions?

2 1

RE: vxdcall calling convention
by Patrik Stridvall 18 Nov '02

18 Nov '02

> Corrects this line in winapi_check: > win32/device.c:544: kernel32: void VxDCall(DWORD,CONTEXT86 *): calling > convention mismatch: cdecl != stdcall I'm not 100% sure this really is a bug. Don't trust winapi_check too much it is very ad hoc. :-) It might however be a bug but I never got around to test it properly. So, have you verified that this really is correct?

2 1

RE: Nameless struct problem
by Patrik Stridvall 18 Nov '02

18 Nov '02

> Dimitrie O. Paun wrote: > > >I had to use the following hack to allow this > >bit to go through my g++ compiler. > > > >I'm using RedHat 8.0, so this gives me: > > > >[dimi@dimi wine.src]$ g++ --version > >g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) > >Copyright (C) 2002 Free Software Foundation, Inc. > >This is free software; see the source for copying > conditions. There is NO > >warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > > Glad you included the warranty bit :-) > > > > >Any ideas what's wrong here, and how it can be fixed? > > > > > Not particularly, but I know I've seen other examples of g++ > being more > strict / particular > about structs than gcc. What error do you get? You could try > -E for the > preprocessor > output and search through it for DUMMYSTRUCTNAME ; it could > be being defined > earlier on or somewhere else in a way that confuses it here... DUMMYSTRUCT is defined as nothing if the compiler supports nameless structs. GNU C++ was mistakenly believed by me to support nameless structs. I didn't check however, I have check now and it seem like no version of GNU C++ does. :-( Not that it really needs to support it since you could get the same effect with "dummy" structs/classes and inheritence, but then I really can't see any particular reason not to support it since makes at least as much sense (if not more) in C++ to have unnamed structs as in C... Anyway, there is a patch in wine-patches that fixes the problem and since it as I said is always possible to "fake it" in C++ there is no great need to ask the GNU C++ developers the fix the problem either...

1 0

Re: Wine with .NET?
by Mark Hannessen 18 Nov '02

18 Nov '02

> Ladies and Gentlemen, > > I am a Microsoft developer and currently pushing the capabilities of the > .NET Framework. On that same note, I am considering moving my laptop to > some version of Linux (either Solaris v8.0 or Red Hat). I assumed that > I would need to use VMWare or some equivalent to continue using Visual > Studio .NET. Can anyone give me some advice? > > Many thanx, > Fred Lackey > Orlando, Florida have you already tryd wine to run visual studio .NET ? in theory it is possible but i don't think anyone has ever tryd. ( and it will likely not work yet, feel free to send patches ) if you want to port visual studio .NET to linux using wine you should use winemaker. Mark Hannessen

7 8

Patch for bug 1150
by Andrew John Hughes 18 Nov '02

18 Nov '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch should resolve bug 1150, compiling commdlg with -DSTRICT. Hope this is okay - this is my first time hacking on Wine. The patch is also attached to the bug. - -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE92DtTSE/kMce1ABARAgXdAJ0RKUv3appMGjMo1+TgyhyujuMzGwCdHhNc dYlWgrnc+lCHhrdfM2cwYXY= =hum9 -----END PGP SIGNATURE-----

1 0

RE: Nameless struct problem
by Patrik Stridvall 17 Nov '02

17 Nov '02

> I had to use the following hack to allow this > bit to go through my g++ compiler. > > I'm using RedHat 8.0, so this gives me: > > [dimi@dimi wine.src]$ g++ --version > g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) > Copyright (C) 2002 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > Any ideas what's wrong here, and how it can be fixed? Yes, it seems that GNU C++ 3.2 (unlike GNU C 3.2) doesn't support unnamed structs. Strange. Not that it really matters that much because you could do "magic" with inheritance in C++. See below. > Index: include/winuser.h > =================================================================== > RCS file: /var/cvs/wine/include/winuser.h,v > retrieving revision 1.152 > diff -u -r1.152 winuser.h > --- include/winuser.h 4 Nov 2002 22:47:59 -0000 1.152 > +++ include/winuser.h 17 Nov 2002 01:32:56 -0000 > @@ -2387,13 +2387,13 @@ > > typedef struct tagMONITORINFOEXA > { > - MONITORINFO DUMMYSTRUCTNAME; > + MONITORINFO DUMMYSTRUCTNAMEx; > CHAR szDevice[CCHDEVICENAME]; > } MONITORINFOEXA, *LPMONITORINFOEXA; > > typedef struct tagMONITORINFOEXW > { > - MONITORINFO DUMMYSTRUCTNAME; > + MONITORINFO DUMMYSTRUCTNAMEx; > WCHAR szDevice[CCHDEVICENAME]; > } MONITORINFOEXW, *LPMONITORINFOEXW; This uses inheritance with C++ in the Microsoft SDK. Working on patch. Coming very soon.

1 0

Nameless struct problem
by Dimitrie O. Paun 17 Nov '02

17 Nov '02

I had to use the following hack to allow this bit to go through my g++ compiler. I'm using RedHat 8.0, so this gives me: [dimi@dimi wine.src]$ g++ --version g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Any ideas what's wrong here, and how it can be fixed? Index: include/winuser.h =================================================================== RCS file: /var/cvs/wine/include/winuser.h,v retrieving revision 1.152 diff -u -r1.152 winuser.h --- include/winuser.h 4 Nov 2002 22:47:59 -0000 1.152 +++ include/winuser.h 17 Nov 2002 01:32:56 -0000 @@ -2387,13 +2387,13 @@ typedef struct tagMONITORINFOEXA { - MONITORINFO DUMMYSTRUCTNAME; + MONITORINFO DUMMYSTRUCTNAMEx; CHAR szDevice[CCHDEVICENAME]; } MONITORINFOEXA, *LPMONITORINFOEXA; typedef struct tagMONITORINFOEXW { - MONITORINFO DUMMYSTRUCTNAME; + MONITORINFO DUMMYSTRUCTNAMEx; WCHAR szDevice[CCHDEVICENAME]; } MONITORINFOEXW, *LPMONITORINFOEXW; -- Dimi.

2 1

Problem running Anstoss2 under Wine
by Adrian Bunk 17 Nov '02

17 Nov '02

I'm trying to run Anstoss2 (a five years old German soccer simulation - I'm only interested in the strategic part of the game) under Wine. I tried the Debian package of the 20021031 Release and a self-compiled package of a 20021116 CVS snapshot. The following messages occur during the start of the game: <-- snip --> $ wine anstoss2.exe fixme:file:DEVICE_Open Unknown/unsupported VxD SICE. Try setting Windows version to 'nt40' or 'win31'. fixme:file:DEVICE_Open Unknown/unsupported VxD NTICE. Try setting Windows version to 'nt40' or 'win31'. err:ntdll:RtlpWaitForCriticalSection section 0x400f10bc "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=081b1ce0 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403a7528)->(00010024,00000008) fixme:ddraw:Main_DirectDrawClipper_Initialize (0x403a7e38)->(0x403a7534,0x00000000),stub! err:msg:DispatchMessageW BeginPaint not called on WM_PAINT for hwnd 10026! err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 10026! err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 10026! fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403a7428)->(0002002d,00000008) fixme:ddraw:Main_DirectDrawClipper_Initialize (0x403ae128)->(0x403a7434,0x00000000),stub! fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now. <-- snip --> The "DEVICE_Open" messages might be related to the copy protection (?). At the beginning I see a small "Cannot open file" window [1] that seems to be non-fatal. The screenshot at [2] shows the main problem I observe: Something with the left-right justification of elements doesn't work. There are three checkbuttons and the one besides "Neues Spiel beginnen" is selected and that's the place where you can select it - but the background black circles that should indicate where you are able to click are 2cm left and a bit ahead of the correct location. The smiling ball at the right bottom is the place to click when you are finished with this page - but it's outside the rest, the thing that is painted in the two light blue colors (e.g. the "ADY" at the left bottom) is the background picture of my window manager. If there's any other information that might help simply ask. TIA Adrian [1] http://www.fs.tum.de/~bunk/TMP/cannot-open-file.png [2] http://www.fs.tum.de/~bunk/TMP/anstoss2-start.png -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed

1 0

Re: some ismbc* functions: third try
by Dmitry Timoshkov 17 Nov '02

17 Nov '02

"Greg Turner" <gmturner007(a)ameritech.net> wrote: > totally untested, but it does compile, and seems logical > enough. while i was at it, i added a few more. Probably it would be better to create a common internal function which accepts C1_???? flags, does all remaining common operations with converting character(s) to unicode and returns (ctype & flags) != 0? -- Dmitry.

2 1

Re: FAQ in sgml format
by Dimitrie O. Paun 17 Nov '02

17 Nov '02

On November 15, 2002 09:19 pm, Tony Lambregts wrote: > Here is the FAQ in sgml format with some very minor additions from the > html version by Dimitrie O. Paun, Keith Matthews and Thomas Wickline Can you please send me a copy of the file you used to generate the SGML, so I can track changes? TIA. -- Dimi.

2 1

Visual-MingW
by Dimitrie O. Paun 17 Nov '02

17 Nov '02

Just a quick heads up. I've been working on compiling Visual-MingW as a Winelib app. Hence the header patches I've sent :) I got it to compile (including resources), but it does not link. Shouldn't be too hard to do, I'll post what changes I had to do later on. -- Dimi.

1 0

RE: Wine with .NET?
by Fredrick P. Lackey 16 Nov '02

16 Nov '02

By the way, I would PREFER to use Wine and NOT VMWare. I guess I should have mentioned that. Thanx, Fred > -----Original Message----- > From: Fredrick P. Lackey > [mailto:fred.lackey@marbellasoftware.com] > Sent: Saturday, November 16, 2002 1:43 PM > To: 'wine-devel(a)winehq.com' > Subject: Wine with .NET? > Importance: High > > Ladies and Gentlemen, > > I am a Microsoft developer and currently pushing the capabilities of > the .NET Framework. On that same note, I am considering moving my > laptop to some version of Linux (either Solaris v8.0 or Red Hat). I > assumed that I would need to use VMWare or some equivalent to continue > using Visual Studio .NET. Can anyone give me some advice? > > Many thanx, > Fred Lackey > Orlando, Florida

2 1

CoInitialize
by steve.lustbader＠philips.com 16 Nov '02

16 Nov '02

One of the threads in my app calls CoInitialize, expecting it to return S_OK (in fact, it's followed by an assert statement requiring that it returns S_OK). When I run it in Wine, however, CoInitialize returns S_FALSE, implying that this thread has already initialized the COM library. Other threads call CoInitialize, but this is the first time that this thread calls it. Does Wine initialize COM differently from Windows? Are the other threads' calls to CoInitialize screwing up this thread's call? -Steve

3 2

Wine and iexplore.exe
by Luca Rosellini 16 Nov '02

16 Nov '02

Hello, I successfully run Internet Explorer 5.00 from a win98SE partition. It works smoothly on almost all sites even with those sites that use flash. Today I tryed to login to my cisco.netacad.net account using emulated wine and I had this error: fixme:file:DeviceIo_MMDEVLDR (5,(nil),0,0x483e610c,4,0x406d0268,(nil)): stub and then: err:mmsys:MMDRV_Alloc Too many open drivers I am using Wine 20021007 under slackware 8.1. Regards -- Luca Rosellini Email: luca.rosellini(a)libero.it Fax: +391786006032 PGP FP: 7711 92E2 30D2 A731 4362 4A7B 748C DF72 FE63 1C40 Registered Linux User 261056

1 0

Wine with .NET?
by Fredrick P. Lackey 16 Nov '02

16 Nov '02

Ladies and Gentlemen, I am a Microsoft developer and currently pushing the capabilities of the .NET Framework. On that same note, I am considering moving my laptop to some version of Linux (either Solaris v8.0 or Red Hat). I assumed that I would need to use VMWare or some equivalent to continue using Visual Studio .NET. Can anyone give me some advice? Many thanx, Fred Lackey Orlando, Florida

1 0

Re: Resend: implement _ismbcalpha, _ismbcalnum
by Dmitry Timoshkov 16 Nov '02

16 Nov '02

"Greg Turner" <gmturner007(a)ameritech.net> wrote: > +int _ismbcalpha(unsigned int ch) > +{ > + if (ch < 0x100) > + return ((0x41 <= ch && ch <= 0x5a) || > + (0x61 <= ch && ch <= 0x7a) || > + /* Japanese/Katakana, CP 932 */ > + (0xa6 <= ch && ch <= 0xdf)); > + else > + { > + FIXME("Handle MBC chars\n"); > + return 0; > + } > +} It's better to create a correct multibyte character pair and call GetStringType then. -- Dmitry.

3 7

RE: Stub implementation of CABINET.DLL
by Patrik Stridvall 16 Nov '02

16 Nov '02

> On Friday 15 November 2002 12:47 pm, Patrik Stridvall wrote: > > Now that we have the permission to use cabextract > > under the LGPL it would be useful to have stubs > > for CABINET.DLL so intrested people can work > > with implementing it with fewer "infrastructure" > > problems. [snip] > Anyone working on this? If not I'd be glad to take it on, > seems like it > should be easy. I personally doesn't currently have that much time to work with it. However, when I saw that not much happend despite getting code from cabextrect under LGPL I thought that perhaps people were having trouble on how to create a new DLL in Wine and how to extract the declarations from the Microsoft header without creating a derived work. I have done it many times before so thought why not do it... So I very happy that somebody is intrested in continuing. PS. If anybody have some other DLL that they wish to implement but don't now how to do it, don't hesitate to ask me to create a stub DLL with related headers.

2 1

Font selection - please review
by Shachar Shemesh 16 Nov '02

16 Nov '02

Hi all, I am thinking of submitting the attached patch. The problem is that I am not comfertable with the location I added it. As far as I could tell, there is nowhere in the whole of Wine where the selected language is matched with the charset to be used by default. This is what this patch comes to amend. There is a slight awkwardness that is inherent to the Win32 API, in which, in order to create the default font, you zero out a LOGFONT struct, fill in the struct length, and call "CreateFontIndirect". Looking at the resulting struct, however, reveals that what you have just asked for is a ANSI_CHARSET font. It appears that windows correctly understands that this is an uninitialized LOGFONT, apparently based on the fields tested. The reason I am not sure this is the correct place, however, is that there seem to be system-wide default fonts, and I'm not 100% sure why, but they are ANSI (read - latin) only. I am willing to delve deeper into that part of the code, but I need to understand it better first. I was wondering whether anyone else on this list is aware of the reasons. Shachar License: LGPL Changelog: Shachar Shemesh <winecode(a)sun.consumer.org.il> objects/font.c * Added a function to convert language to charset. * Added code to select the apropriate charset in case the charset was not specified (DEFAULT_CHARSET or uninitialized LOGFONT). Index: objects/font.c =================================================================== RCS file: /home/sun/sources/cvs/wine/objects/font.c,v retrieving revision 1.89 diff -u -r1.89 font.c --- objects/font.c 13 Nov 2002 04:13:42 -0000 1.89 +++ objects/font.c 14 Nov 2002 19:49:44 -0000 @@ -41,6 +41,8 @@ static INT FONT_GetObjectW( HGDIOBJ handle, void *obj, INT count, LPVOID buffer ); static BOOL FONT_DeleteObject( HGDIOBJ handle, void *obj ); +static BYTE FONT_GetCharsetFromLang( LANGID language ); + static const struct gdi_obj_funcs font_funcs = { FONT_SelectObject, /* pSelectObject */ @@ -317,6 +319,16 @@ { memcpy( &fontPtr->logfont, plf, sizeof(LOGFONTW) ); + /* Make sure the correct font is chosen in case the decision is up to us */ + if( plf->lfCharSet==DEFAULT_CHARSET || + (plf->lfHeight==0 && plf->lfWidth==0 && plf->lfEscapement==0 && + plf->lfCharSet==0 && plf->lfPitchAndFamily==0 && + plf->lfFaceName[0]==0) ) + { + fontPtr->logfont.lfCharSet= + FONT_GetCharsetFromLang( LANGIDFROMLCID(GetUserDefaultLCID())); + } + TRACE("(%ld %ld %ld %ld %x) %s %s %s => %04x\n", plf->lfHeight, plf->lfWidth, plf->lfEscapement, plf->lfOrientation, @@ -2207,4 +2219,69 @@ BOOL WINAPI RemoveFontResourceExW( LPCWSTR str, DWORD fl, PVOID pdv ) { return WineEngRemoveFontResourceEx(str, fl, pdv); +} + +/*********************************************************************** + * FONT_GetCharsetFromLang + */ +static BYTE FONT_GetCharsetFromLang( LANGID language ) +{ + switch( PRIMARYLANGID(language) ) + { + /* I am currently unaware of any language that requires SYMBOL + case : + return SYMBOL_CHARSET;*/ + case LANG_JAPANESE: + return SHIFTJIS_CHARSET; + case LANG_KOREAN: + return HANGEUL_CHARSET; + case LANG_CHINESE: + { + switch( SUBLANGID(language) ) + { + case SUBLANG_CHINESE_SIMPLIFIED: + return GB2312_CHARSET; + case SUBLANG_CHINESE_TRADITIONAL: + return CHINESEBIG5_CHARSET; + } + } + case LANG_GREEK: + return GREEK_CHARSET; + case LANG_TURKISH: + return TURKISH_CHARSET; + case LANG_HEBREW: + return HEBREW_CHARSET; + case LANG_ARABIC: + return ARABIC_CHARSET; + case LANG_LATVIAN: + return BALTIC_CHARSET; + case LANG_VIETNAMESE: + return VIETNAMESE_CHARSET; + case LANG_RUSSIAN: + case LANG_BULGARIAN: + /* Byelorussian probably goes under SUBLANG_RUSSIAN_MOLDAVIA */ + case LANG_MACEDONIAN: + case LANG_SERBIAN: + case LANG_UKRAINIAN: + return RUSSIAN_CHARSET; + case LANG_CZECH: + case LANG_HUNGARIAN: + case LANG_POLISH: + case LANG_ROMANIAN: + /* For some reason SERBIAN and CROATIAN has the same value, despite + * seeming to require different encodings. I disabled one at random. + case LANG_CROATIAN: */ + case LANG_SLOVAK: + case LANG_SLOVENIAN: + case LANG_SORBIAN: + return EE_CHARSET; + case LANG_THAI: + return THAI_CHARSET; + /* The JOHAB charset seem to require KOREAN as well. I don't know when + * to use that instead + case LANG_KOREAN: + return JOHAB_CHARSET; */ + } + + return ANSI_CHARSET; }

2 2

kdelnk2desktop.py
by Dustin Navea 16 Nov '02

16 Nov '02

I just switched to slackware from Mandrake8 and I was foolin around tryin to see if ther ewas an xchat built with kdelibs and stumbled across kdelnk2desktop.py in my /usr/bin dir. im not sure if it exists in other distors but it could be a replacement for the current wineshelllink on distros that do have it. Anyone wanna look into this or want me to, let me know. -Dustin

2 1

something about Chinese character processing
by yf 16 Nov '02

16 Nov '02

I found that to show Chinese character properly, following should be modified. But it only affect menu, the character within the windows still as before ( can't be showed properly). What should I do then? --- wine-20021031/graphics/x11drv/codepage.c.original 2002-11-16 13:50:31.000000000 +0800 +++ wine-20021031/graphics/x11drv/codepage.c 2002-11-04 17:44:14.000000000 +0800 @@ -279,8 +279,8 @@ { if ( IsLegalDBCSChar_cp936( *str_src, *(str_src+1) ) ) { - str2b_dst->byte1 = *str_src; - str2b_dst->byte2 = *(str_src+1); + str2b_dst->byte1 = *str_src&0x7f; + str2b_dst->byte2 = *(str_src+1)&0x7f; str_src++; } else

2 1

Re: StgIsStorageFile Try #2
by Dmitry Timoshkov 16 Nov '02

16 Nov '02

"Ryan Cumming" <ryan(a)completely.kicks-ass.org> wrote: > + strW = HEAP_strdupAtoW( GetProcessHeap(), 0, fn ); Please don't use HEAP_strdupAtoW. Use RtlCreateUnicodeStringFromAsciiz instead. -- Dmitry.

1 0

wineoss MIDI help
by Jeff Smith 16 Nov '02

16 Nov '02

I have several programs that require MIDI support. When I try to run them I get: err:midi:OSS_MidiInit ioctl on midi info for device 0 failed. This comes from line 274 of dlls/winmm/wineoss/midi.c When this error is encountered, the /dev/sequencer is closed and OSS_MidiInit returns. I have determined that my card indicates having two midi devices. Only the second supports the SNDCTL_MIDI_INFO ioctl. But midi.c never gets to the second because of the first. I have tried some simple hacks, but have not accomplished anything notable. Anybody got any insights as to a simple fix? If not, would I be better off delving into wineoss or getting the first MIDI device of the emu10k1 driver to handle MIDI_INFO? ;-) -- Jeff S _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

Re: test skeleton Re: StgIsStorageFile
by Ryan Cumming 16 Nov '02

16 Nov '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On November 15, 2002 18:06, Greg Turner wrote: > On Friday 15 November 2002 02:29 am, Ryan Cumming wrote: > > On a side note, I made a pretty nice testcase for this, but there > > seems to be no dlls/ole32/tests directory. > > Ask and ye shall receive. Cheers :) I'll get to work on porting my StgIsStorageFile testcase tommorow. - -Ryan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE91b9sLGMzRzbJfbQRAtUYAKCIbfexD39A/4raTAqrMylFuCb73gCdG4NP lDhlqa8vxpF17phsWS1mqcs= =ud+e -----END PGP SIGNATURE-----

1 0

Re: Stub implementation of CABINET.DLL
by Greg Turner 16 Nov '02

16 Nov '02

On Friday 15 November 2002 12:47 pm, Patrik Stridvall wrote: > Now that we have the permission to use cabextract > under the LGPL it would be useful to have stubs > for CABINET.DLL so intrested people can work > with implementing it with fewer "infrastructure" > problems. > > ---8<--- > > *** cabinet > > * configure.ac, > include/fci.h, > include/fdi.h, > dlls/Makefile.in, > dlls/cabinet/.cvsignore, > dlls/cabinet/Makefile.in, > dlls/cabinet/cabinet.spec, > dlls/cabinet/fci.c, > dlls/cabinet/fdi.c, > dlls/cabinet/main.c: > Added stub implementation of CABINET.DLL. Anyone working on this? If not I'd be glad to take it on, seems like it should be easy. -- gmt "War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself." -- John Stuart Mill

1 0

Re: Fw: Re: Filesystem change notifications
by Jeff Smith 15 Nov '02

15 Nov '02

> >It's not that I am for adding everything inline. That's not a good idea. >Also, I think a Windows compatibility layer can be forgiven for having more >dependancies than a personal finance program. This holds especially true if >non-core windows functionality is only available if the external library is >available at runtime (i.e. - no fribidi install - no Hebrew support in >Wine. No CUPS installed - no printing available etc.). I'm not sure this >holds true to something which is a core Windows function. > > Shachar I totally agree. And although we don't want to fall into "dependency hell", one has to consider we are trying provide a layer of compatibilty for an OS that is known for the same. So I think selective dependencies, as Shachar mentions, are perfectly reasonable. I don't mind a dependecy on FAM, but I could be biased, as I already installed it for the associated KDE functionality. If inserted as a conditional dependency, the fallback position if it is not present is no worse than the current position. Just my two centi-dollars. -- Jeff S _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

CreateWindow fails
by steve.lustbader＠philips.com 15 Nov '02

15 Nov '02

My app calls CreateWindow like this: WNDCLASSEX wcex; wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = 0; wcex.lpfnWndProc = (WNDPROC)MyWndProc; wcex.cbClsExtra = 0; wcex.cbWndExtra = 0; wcex.hInstance = hInstance; // from argument to DllMain wcex.hIcon = NULL; wcex.hCursor = NULL; wcex.hbrBackground = NULL; wcex.lpszMenuName = NULL; wcex.lpszClassName = TEXT("foo"); wcex.hIconSm = NULL; RegisterClassEx(&wcex); g_hTarget = CreateWindow(TEXT("foo"), TEXT(""), WS_POPUP, 0, 0, 0, 0, NULL, NULL, NULL, NULL); ASSERT( NULL != g_hTarget ); It fails the final assertion in Wine but not in Windows. Any idea why CreateWindow would be returning NULL here? What debug output could I provide that could be helpful here? -Steve

1 0

Re: FW: wine-devel digest, Vol 1 #1391 - 17 msgs
by Andrew Lynch 15 Nov '02

15 Nov '02

> Date: Thu, 14 Nov 2002 18:23:49 -0800 (PST) > From: Steven Edwards <steven_ed4153(a)yahoo.com> > Subject: Re: Wine Fun Projects v0.2 > To: dpaun(a)rogers.com, Wine Devel > <wine-devel(a)winehq.com> > > You might want to add visual-mingw to the winelib > apps section. One > thing I recommened to Jermey > White a while back was that WINE might gain more of > a market share if > there was a easy way for > people that are writing Windows apps on Windows if > they had a IDE for > GCC that was cross-platform. > > I was thinking at the time of something like a > CrossOver Developer > Studio or something. > > Anyway the idea is to run Visual-Mingw under WINElib > and be able to > just recompile your Win32 app > that was built with Visual-Mingw and the w32api > package plus reduce > some of the redunancy Wine, > Mingw and ReactOS have by finding areas where we are > not in sync. > > It would be a bitch and a long term project but I > think its something > to think about. > > Thanks > Steven > Visual-Mingw sounds almost identical to DevEx found at http://sourceforge.net/projects/wingtk and http://www.bloodshed.net I am using their wGLADE tool for cygwin/GTK+ development presently and it works great under Win98. Andrew Lynch PS, all of these tools are GPL __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com

2 2

Re: WWN 144
by Brian Vincent (C) 15 Nov '02

15 Nov '02

> Hmm, what is wrong with this picture? What's wrong is you posted from two different email accounts and the XML parser only matched the last one (even though you'd posted something like 25 from the other acct.) And frankly I just don't care enough to bother fixing the stat script to try to match every person who has multiple accts. A bigger issue is the parser (both on WineHQ and Kernel Traffic) doesn't seem to deal with <dl>, <dd>, <dt>, and <tt> tags so a few of the threads ended up looking like crap. And that's something I'm going to try to get fixed. -brian

1 0

WWN 144
by Dustin Navea 15 Nov '02

15 Nov '02

Hmm, what is wrong with this picture? This week, 372 posts consumed 1216 K. There were 68 different contributors. 44 (64%) posted more than once. 43 (63%) posted last week too. The top 5 posters of the week were: " /> " /> 43 posts in 117K by Dimitrie O. Paun 27 posts in 72K by Sylvain Petreolle 26 posts in 85K by Tony Lambregts 2 posts in 4K by Dustin Navea 22 posts in 51K by Alexandre Julliard Pulled up in IE 6 and it showed that, even after refreshing. -Dustin

1 0

RE: C++ tests (1/2)
by Patrik Stridvall 15 Nov '02

15 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Many normal "C" features are not commonly used either, shouldn't we > > have tests for them? > > If all the C framework could do was test the alignment of a few rarely > used structures, then it would clearly not be worth the > trouble either. Perhaps. But that is only ONE of the things we could do. Unless you have noticed the meantion examples (repeated below) contains INLINE FUNCTIONS that needs to be tested not just alignment and that sort of things. < A FEW examples of C++ only features: < 1. The D3D math classes (vector, matrices, quaternions, colors etc) in < d3dvec.inl d3dx8math.inl d3dxmath.inl < 2. The GDI+ API classes in gdiplus*.h < 3. The DAO API classes in dbdao.h < 4. STL compatible classes for accessing SAFEARRAY's in t_safevector.h

1 0

RE: C++ tests (1/2)
by Patrik Stridvall 15 Nov '02

15 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So my questions to you: > > 1. Should we support the C++ only features meantion above? > > 2. If yes, should we just include it in the tree without tests > > and just hope it works or should we have C++ tests for them? > > When someone has an app that requires these features they can > implement them, and test them by building their app. Or we can > implement them and write a small test program to test them once. The same can be said about every "C" feature as well. > No > need to build a new test environment for such uncommon features. Many normal "C" features are not commonly used either, shouldn't we have tests for them? Look, the point of tests is not testing once. It is testing for regressions when the code changes. > > I see no relevent comparsion between them: > > 1. C++ is actually used by the Microsoft SDK. Perl is not. > > 2. The Perl framework was big and required generated modules. > > The C++ framework is very small and uses the Wine header files > > as they are (or should be in order to be Microsoft compatiable) > > The issue is not really the size of the framework, it's the extra > dependencies. It would require everybody who wants to run tests to > have a working, compatible C++ installation; given the various levels > of brokenness of existing g++ versions that's far from trivial. Very true. Thanks for reminding me that it should be an optional feature. It you want to use it: ./configure --with-cxx No problem.

2 1

COM Enhancement patch
by Christian Costa 15 Nov '02

15 Nov '02

Hi all, I've sent a patch for ddraw COM management, I did not have any comments and the patch has been rejected. Could someone tell me if something is wrong or lacking? Christian. PS: I've joined a small doc that explains how to use objects with multiple interfaces. This docs is based on what has been done before with the ddraw code plus the enhancement I did. --------------------------------------------------------------------------------- - COM OBJECTS MANAGEMENT - --------------------------------------------------------------------------------- 1) Definitions: --------------- a) Object classes An object class is a structure wich defines the data of an object and all the interfaces that act on the object data Example : struct ObjectClass { INTERFACE 1; INTERFACE 2; ............ INTERFACE N; DATA; } ; typedef struct ObjectClass ObjectClass; b) Objects An object is a instance of an object class. Example : An object is created as follows : ObjectClass* object = malloc(sizeof(ObjectClass),...) c) Interfaces An interface is a way for an application to interact with an object. It contains a pointer to a virtual table plus some other data than can help objects management. An interface is a structure, which is used internally, that can be defined with the INTERFACE macro : #define INTERFACE(iface) \ struct { \ iface interface; \ /* VTABLE */ LPVOID object; \ /* pointer to the object the interface belongs to */ } To add a field to the interface, just add it in this macro. For example, we could embed the version number inside an interface or a magic number to check if the interface's pointer points to a real interface. And, off course, modify some macros or create new ones to make use of them. 2) Implementing COM objects: --------------------------- a) Declaring a COM object with multiple interfaces To declare interfaces in a COM object the ICOM_VFIELD_MULTI must be used for each interface as shown below: struct IDirect3DImpl { /* IUnknown fields */ ICOM_VFIELD_MULTI(IDirect3D); ICOM_VFIELD_MULTI(IDirect3D2); ICOM_VFIELD_MULTI(IDirect3D3); ICOM_VFIELD_MULTI(IDirect3D7); DWORD ref; /* IDirect3D fields */ IDirectDrawImpl* ddraw; LPVOID private; }; b) Creating an object Just declare an pointer to an object and allocate the memory for it. Example: IDirect3DImpl* object = malloc(sizeof(IDirect3DImpl),...) c) Initializing interfaces It is done with the ICOM_INIT_INTERFACE(object_pointer, interface_name, virtual_table) ICOM_INIT_INTERFACE(object,IDirect3D, VTABLE_IDirect3D); ICOM_INIT_INTERFACE(object,IDirect3D2,VTABLE_IDirect3D2); ICOM_INIT_INTERFACE(object,IDirect3D3,VTABLE_IDirect3D3); ICOM_INIT_INTERFACE(object,IDirect3D7,VTABLE_IDirect3D4); d) Retreive an object from within an interface's function If we consider the function : IDirect3D_AddRef(IDirect3D iface,.......) To retrieve a pointer to an object within the function, both followings macro are used : 1) ICOM_OBJECT(object_class,iface) This macro return an pointer to the object, the value is of object_class* type Example: IDirect3DImpl* d3d = ICOM_OBJECT(IDirect3DImpl,iface); 2) ICOM_THIS_OBJECT(object class,iface) It simply declares a This pointer and initialize it with the object address. IDirect3DImpl* This = ICOM_OBJECT(IDirect3DImpl,iface); e) Sharing functions between multiple interfaces In the case where a function does no have to do specific actions depending on the interface, you can share directly a function. Example : If we consider the function : IDirect3D_AddRef(IDirect3D iface,.......) The different virtual tables would be : VTABLE_IDirect3D = {......,IDirect3D_AddRef,....); VTABLE_IDirect3D2 = {......,XCAST()IDirect3D_AddRef,....); VTABLE_IDirect3D3 = {......,XCAST()IDirect3D_AddRef,....); VTABLE_IDirect3D7 = {......,XCAST()IDirect3D_AddRef,....); Note that this is possible because the ICOM_OBJECT can retreive the object's pointer without knowing the interface involved. f) Thunking interface Interface thunking enable changing from one interface to another. The following macro COM_INTERFACE_CAST(impltype, ifnamefrom, ifnameto, ifaceptr) performs this task. impltype = object class ifnamefrom = interface type we have ifnamefrom = interface type we want ifaceptr = pointer to the interface to cast return = pointer to the casted interface Interface thunking is a another way to shared a single function across different interfaces but as shown below this is required only when structures must be translated, interfaces returned casted or to handle prototype change : Example: You want to share the IDirect3D_CreateDevice across all IDirect3DX interfaces (with X above 1 because a device in Direct3D is created in a different way). IDirect3D2_CreateDevice(IDirect3D2* iface,.....) is the only one implementation of the function. The others are thunks to the IDirect3D2_CreateDevice. IDirect3D3_CreateDevice(IDirect3D3* iface, .....,LPDIRECT3DDEVICE3 *lpdevice, LPUNKNOWN lpUnk) { IDirect3DDevice3 *dev; IDirect3D_CreateDevice(ICOM_INTERFACE_CAST(IDirect3DImpl,IDirect3D2,IDirect3D3,iface),.....,&dev); *lpdevice = ICOM_INTERFACE_CAST((IDirect3DImpl,IDirect3D3,IDirect3D2,device) } IDirect3D7_CreateDevice(IDirect3D7* iface, .....,LPDIRECT3DDEVICE7 *lpdevice) { IDirect3DDevice2 *dev; IDirect3D_CreateDevice(ICOM_INTERFACE_CAST(IDirect3DImpl,IDirect3D2,IDirect3D7,iface),.....,&dev); *lpdevice = ICOM_INTERFACE_CAST((IDirect3DImpl,IDirect3D7,IDirect3D2,dev) } Here, we have to deal with a returned interface and a prototype change. The VTABLE should be: VTABLE_IDirect3D2 = {......,IDirect3D2_CreateDevice,....); VTABLE_IDirect3D3 = {......,IDirect3D3_CreateDevice,....); VTABLE_IDirect3D7 = {......,IDirect3D7_CreateDevice,....); Note that there are few functions that need this, for the others, thunks are not necessary and the way described in e) must be preferred. g) Getting an specific interface of an object With the ICOM_INTERFACE(implobj, ifacename) macro, any interfaces can be retreive from an object. implobj = pointer to the object ifacename = interface name we want return = pointer to an interface Example: IDirect3DImpl* object; ............ IDirect3D3* iface_d3d3 = ICOM_INTERFACE(object,IDirect3D3) h) Calling an COM object functions from another If a function is shared across multiple interfaces, you should write: IDirect3D3_CreateDevice(IDirect3D* iface,.....) { ICOM_THIS_OBJECT(iface); ................. IDirect3D_AddRef(ICOM_INTERFACE(This,IDirect3D),.....); ................. } If you know the nature of iface (i.e. thunking is used or the function is used in only one interface), you can write : IDirect3D3_CreateDevice(IDirect3D* iface,.....) { ICOM_THIS_OBJECT(iface); ................. IDirect3D3_AddRef(iface,.....); ................. }

6 6

Wine without any X11 environment
by Michael Riedel 15 Nov '02

15 Nov '02

Hello, is it possible to use wine in a telnet session to start a (command line) windows application? I get the error that x11drv can't connect to a display (which is correct). I'm also not very sure that the windows program itself does not perform some graphic related queries (there were some fixme messages when I tried to use 'ttydrv'). Any ideas? Is there any workaround to use a dummy display or whatever? Thanks, Michael --

3 3

Re: StgIsStorageFile
by Dmitry Timoshkov 15 Nov '02

15 Nov '02

"Ryan Cumming" <ryan(a)completely.kicks-ass.org> wrote: > On a side note, I made a pretty nice testcase for this, but there seems to be > no dlls/ole32/tests directory. Just send a file with tests to wine-patches and somebody else will make a makefile magic for you. -- Dmitry.

3 3

Re: wine/ programs/rundll32/rundll32.c dlls/kernel ...
by Martin Wilck 15 Nov '02

15 Nov '02

Am Fre, 2002-11-15 um 05.17 schrieb Alexandre Julliard: > ChangeSet ID: 6302 > Modified files: > programs/rundll32: rundll32.c > dlls/kernel : computername.c > > Log message: > Warning fixes. Your compiler seems to issue more warnings than mine :-/ It is good to see these patches are really reviewed. The lenW thingy is really embarrassing for me. Two questions/remarks: @@ -426,12 +426,13 @@ memcpy( name, buf, len ); name[len] = 0; *size = len; + ret = TRUE; This shouldn't be necessary because the whole block is executed only if ret == TRUE. } } __EXCEPT(page_fault) { SetLastError( ERROR_INVALID_PARAMETER ); - ret = FALSE; + return FALSE; } __ENDTRY What is the point of this one? (applies also to the last hunk) Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

RE: C++ tests (1/2)
by Patrik Stridvall 15 Nov '02

15 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Then of course we want normal C++ tests as well. Many (most?) > > applications likely to be ported by Winelib are C++ application > > so we really should have tests for possible C++ problems. > > The Wine tests are supposed to test the implementation, That is their primary use, yes. However I see no need to limit it to that. > not the > compilation. If some code interfaces incorrectly with Winelib, because of C++ problems or whatever, it doesn't really matter if the implementation is correct, does it? The result will still be wrong. Interface problems are inherently compilation specific. So yes, I really think we should have some tests for them. Sure I don't have much hope of catching that many bugs but then, it givens at least some confidence that the interface is reasonable bug free. > And building C++ apps with Winelib is a complex issue > that you won't be able to test in the Wine framework, except with > carefully tweaked code that won't match what real apps do anyway. > > Frankly, the likelihood of catching a real problem that way is much > too small to justify the complexity of a whole new test environment. What complexity? The patch is very small and half of it concerns the .c.cxx hack to compile tests with both with C and C++, that I can remove if you wish. Except for the file extension choping, it is possible to do with only changing "Makefile:s". Anyway if you don't accept the somewhat abstract argument above, here are some more concrete ones: How are we supposed to test specific C++ features in the Winelib header. Sure we doesn't have many yet, primarily because only C++ Winelib application needs then and we don't have any in the tree so we don't need that ourselves. But some (many?) C++ application ports from Windows certainly does. Sure we can add them to the Wine tree without any tests but if they are neither used internal nor tested they are very likely to be wrong. And yes, there are quite a lot of C++ only feature in the Microsoft SDK that are not in Wine yet. A FEW examples of C++ only features: 1. The D3D math classes (vector, matrices, quaternions, colors etc) in d3dvec.inl d3dx8math.inl d3dxmath.inl 2. The GDI+ API classes in gdiplus*.h 3. The DAO API classes in dbdao.h 4. STL compatible classes for accessing SAFEARRAY's in t_safevector.h Then of course we have COM... Sure we can test it in C to a large extent, but will it be enough? So my questions to you: 1. Should we support the C++ only features meantion above? 2. If yes, should we just include it in the tree without tests and just hope it works or should we have C++ tests for them? > We just got rid of the Perl framework, please let's not add a new one. I see no relevent comparsion between them: 1. C++ is actually used by the Microsoft SDK. Perl is not. 2. The Perl framework was big and required generated modules. The C++ framework is very small and uses the Wine header files as they are (or should be in order to be Microsoft compatiable)

2 1

Wine Fun Projects v0.2
by Dimitrie O. Paun 15 Nov '02

15 Nov '02

Folks, The second release (much expanded) of the Fun Project page has been released, in all it's glory, at: http://www.dssd.ca/wine/Wine-Fun-0.2.html The working version of the above is at: http://www.dssd.ca/wine/Wine-Fun.html By now, you should know that comments, suggestions, and flames are not only appreciated, but expected. -- Dimi.

4 6

Re: Quick question about ANSI and Unicode
by Dustin Navea 15 Nov '02

15 Nov '02

I fixed it, dang outlook defaults. Dustin ----- Original Message ----- From: "Tony Lambregts" <tony_lambregts(a)telusplanet.net> To: "Dustin Navea" <speeddymon(a)ev1.net> Sent: Friday, November 15, 2002 10:33 AM Subject: Re: Quick question about ANSI and Unicode > Dustin Navea wrote: > > > Ok, as you may have noticed Dimi sent a couple of patches that were > > supposed to fix Treeview Notifies a couple of weeks back. They didnt > > exactly work, but its not that the code he submitted didnt help. > > Basically when running the StarCraft installer in wine, it attempts to > > display the treeview-based directory listing in unicode which isnt > > supported by that installer, and so it ends up not showing anything. > > I was wondering if anyone thinks that the fact that my TextCP=0 in the > > wine config file has anything to do with it. I'm thinking that if I > > set it to TextCP=1252 or TextCP=437 then it will work as expected, but > > I have no way of testing this until tonight, as I'm not on a Linux box > > right now, being at work and all. Just thought I would check with > > everyone and see what they thought. > > > > Comments appreciated. > > > > I am sorry I can't help with the codepage thing. However, I am sure > that you didn't mean to, but you sent this in html format, and you know > this list is text only... Do you need some help with setting up outlook > to send text only? > > -- > > Tony Lambregts > > > >

1 0

RE: Wine without any X11 environment
by Patrik Stridvall 15 Nov '02

15 Nov '02

> is it possible to use wine in a telnet session to start a > (command line) > windows application? Yes. > I get the error that x11drv can't connect to a > display (which is correct). I'm also not very sure that the windows > program itself does not perform some graphic related queries (there were > some fixme messages when I tried to use 'ttydrv'). If the application directly or indirectly loads GDI32.DLL or USER32.DLL it also load the x11drv with the result above if DISPLAY isn't set. > Any ideas? Is there any workaround to use a dummy display or whatever? In addition to the ttydrv (as you meantion above) you can use VNC like: vncserver :1 export DISPLAY=:1

1 0

Adding -lc when linking?
by Gerald Pfeifer 15 Nov '02

15 Nov '02

When compiling Wine on FreeBSD, there are tons of warnings of the following kind (and have been that way since I can remember) which regularily cause confusion and support requests by people building our port: /usr/bin/gcc -shared -Wl,-Bsymbolic glu32.spec.o glu.o glu32.dll.dbg.o -o glu32.dll.so -L../../dlls -L../../library -lwine -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -lm /usr/lib/libgcc.a(_op_vdel.o): In function `__builtin_vec_delete':_op_vdel.o(.text+0x45): undefined reference to `free' /usr/lib/libgcc.a(_op_delete.o): In function `__builtin_delete':_op_delete.o(.text+0x45): undefined reference to `free' /usr/lib/libgcc.a(_op_new.o): In function `__builtin_new':_op_new.o(.text+0x1aa): undefined reference to `malloc' /usr/lib/libgcc.a(exception.o): In function `__eh_alloc': exception.o(.text+0xa5): undefined reference to `malloc' /usr/lib/libgcc.a(exception.o): In function `__eh_free': exception.o(.text+0xc9): undefined reference to `free' /usr/lib/libgcc.a(tinfo2.o): In function `type_info::before(type_info const &) const': tinfo2.o(.text+0x14): undefined reference to `strcmp' Alfred (Cc:ed) verified that these warnings can be eliminated by o getting rid of the -Wl,-Bsymbolic option (which you probably want to keep to actually get warnings linking symbols are hosed), or o explicitly adding -lc. Would you mind making one of these changes (neither should break GNU/Linux)? If not, how should this problem be addressed? Gerald PS: Please Cc: Alfred and me when replying, as we are not on this list. -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0

Quick question about ANSI and Unicode
by Dustin Navea 15 Nov '02

15 Nov '02

Ok, as you may have noticed Dimi sent a couple of patches that were supposed to fix Treeview Notifies a couple of weeks back. They didnt exactly work, but its not that the code he submitted didnt help. Basically when running the StarCraft installer in wine, it attempts to display the treeview-based directory listing in unicode which isnt supported by that installer, and so it ends up not showing anything. I was wondering if anyone thinks that the fact that my TextCP=0 in the wine config file has anything to do with it. I'm thinking that if I set it to TextCP=1252 or TextCP=437 then it will work as expected, but I have no way of testing this until tonight, as I'm not on a Linux box right now, being at work and all. Just thought I would check with everyone and see what they thought. Comments appreciated. -Dustin

1 0

Re: rpc_J_PL0-r1
by Greg Turner 15 Nov '02

15 Nov '02

On Friday 15 November 2002 07:42 am, Greg Turner wrote: > This is basically just a resend of the old rpc_J_PL0 patch, but fixed > to go in cleanly against the current CVS, since rundll32 (trivially) > broke my old patch. oops: +++ ./programs/Makefile.in 2002-11-15 07:29:36.000000000 -0600 @@ -57,6 +58,8 @@ progman \ regedit \ regsvr32 \ + rpcss \ + rpcss \ uninstaller \ wcmd \ wineconsole \ I'll save you all the bandwith of fixing this.... -- gmt "War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself." -- John Stuart Mill

1 0

something with Chinese character processing
by yf 15 Nov '02

15 Nov '02

I found that to show Chinese character properly. Following should be modified: in wine-2002????/graphics/x11drv/codepage.c static Xchar2b *X11DRV_unicode_to_char2b_cp936(fontObject *pfo, LPCWSTR lpwstr, UINT count) { ... for(i=0; i<count; i++, str_src++, str2b_dsg++) { if(IsLegalDBCSChar_cp936(*str_src, *(str_src+1))) { // modified begin ===> str2b_dst->byte1=*str_src&0x7f; str2b_dst->byte2=*(str_src+1)&0x7f; str_src++; // <=== modified end } else ... } ... } But there still some character can't be properly showed. Where I lost should be modified, please tell me. Best regards. /yf

1 0

something with Chinese character processing
by yf 15 Nov '02

15 Nov '02

I found that to show Chinese character properly. Following should be modified: in wine-2002????/graphics/x11drv/codepage.c static Xchar2b *X11DRV_unicode_to_char2b_cp936(fontObject *pfo, LPCWSTR lpwstr, UINT count) { ... for(i=0; i<count; i++, str_src++, str2b_dsg++) { if(IsLegalDBCSChar_cp936(*str_src, *(str_src+1))) { // modified begin ===> str2b_dst->byte1=*str_src&0x7f; str2b_dst->byte2=*(str_src+1)&0x7f; str_src++; // <=== modified end } else ... } ... } But there still some character can't be properly showed. Where I lost should be modified, please tell me. Best regards. /yf

1 0

Another msvcrt replacement
by Fabian Cenedese 15 Nov '02

15 Nov '02

Hi Looks like wine is not the only one in need of MS replacements. They're only at version 0.0.1 but maybe they have something wine could use or wine sure has something they could use... http://mingwacr.sourceforge.net/ bye Fabi

1 0

Wine Time Line
by Thomas Wickline 15 Nov '02

15 Nov '02

Hi, I have been looking over the FAQ and we have a question in the FAQ " What is the History of Wine" And after talking with Dimi Paun I would like to expand this to a " Wine Time Line" page that could be updated a couple times a year. This would give users info about wine's progression & events that took place over the years. Here is a draft of the first year 1993/1994..... Done by _Robert Amstadt_ -- A discussion began on USENET about the feasibility of running Windows apps on Linux. There were some people that said that it is impossible. This didn't sit well with Robert Amstadt so he began work to prove them wrong. He started out by writing a program loader for Win3.1 apps. Alexandre Julliard merged windowing functions written by Peter MacDonald in Tcl/Tk to the program loader written by Robert. Alexandre soon after rewrote everything to eliminate the Tcl/Tk in favor of direct calls to Xlib. Eric Youngdale also contributed early in many areas including improvements to the program loader. The very first Wine mailing list was operated by Robert to allow discussions between developers. After a year with many successes and growing interest in the project we asked for the creation of the newsgroup comp.emulators.ms-windows.wine. The vote was overwhelmingly in favor of its creation. Around the same time, Robert was asked to give a presentation about Wine at the first Linux Congress in Heidelberg, Germany. The room was packed. Interest in Wine was very high. During the first year of development, most of the code was written by Alexandre Julliard and Robert Amstadt. However, we have always received contributions of code from many people. Life got busy for Robert and he stepped down as head of the project and let Alexandre take control. It was probably sometime during the second year. -- Thoughts, Volinteers, Flames are most welcome.. Thomas

3 2

RE: C++ tests (1/2)
by Patrik Stridvall 15 Nov '02

15 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > In the case of generated.c it is very useful since > > alignment and that sort of thing might pontially be different > > with C++. For other normal tests I'm not sure how useful > > it is to tests with C++ as well. It can't hurt of course > > but then it takes twice as long to run... > > I don't see what this buys us at all. If the C++ compiler generates > different structure layouts from the same headers then it is broken, > but that's not really a Wine problem. First of all it was just an example what it could be used for. It is the only thing that winapi_test (tests/generated.c) currently tests for. However, there will be more tests in the future testing for other things that might or might not be C++ dependent. Secondly the test makes certain that you don't have a #ifdef __cplusplus affecting some structure by mistake. And yes, there are structure like that MONITORINFO that does. And no, don't look in the Wine source, it doesn't implement it yet. Then we could have #ifdef __cplusplus that have an "missing" #endif that matches some other #endif in the wrong place or something. We also have the COM interfaces that are different in C++... Then of course we want normal C++ tests as well. Many (most?) applications likely to be ported by Winelib are C++ application so we really should have tests for possible C++ problems. But it you don't like the .c.cxx hack I could generate C++ tests to a generated_cxx.cxx or whatever then we don't need that part of the patch. It is a little ugly I admit. :-)

2 1

Re: C++ tests (1/2)
by Alexandre Julliard 14 Nov '02

14 Nov '02

Patrik Stridvall <ps(a)leissner.se> writes: > In the case of generated.c it is very useful since > alignment and that sort of thing might pontially be different > with C++. For other normal tests I'm not sure how useful > it is to tests with C++ as well. It can't hurt of course > but then it takes twice as long to run... I don't see what this buys us at all. If the C++ compiler generates different structure layouts from the same headers then it is broken, but that's not really a Wine problem. -- Alexandre Julliard julliard(a)winehq.com

1 0

dsl file for sgml faq
by Vincent Béron 14 Nov '02

14 Nov '02

Finally, it's done. In the attached archive you'll find the following files: wine-faq.sgml -> Main sgml file faq-0.sgml \ faq-1.sgml |-> Content sgml files faq-2.sgml / faq.css -> CSS file for the FAQ index.html -> The output of docbook2html -d faq.dsl wine-faq.sgml authors.ent -> same as in documentation/, wasn't needed actually. faq.dsl -> Definition file for docbook. This is where the work went. I modify a few docbook definitions to match Dimitrie's layout. Not obvious without knowing LISP beforehand :) Of course, if somebody chooses another layout, some of this will need adjustment. Or if we prefer something closer to "vanilla" docbook. Dimitrie, the actual HTML code is rather ugly in it's source presentation, so don't hand-edit it :P Anyway, it's not meant to be hand-edited, that's what sgml and docbook are for. The layout is exactly what you already have, although with some small modifications to the layout the dsl file can be alot simpler. Tony, you can begin the transition if Dimitrie likes it (and when you have the time to). That's all for tonight. Vincent

3 7

Re: ReadFile speedup
by Hannu Kotipalo 14 Nov '02

14 Nov '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hannu Kotipalo kirjoitti Sunnuntai 10. Marraskuuta 2002 14:49: > are speeded up a lot. For example, wzebra opening database readout : > > Before : over 700 seconds > After : 12-13 seconds > A new version, replacing the earlier. I tested this with a few applications, looks like for most of applications this has not much effect. However, wzebra proves that the effect can be enourmous on some. (And Simcity tellls that it can be negative on some applications :-( Changelog: - - This patch speeds up applications reading files by small packets - - 4 static 512 byte buffers (can be defined for n * n buffers, see file.c) - - Buffer invalidation mechanism changed. With several buffers this *should* fix the reported (thans to Tony Lambregts) slowdown on SIMCITY2000. I haven't got it, cannot test. Please test and see -debugmsg +file, it can give a hint about needed buffers and their sizes. diff is made by 'diff -urN wine-20021031/ wine-20021031-patched/ > patch.diff' Hannu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE90XAUuA3ghgc3fUsRAuk7AKDwLK/E4WzkCHMf0j615aktFuiWEgCgt0xq FLujbIUEEASUu9K51siPOwA= =RxKU -----END PGP SIGNATURE-----

3 4

Re: dsl file for sgml faq
by Tony Lambregts 14 Nov '02

14 Nov '02

Vincent Béron wrote: > Tony Lambregts a écrit: > >> Vincent Béron wrote: >> >>> Tony Lambregts a écrit: >>> >>>> I have been fighting with trying to get your sample built on my >>>> system. The end point for me seems to be that in order to use your >>>> faq.dsl I need docbook DTD 4.2. RedHat 7.2 has Docbook 3.0 through >>>> 4.1 but 4.1 just does not cut it. >>>> >>>> jade:../faq.dsl:50:24:E: reference to undefined variable >>>> "$generate-article-lot-list$" >>>> >>>> The sgml tools site has only 3.0/2 >>>> >>>> So I feel very THICK and ned some enlightenment on what direction >>>> to take either. >>>> >>>> 1) It seems pointless to rely on something (docBook 4.2 DTD) that >>>> is difficult to get, so no one will use it so, no one will maintain >>>> the FAQ. >>> >>> >>> >>> >>> Silly me, not thinking about others. It runs fine with docbook 3.1 >>> (modify the doctype at top of wine-faq.sgml) if you remove the >>> articleinfo pair (but you can keep the title). >>> >>>> >>>> 2) I am THICK and I it will be quickly apparent what I should do >>>> once I have more informatioin. >>>> >>> >>> You're NOT thick! It's just that I do things here (on my machine), >>> and I don't always check if it would work on other machines. >>> >>> Vincent >>> >> When I made the suggested changes I still get the same error... >> >> [tony@tony documentation]$ db2html -d ../faq.dsl wine-faq.sgml >> output is wine-faq >> Using catalogs: /etc/sgml/sgml-docbook-3.1.cat >> Using stylesheet: ../faq.dsl >> Working on: /usr/local/src/wine/documentation/wine-faq.sgml >> jade:../faq.dsl:50:24:E: reference to undefined variable >> "$generate-article-lot-list$" > > > Ok, it's the definition of the article element which causes problems. > > What is your dsssl-stylesheets version? You can locate db31.dsl and > look in the parents directory name. dsssl-stylesheets-1.64 > > > I needed to copy some definitions (bad thing to do, as your > experiencing shows) to precisely control the HTML layout. > > Try with the enclosed dsl file (warning: endlines are probably MS), > and compare the differences (if it works ;-)). Then tell me which > differences you absolutely need, or want, and I'll try to get them in > a portable way. > > Vincent I had to modify the faq-plain.dsl a little to get output >------------------------------------------------------------------------ > ><!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [ ><!ENTITY walsh-style PUBLIC "-//Norman Walsh//DOCUMENT DocBook HTML Stylesheet// ><!ENTITY cygnus-style SYSTEM "/usr/lib/sgml/stylesheet/dsssl/docbook/cygnus/cygn >]> > > <!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [ <!ENTITY walsh-style PUBLIC "-//Norman Walsh//DOCUMENT DocBook HTML Stylesheet//EN" CDATA DSSSL> <!ENTITY cygnus-style SYSTEM "/usr/lib/sgml/stylesheet/dsssl/docbook/cygnus/cygnus-both.dsl" CDATA DSSSL> ]> ><style-sheet> ><style-specification id="html" use="docbook"> ><style-specification-body> > >(define %html-pubid% "-//W3C//DTD HTML 4.01 Transitional//EN") >(define %html-header-tags% '(("META" ("HTTP-EQUIV" "Content-Type") ("CONTENT" "t > (define %html-header-tags% '(("META" ("HTTP-EQUIV" "Content-Type") ("CONTENT" "text/html; charset=ISO-8859-1")))) >(define %use-id-as-filename% #t) >(define %html-ext% ".html") > >(define %stylesheet% "faq.css") >(define %stylesheet-type% "text/css") > ></style-specification-body> ></style-specification> > ><external-specification id="docbook" document="walsh-style"> > ></style-sheet> > > With those changes I get output (but not the prety stuff ) <grin> -- Tony Lambregts

1 0

Re: Fw: Re: Filesystem change notifications
by Ian Pilcher 14 Nov '02

14 Nov '02

Shachar Shemesh wrote: > It's not that I am for adding everything inline. That's not a good idea. > Also, I think a Windows compatibility layer can be forgiven for having > more dependancies than a personal finance program. This holds especially > true if non-core windows functionality is only available if the external > library is available at runtime (i.e. - no fribidi install - no Hebrew > support in Wine. No CUPS installed - no printing available etc.). I'm > not sure this holds true to something which is a core Windows function. That would be the plan. No FAM header at compile time, no change notification support (i.e. current behavior); can't load FAM library or connect to FAM daemon at runtime, no change notification support. -- ======================================================================== Ian Pilcher pilchman(a)attbi.com ========================================================================

2 1

Re: Fw: Re: Filesystem change notifications
by Havoc Pennington 14 Nov '02

14 Nov '02

On Thu, Nov 14, 2002 at 07:04:24AM +0000, Keith Matthews wrote: > It sems to have been dropped in RH 7.3 which is a good thing. > No, it's not dropped. > Fam requires portmapper. If not set up properly (i.e. by someone who > understands what they are letting loose) portmapper can be a serious > security problem. The security community regard the introduction of fam > a serious backward step on RH's part. Sounds like someone is misinformed, because we don't have it listening on external ports. That's only required to make it work over NFS or something. Our FAM is a local-only thing unlike on Irix. > You are also assuming that every distro follows RH's lead which is very > definitely not true. Many people are already getting upset about the > number of libraries that are required to get some packages to run. > GNUCash being a prime example of package use gone mad. GNUCash has something like 40 dependencies including a lot of very unstable/unfinished APIs. FAM is 1 dependency and while it sucks, it doesn't change very often (or at all that I know of). Alex Larsson wanted to work on a nicer FAM-type thing based on a per-user daemon or something, but hasn't had time. Certainly there's room to write such a thing, but I don't think it's harmful to use FAM if FAM is present. It's not like a FAM dependency would be pervasive, it would be small and well-isolated and easy to change to some other dependency if you found something better. Havoc

2 1

Re: Filesystem change notifications
by Ender 14 Nov '02

14 Nov '02

It all depends which platforms you want to support in this patch, as far as it goes. FAM has support for a lot of different systems, but there's no need to really add it as a dependency IMHO. Adding support for the platforms we wish to support would be simpler. I think the best reference would be to use F_NOTIFY under Linux. This makes writing FindFirstChangeNotification a maybe 20 minute job. The simplest example I can think of is from Samba: http://cvs.samba.org/cgi-bin/cvsweb/~checkout~/samba/source/smbd/notify_ker… It's GPLed, so only use it as an example, don't copy code from it :) Other platforms have other methods (eg, FreeBSD you can use kqueue/kevent).. so yes, it all depends how much compatability you want. On other platforms you can always resort to polling, but this is quite horrible. I think NetBSD has a kqueue/kevent method, but IIRC it's broken. :) - Ender

2 1

Unknown message 0x0313
by Fabian Cenedese 14 Nov '02

14 Nov '02

Hi While trying to find problems with messages I stumbled over a message I didn't know what it is. My app got a message 0x0313 when I right clicked on the app button in the taskbar, that on my old NT4. The only info I found is that the app should show the system menu like in this example: // With ClassWizard OnRButtonDown () addition Void Cxxxx: OnRButtonDown (UINT nFlags, Cpoint point) { // Client coordinate in screen coordinate conversion ClientToScreen (& point); // Indication of system menu PostMessage (0x0313, 0, MAKELPARAM (point.x and point.y)); Cwnd: OnRButtonDown (nFlags and point); } Is this code defined in the new VS.net? Thanks bye Fabi

1 0

Filesystem change notifications
by Ian Pilcher 14 Nov '02

14 Nov '02

Is anyone working on implementing FindFirstChangeNotification and friends? If not, this looks like something that may be both within my capabilities and non-trivial enough to be useful (a rare combination!). My thought is to use SGI FAM (http://oss.sgi.com/projects/fam/), which is shipped with Red Hat and (according to bug #588) Mandrake. I'm not sure about any other distributions, but the FAQ on the web page states that Enlightenment, GNOME, and KDE all use it, so it should be pretty widespread. If no one is working on this, start preparing for an endless series of questions about the wineserver's internal workings. -- ======================================================================== Ian Pilcher pilchman(a)attbi.com ========================================================================

3 4

Wine 0.9 TODO v0.5
by Dimitrie O. Paun 14 Nov '02

14 Nov '02

Folks, A new version (0.5) of the Wine 0.9 TODO is out: http://www.dssd.ca/wine/Wine-0.9-TODO-0.5.html The work-in-progress one is always available at: http://www.dssd.ca/wine/Wine-0.9-TODO.html Please check it out, and help me keep it up-to-date. :) Again, for you convenience, the TODO is included below, in text form: A. WineHQ work 1. Website redesign [IN PROGRESS] * worker: Jeremy Newman * status: backend is getting finalized * updated: Nov 7, 2002 2. Move the doc scripts out of documentation into the tools CVS module [TODO] * worker: Jeremy Newman * status: should remind Jeremy to do it :) * updated: Nov 7, 2002 3. Reorganize the navigational menu [DONE] * worker: Francois Gouget & al. * status: merged into new site * updated: Nov 5, 2002 4. Create some really sexy screenshots [IN PROGRESS] * worker: Brian Vincent * status: please send screenshots to the above mentioned maintainer * updated: Nov 12, 2002 * criteria: listed here 5. Rework the FAQ interface [IN PROGRESS] * workers: Dimitrie O. Paun, Keith Matthews, Thomas Wickline * status: released for public review here * updated: Nov 9, 2002 6. Enlist some 'official' distribution maintainers [DONE] * RedHat: Vincent Béron * SUSE: Marcus Meissner * Mandrake: Kye Lewis * Debian: Ove Kaaven * FreeBSD: Gerald Pfeifer * status: completed * updated: Nov 7, 2002 7. Create nice page with apps that run virtually flawless [IN PROGRESS] * workers: Carlos Lozano, Dustin Navea * status: list submitted for discussion, and partly posted here as a HTML page. * updated: Nov 13, 2002 * criteria: not MS dlls required, no tricks, etc. B. Documentation work 1. Fix incomplete and/or out of date documentation. [IN PROGRESS] * workers: Dustin Navea, Tony Lambregts * status: 7.5% complete (first round of patches committed, help would be appreciated) * updated: Nov 12, 2002 2. Fix documentation build process [IN PROGRESS] * worker: Vincent Beron * status: patch submitted * updated: Nov 10, 2002 3. Move CVS docu from User Guide to Devel Guide [IN PROGRESS] * worker: Bill Medland * status: just started * updated: Nov 7, 2002 4. Merge documentation/wine.texinfo into the Development Guide [TODO] 5. Merge documentation/HOWTO-winelib into the Development Guide [TODO] 6. Do something about documentation/installation-und-konfiguration.german [TODO] 7. Do something about documentation/shell32 [TODO] 8. Do something about documentation/status [TODO] C. Wine configuration 1. Merge configuration into the registry [TODO] 2. Write control panel applets for editing it [IN PROGRESS] * worker: Jaco Greeff * status: 7.5% (screenshots here, and here) * updated: Nov 11, 2002 3. Have decent defaults so we can start control panel without prior configuration [TODO] 4. Have wizard like app to autoconfigure wine [TODO] * proposal: WineSetupTk by Jeremy White 5. Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg [TODO] 6. Write wine.inf script to setup a new Wine installation [TODO] 7. Have a wineboot script for RunOnce stuff [IN PROGRESS] * workers: Andreas Mohr, Shachar Shemesh * status: 50% * updated: Nov 7, 2002 D. Stabilize utilities 1. Get rid of the init directive from .spec files [DONE] * worker: Alexandre Julliard * status: implemented by this * updated: Nov 7, 2002 2. Make sure the .spec file format is fairly stable [IN PROGRESS] * worker: Alexandre Julliard * status: Yes, I'll do that. * updated: Nov 7, 2002 * what: can we get rid of the rsrc directive? 3. Ensure the various utilities' options are stable [IN PROGRESS] * status: Alexandre fixed winebuild options * updated: Nov 7, 2002 * what: audit the other utilites 4. Get rid of the Perl testing framework [DONE] * worker: Dimitrie O. Paun * status: patch submitted, and committed ([1], and [2]) * updated: Nov 11, 2002 E. Important fixes 1. Window management rewrite, so we can install apps in managed mode. [TODO] * worker: Alexandre Julliard * status: not started 2. Finish DLL separation Phase 1 [IN PROGRESS] * worker: ? * status: deferred * updated: Nov 11, 2002 * criteria: DLLs should use only functions exported through .spec file. 3. Detect printing system at runtime [TODO] * worker: Huw Davies * status: Yup, I'm going to do this in the near future. * updated: Nov 7, 2002 4. Detect OpenGL system at runtime [IN PROGRESS] * worker: Lionel Ulmer * status: Patch submitted for review. * updated: Nov 9, 2002 5. Start builtin WinHelp when invoked from apps [DONE] * worker: Eric Pouech * status: patches submitted (client, server) for review, and accepted. * updated: Nov 11, 2002 6. Add macro support to the builin WinHelp [IN PROGRESS] * worker: Eric Pouech * status: Patch submitted for review. * updated: Nov 14, 2002 7. Add CHM support to builtin WinHelp [IN PROGRESS] * worker: J.Brown (Ender/Amigo) * status: Cabextract, and CHMtools donated to Wine * updated: Nov 11, 2002 8. Good support for VisualBasic apps [TODO] * worker: ? * status: ? * updated: Nov 9, 2002 * tests: submitted by Roderick Colenbrander -- Dimi.

1 0

Re: wine/dlls/ntdll debugtools.c
by Dimitrie O. Paun 13 Nov '02

13 Nov '02

On November 13, 2002 02:38 pm, Alexandre Julliard wrote: > Reduce the maximum length of debug strings to 80 characters. Why do that? My console has >140 columns, 80 is rather small. -- Dimi.

2 4

Wine, bugs and Word2k ...
by Paul Millar 13 Nov '02

13 Nov '02

Hi, I've been trying out wine with Word 2000 using builtin DLLs, both in desktop and managed mode. Mostly it works fine, but there's a few problems that detract from the "user experience". Any pointers on where to start looking for these bugs would be much appreciated -- relay is around 46 MiB before any of the problems surface :^/ 1. Whenever word decides to run their help agent, on my machine C:\WINDOWS\Msagent\AGENTSVR.EXE, I get messages: fixme:hook:NotifyWinEvent( 4, <HWND 1>, -3, 0)-stub! fixme:hook:NotifyWinEvent( 5, <HWND 1>, -3, 0)-stub! fixme:hook:NotifyWinEvent( 32773, <HWND 2>, -4, 0)-stub! Word and the agent then freezes. Killing off the agent, e.g. "kill $(ps ax|grep wine.*AGEN|awk '{print $1}')" allows word to recover ... 2. Dragging a dialogue box around causes a corruption on the screen (see [1]). When I release the button, the window moves, along with any corruption. Forcing a refresh (eg hiding the desktop window behind another one), clears up the corruption. 3. Normal resizing works fine, but word has an extra resizable corner (which isn't rendered correctly under wine, see [2]). This has had variable success in the past: when it fails, the window is resized so the left edge of the window shoots off the left edge of the screen, seemingly ignoring whatever the mouse does. With current CVS it seems to always fail in this way. 4. Exiting word, it tries to save NORMAL.DOT, saying "The disk is full or too many files are open. C:\windows\...\Templates\Normal.dot" causing: fixme:storage:StorageImpl_Commit (4): stub! fixme:storage:StorageImpl_Commit (4): stub! fixme:storage:StorageImpl_Commit (4): stub! fixme:ole:WriteFmtUserTypeStg (0x402b5550,17c,L"Microsoft Word Document") stub! fixme:hook:NotifyWinEvent (32774,0x00030031,52,3)-stub! fixme:hook:NotifyWinEvent (32773,0x00030031,-4,33)-stub! fixme:hook:NotifyWinEvent (32774,0x00030031,26,7)-stub! fixme:hook:NotifyWinEvent (32777,0x00030031,52,0)-stub! fixme:hook:NotifyWinEvent (32774,0x00030031,52,3)-stub! So I guess the storage is at fault. 5. Exiting Word causes wine to crash. This used to work ok (upto a few days ago). Backtrace shows a few random references to _end+0xd27f0 (etc..), followed by PE_InitDLL (pe_image.c:628 nt=1, module=1140195328, type=0, lpReserved=0x01), followed by module.c:159 .... seems to be trying to initialise winmm.dll, failing and jumping into blue yonder. On a whim, I reversed Eric's recent always-unload-winmm patch [3]. This "fixed" the problem. So, is wine attempting (and failing) to load winmm in order to unload it? (6. The debugger froze whilst trying to dereference the wm pointer in MODULE_InitDLL, it managed to print some of the structure before hanging ... but I think that's enough bugs for now ...) Cheers, Paul. [1] - http://www.astro.gla.ac.uk/users/paulm/corner.png [2] - http://www.astro.gla.ac.uk/users/paulm/corrupt.png [3] - http://cvs.winehq.com/patch.py?id=6212 ---- Paul Millar

3 6

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