- Wine-Devel - list.winehq.org

Re: Need to disable DTR on serial port
by Geoffrey Hausheer April 12, 2004

April 12, 2004

On Mon, 12 Apr 2004 09:26:30 +0200, "Rein Klazes" said: > > 1) it might be better to call COMM_WhackModem() after tcsetattr() so > > previous flow control settings don't interfere with setting the RTS/DTS > > lines. > > > > 2) #ifdef guards around TIOCM_DTR and TIOCM_RTS? > > > > Agreed, I will fix this in a moment. > Well, I tried Rein's latest patch out, and it still doesn't let me communicate with the device (using either my test program or TzMax). I am not sure if the patch isn't working (I can see the relevant code being called in winedbg), if there is something else required that wine isn't doing, or if it is a timing issue. In case it is interesting, here is my test app. This appears to be the minimum set of commands needed to communicate with the device. Note the tight write/query loop. Adding even a 'Sleep(1)' within that loop prevents the communication from working in Windows. I'm open to any other suggestions. Thanks, .Geoff

1 0

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar April 12, 2004

April 12, 2004

OK. I will resend the fix after incorporating your feedback. Thanks Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry(a)baikal.ru] > Sent: Monday, April 12, 2004 6:34 PM > To: Santosh Siddheshwar > Cc: wine-devel(a)winehq.com > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > Change Log: > > windows/defdlg.c - Added code for allocating DIALOGINFO structure and > > storing it as an attribute of the window > > windows/dialog.c - Removed code for allocating DIALOGINFO structure and > > moved initialization of DIALOGINFO structure > > to after CreateWindowEx has been called. > > Very nice! I'm glad to see that you finally have fixed that. However, > I see one minor point, which needs to be addressed as well: instead > of duplicating WM_CREATE code in both DefDlgProcA and W just move it > to DEFDLG_Proc. That way you will also fix 16-bit dialog creation code > by adding the same case into DefDlgProc16. > > Thanks for your great work! > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

1 0

Re: Handling dialog messages for non-template based dialogs
by Dmitry Timoshkov April 12, 2004

April 12, 2004

"Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > Change Log: > windows/defdlg.c - Added code for allocating DIALOGINFO structure and > storing it as an attribute of the window > windows/dialog.c - Removed code for allocating DIALOGINFO structure and > moved initialization of DIALOGINFO structure > to after CreateWindowEx has been called. Very nice! I'm glad to see that you finally have fixed that. However, I see one minor point, which needs to be addressed as well: instead of duplicating WM_CREATE code in both DefDlgProcA and W just move it to DEFDLG_Proc. That way you will also fix 16-bit dialog creation code by adding the same case into DefDlgProc16. Thanks for your great work! -- Dmitry.

1 0

Re: shell32: open desktop.ini to fetch icon
by Dmitry Timoshkov April 12, 2004

April 12, 2004

"Juan Lang" <juan_lang(a)yahoo.com> wrote: > ChangeLog: if a folder contains a desktop.ini, check > it for the icon location before using the default > folder icon It would be much better if you could mark all string constants as such using 'const' key word in all your patches (including already committed, submitted and future ones). Taking into account Wine size that should considerably improve overall virtual memory usage. -- Dmitry.

1 0

Need to disable DTR on serial port
by Geoffrey Hausheer April 12, 2004

April 12, 2004

In an ongoing effort to get TzMax working, I've been fighting to get it to talk to the device through the COM port. The problem is that the device (a wrist-watch...the program is used to download heart-rate data from said watch) is very difficult to comunicate with. In theory it is quite simple: send a 'ping' command, wait for a response, then send the 'receive' command, and read the data. In practice, getting the watch to acknowledge the initial ping is challenging. You need to repetitively send the 'ping' at odd intervals until the watch responds. Once it does, it will respond to commands readily. In any case, it turns out that one of the many requirements to get the watch to respond is to have DTR disabled (done by setting fDtrControl = DTR_CONTROL_DISABLE). But apparently the default for linux is DTR_CONTROL_ENABLE, and Wine will ignore any requests to change it (DTR_CONTROL_HANDSHAKE being unimplemented as well) I assume that driving the DTR line low is the trigger that tells the watch to listen to the Rx line. I am not sure if this is a Wine or Linux limitation, (as I have very limited knowledge of serial protocols), so I was wondering if anyone had any ideas for a suibtable workaround? Thanks, .Geoff

