- Wine-Devel - list.winehq.org

winspool.drv again
by Dimitrie O. Paun Nov. 22, 2002

Nov. 22, 2002

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

Nov. 22, 2002

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

Nov. 22, 2002

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

Nov. 22, 2002

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

Nov. 22, 2002

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

Nov. 22, 2002

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

Nov. 22, 2002

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

Nov. 22, 2002

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

Nov. 21, 2002

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

Nov. 21, 2002

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