February 2003 - Wine-devel - list.winehq.org

Wine default install queries - Wine 20030115
by J. Grant 01 Mar '03

01 Mar '03

Hi, Is there a reason e:\test is in the default path when I install from CVS? (this dir does not exist) There is no windows version defined in the [Version] block, should a windows version be defined to use as default? Drive F: was setup as CDROM, even though the ./tools/wineinstall said it could not find the CDROM during the process I think. Checking fstab for "cdrom" would determine the cdrom drive(s) on most computers. [Drive C] was setup as type "win95", however its had label "MS-DOS", I think this would be better as "wine" by default, could this be considered please? Regards JG

3 9

Re: more direct sound capture fixes
by Robert Reif 01 Mar '03

01 Mar '03

Thanks for the feedback. I know the debugging code is getting out of hand but what is the recommended way of providing useable traces. Should the debug code be put in a separate file? Are there standard routines for converting constants to readable strings? I'm new to wine so I don't know what the current practices are yet. The critical section was put in there because there is the potential of accessing that variable from all three threads. It's overkill now and probably not needed but I'm trying to track down some weird behavior in full duplex mode. That variable stores the state of both the read and write threads so we need to do bit opps on it. The current behavior of the driver reorders commands by placing ones that must be waited on at the head of the queue. Not sure why but I added that #define to allow it to be disabled. It makes the capture code more stable and deterministic. It defaults to the current behavior. I was running into under run problems in the capture thread where it had data to save but no headers to put it in. The headers were in the queue but ignored until after the timeout period. I added code to peek into the queue rather than giving up and it fixed the under run problem. I'm also having problems with the mixer and primary buffers and am trying to figure them out but I suspect a similar problem. The OSS people don't recommend using multiple threads for reading and writing. Three are currently used: the main app thread where the sound device is opened, one for writing and one for reading. Could this have something to do with my full duplex problems? audio.c is getting big with both input and output and wave and direct sound all together. Do we want to break it up someday? What about hardware mixing? Is anyone working on redesigning this? My needs are short term. I need to get my app working under wine right now but I would like to see direct sound audio better integrated someday and am willing to help. Thanks, Bob. Eric Pouech wrote: > > wineoss.diff: > > Added more debugging code. > it really starts being ugly and inefficient > > Started work on direct sound capture driver. > > Tried to get wave driver to work better in full duplex mode. > > Capture works but playback has problems. > just a few questions: > - I don't think you need the enable_crst, do you ? I don't think the > ioctl will be done in parallel anyway > - why do you need to change the message order ? you'd better in wave > capture, when you run out of waveheaders try to process the pending > messages (as we do in wave playback) before sending back an error, > without reordering them > > A+ > > -- > Eric Pouech

2 1

Report after porting a windows app to WINE
by Mike Engelhardt 28 Feb '03

28 Feb '03