3 4

Re: win32 build error log
by Ivan Leo Murray-Smith April 11, 2004

April 11, 2004

> Patch is in Wine CVS. w32 packages are built against the release source, not the CVS. These fixes will affect next months build. > Patch is in MinGW CVS. Will this be ready for next month, or should I install mingw from CVS? Ivan.

1 0

Wine menu woes
by Geoffrey Hausheer April 11, 2004

April 11, 2004

I have an application that seems to work very well, except that the menus don't work (in wine, they are fine in Windows) The app is located here (free download): http://www.acumeninc.com/download/tzmax50v3.21.exe After some debugging, I found that the app creates a menu, then destroys it and recreates it using different titles. Something like: hMenu = CreateMenu(); hSub1 = CreatePopupMenu(); ... hSub2 = CreatePopupMenu(); ... AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub1, "&File"); AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub2, "&Other"); ... SetMenu(hWnd,hMenu); while(GetMenuItemCount(hMenu)) RemoveMenu(hMenu,0, 0x400); //Note: this just detaches the menus hOldMenu = hMenu; DestroyMenu(hMenu); hMenu=CreateMenu(); AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub1, "[&File]"); AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub2, "[&Other]"); if(hMenu != hOldMenu) SetMenu(hWnd, hMenu); That last line is where wine and Windows differ. In windows, the menuid is always different, so hMenu never equals hOldMenu. In wine, we reuse the menuid, so hMenu always equals hOldMenu. Since SetMenu didn't get called after the last createMenu, the menus don't work. I have no idea why the app implements its menus this way, but I removed the 'USER_HEAP_FREE( hMenu );' in DestroyMenu() and the menus work fine, as expected (obviously this isn't a fix, just a validation that the code behaves this way). I've included a test app that does the above if anyone is interested. As a secondary issue, for some reason the 'Exit' item executes the ID_DO_SOMETHING code instead of the ID_FILE_EXIT code. It doesn't do that in windows (it correctly exits instead). I don't think it is related, and i haven't looked into it, but I thought I'd mention it. Thanks, .Geoff

4 3

Re: win32 build error log
by Filip Navara April 11, 2004

April 11, 2004

>> i586-mingw32msvc/bin/ld: cannot find -ldxerr9 > > MinGW lacks up to date DirectX headers and import libs > but Filip Navara has been working on this. His work just > needs to be integrated into MinGW. Meanwhile I will add > a dxerr8 and dxerr9 to my MinGW rpm packages so we have > a means of cross compiling our tests. My work was recently merged into MinGW CVS. [Danny Smith immediately did some changes in dxerr libraries that I think aren't right, but haven't tested it. So it's possible that the versions in MinGW CVS will not work anyway.] - Filip

1 0

win32 build error log
by Ivan Leo Murray-Smith April 11, 2004

April 11, 2004

The error log from the win32 build of wine-20040408 Ivan.

2 1

Re: exec-shield workaround take 2
by Dan Kegel April 11, 2004

April 11, 2004

Mike Hearn wrote: > It seems it's turned from being an normal (albiet static) app which > reserves the areas needed then boots wine, into a reimplementation of > ld-linux.so? This isn't all bad. Consider: we could add the ability to load PE executables and shared libraries into this private ld-linux.so. At that point, the need for winelib executables to be shared libraries goes away, doesn't it? And that would make everybody very, very happy, as it would solve the problem that made mono and everybody else fork wine just so they could load Windows DLLs into native linux apps. Or am I confused? Wouldn't be the first time... - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

2 1