- Wine-Devel - list.winehq.org

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

Nov. 23, 2002

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 Nov. 23, 2002

Nov. 23, 2002

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 Nov. 23, 2002

Nov. 23, 2002

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 Nov. 22, 2002

Nov. 22, 2002

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 Nov. 22, 2002

Nov. 22, 2002

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 Nov. 22, 2002

Nov. 22, 2002

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 Nov. 22, 2002

Nov. 22, 2002

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 Nov. 22, 2002

Nov. 22, 2002

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 Nov. 22, 2002

Nov. 22, 2002

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 Nov. 22, 2002

Nov. 22, 2002

>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