Dear WINE developers, I develop an MS windows app and just got it working under WINE/Linux. It's call LTspice/SwitcherCADIII. It's a free schematic capture/SPICE simulator obtainable from www.linear.com/software. I've noticed a few things about WINE that might help you improve it. WINE can confuse SendMessage() with PostMessage(). LTspice uses SendMessage to handshake between threads sometimes. Wine usually obeys the difference, but treated some SendMessage calls like a PostMessage. My workaround was to poll volatile global variables. I needed to add some redraws to clear up some differences between WINE and Windows dialog box updates. This was for a tab control that make different controls on the pane visible or not depending on tab selection. Also LTspice draws directly to the screen and carefully counts the number of times it XOR'ed something with the screen. That behaved a bit different between WINE and Windows. Again, I found workarounds for most of it. I'm not sure, but maybe it's just a difference between obeying the SetROP2() setting for CDC::SetPixel() calls. The version of LTspice I put up on the web today, 2.01c, works quite well under WINE/Linux. The main problem with it is that the RoboHelp isn't working. Any advice there? A few other WINE issues: 1. The icons drawn on Property sheet tabs have a black background in WINE. In Windows it's the background color. You can see the problem on the Tools=>Control Panel tab icons. 2. The resize grip on the lower right hand corner of resizeable dialogs is drawn like a scrollbar. The "proper" windows method to draw these resize grips is to use a scroll bar created like this: CScrollBar m_Grip; char OldResizableGrip[] = "OldResizableGrip"; LRESULT CALLBACK GripWindowProc(HWND hwnd, UINT msg, WPARAM wParam,LPARAM lParam) { if(WM_NCHITTEST == msg) return(HTBOTTOMRIGHT); // the mouse cursor that goes with a grip on the bottom right of a window HANDLE oldWndProc = GetProp(hwnd, OldResizableGrip); if(WM_DESTROY == msg) // unsubclass { RemoveProp(hwnd, OldResizableGrip); SetWindowLong(hwnd, GWL_WNDPROC, (LONG) oldWndProc); } return(CallWindowProc((WNDPROC) oldWndProc, hwnd, msg, wParam,lParam)); } BOOL CSelectWaveformsDlg::OnInitDialog() { CDialog::OnInitDialog(); SetAllListBoxItems(); CRect rect(0, 0, GetSystemMetrics(SM_CXVSCROLL),GetSystemMetrics(SM_CYHSCROLL)); m_Grip.Create(WS_CHILD | WS_CLIPSIBLINGS | SBS_SIZEGRIP | WS_VISIBLE,rect, this, AFX_IDW_SIZE_BOX); CWnd *resizeWnd = GetDlgItem(AFX_IDW_SIZE_BOX); if(resizeWnd) { CRect rect, rect2; resizeWnd->GetWindowRect(&rect); GetClientRect(rect2); rect2.left = rect2.right - rect.Width(); rect2.top = rect2.bottom - rect.Height(); resizeWnd->MoveWindow(&rect2, FALSE); ::SetProp(m_Grip, OldResizableGrip, (HANDLE) ::GetWindowLong(m_Grip, GWL_WNDPROC)); ::SetWindowLong(m_Grip, GWL_WNDPROC, (LONG) GripWindowProc); } return(TRUE); } 3. Function key F6 is not trapped. 4. The cursor colors are off. For example, the voltage probe cursor should have a red body. In WINE it's black. The sleeve of the pointing hand is blue, in WINE it's black. 5. Font's aren't always correct. There's two types for schematics, "Arial" and "New Courier". The Arial can become italic depending on the size required. I would like to know if there is a way to determine if my app is running under WINE under runtime. That way I can work around more of these problems without imparing its performance under MS Windows. If you know the answer, please e-mail me directly. --Mike Engelhardt pmte(a)concentric.net

5 15

Re: FAQ updates
by Mike Hearn 28 Feb '03

28 Feb '03

On Fri, 2003-02-28 at 12:56, Andreas Mohr wrote: > Hi all, > > - Supported Platforms didn't mention MacOS X prominently enough by far... I think it should be made clear that Wine is useless on MacOS anyway, even if you do have the source and try to recompile for WineLib. It might simply be better to say, MacOS is *not* supported in any shape or form, and won't be until somebody does the large amount of work necessary to make it happen. > - add some URLs, correct URL handling > - remove linux.corel.com, as it's DEAD :-\ May it rest in peace.

1 0

Wine on Windows
by Serenity 27 Feb '03

27 Feb '03

Hi, Right, I've been Googling this one up, and I've found some information, but it's a few years old so I'm not sure if it's current... Has anybody had any success compiling and executing Wine on Win32? I know, it seems a bizzare concept, but I have legitament reasons to want to use Wine on Windows. There are some emails dating back to 2000 online saying it compiles on cygwin, but I'm not sure if this is still the case... Plus, ideally I'd be looking for a native port... Any directions would be great Ta Serenity

6 10

Enviroment variable formats
by J. Grant 27 Feb '03

27 Feb '03

Hello, While converting some paths, i had to frequently modify case.. Would it be possible for the fake wine drives use lower case names for their directorys by default? In MS-Windows different case is not a different file name. So I don't believe it will not make any difference to the program. The "config" has a mixture of all uppercase, and lowercase etc From wcmd there is also a mixture in the environment vars: COMSPEC=C:\WINDOWS\SYSTEM\wcmd.exe PATH=d:\vs\vc98\bin;d:\vs\common\msdev98\bin;c:\windows;c:\windows\system TEMP=E:\ TMP=E:\ windir=C:\WINDOWS winsysdir=C:\WINDOWS\SYSTEM USERPROFILE=C:\windows\Profiles\Administrator SYSTEMROOT=C:\WINDOWS the vars would be best in uppercase too IMO, as they are not differentiated. What do you think? Regards JG

1 0

Re: wine/ windows/painting.c windows/driver.c obje ...
by Dimitrie O. Paun 27 Feb '03

27 Feb '03

On Thu, 27 Feb 2003, Alexandre Julliard wrote: > Replaced most uses of the auto-generated glue code by explicit calls > to WOWCallback16Ex. Yay! Will you get rid of the last 4 as well: ./loader/task.c:/* ### start build ### */ ./loader/ne/module.c:/* ### start build ### */ ./loader/ne/segment.c:/* ### start build ### */ ./memory/local.c:/* ### start build ### */ This is a rather obscure extension that is hard to understand, I'm glad it's on it's way out. -- Dimi.

2 1

CryptoAPI
by Eric 27 Feb '03

27 Feb '03

Is anyone working on the CryptoAPI? I saw that back in December of '01 that a couple people had some interest, but I don't see anything else in the archives since then. - Eric

1 0

Re: more direct sound capture fixes
by Dimitrie O. Paun 27 Feb '03

27 Feb '03

On Thu, 27 Feb 2003, Eric Pouech wrote: > except that I'm not sure ALSA folks will be happy answering OSS related > questions ;-) True, but we might just trick'em into explaining how to do that in ALSA :) -- Dimi.

1 0

open source developer tutorial
by Dan Kegel 27 Feb '03

27 Feb '03

I'm writing a tutorial for budding open source developers; it's at http://www.kegel.com/academy/opensource.html My goal is to expand the pool of available open source developers by reaching out to e.g. college students who know C but aren't part of the open source / free software scene, and encouraging them to join in the fun. I use Wine in several of my examples, so be forewarned, this tutorial might cause a few newbies to post patches to wine. Feedback welcome. (I'm especially interested in usability comments -- the tutorial has to be easy to follow -- but any feedback at all would be helpful.) Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 1