wine-devel

wine-devel@winehq.org

84471 discussions

PE support in MZ_Exec() /winedos/module.c
by Chris Morgan 23 Sep '02

23 Sep '02

I have a .com application that is calling out to dos int21 4Bh to load and execute a program. MZ_Exec assumes this program is always going to be a dos executable and the application fails to run and complains that it is a pe executable. So I've started to try and add support for correctly handling pe executables. So far I have a patch like below but I'm thinking that a lot more needs to be done in order to fulfill the dos requirements of this function and kind of wanted some opinions on this. This compiles but I haven't tested it since the program is at work, just wanted to get some feedback. Thanks, Chris Index: dlls/winedos/module.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/module.c,v retrieving revision 1.21 diff -u -r1.21 module.c --- dlls/winedos/module.c 30 Aug 2002 00:03:25 -0000 1.21 +++ dlls/winedos/module.c 22 Sep 2002 03:28:00 -0000 @@ -39,6 +39,7 @@ #endif #include "windef.h" #include "wine/winbase16.h" +#include "wine/winbase.h" #include "wingdi.h" #include "winuser.h" #include "winerror.h" @@ -342,16 +343,29 @@ */ BOOL WINAPI MZ_Exec( CONTEXT86 *context, LPCSTR filename, BYTE func, LPVOID paramblk ) { + enum binary_type binType; + STARTUPINFOA st; + PROCESS_INFORMATION pe; + BOOL status; + /* this may only be called from existing DOS processes * (i.e. one DOS app spawning another) */ - /* FIXME: do we want to check binary type first, to check - * whether it's a NE/PE executable? */ HANDLE hFile = CreateFileA( filename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); BOOL ret = FALSE; + + binType = MODULE_GetBinaryType(hFile); + if (hFile == INVALID_HANDLE_VALUE) return FALSE; switch (func) { case 0: /* load and execute */ + if(binType == BINARY_PE_EXE) + { + ZeroMemory (&st, sizeof(STARTUPINFOA)); + st.cb = sizeof(STARTUPINFOA); + status = CreateProcessA (NULL, filename, NULL, NULL, FALSE, + 0, NULL, NULL, &st, &pe); + } case 1: /* load but don't execute */ { /* save current process's return SS:SP now */

4 3

Standard load address for a Win32 program (0x00400000) not available
by Per Wigren 23 Sep '02

23 Sep '02

Hi! I'm trying to run Streambox VCR, but I get this error: err:win32:do_relocations Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load 'F:\x\vcr.exe' as Win32 binary I DO have some security-patches in the kernel.. If that is the problem, what patches should I disable? Regards Per Wigren

2 2

GetCursorPos & NTCurrentTeb question
by Rick Romero 23 Sep '02

23 Sep '02

I'm trying to track down the buttonup issue for Foxpro, and I've found an inconsistency, but I can't track it down. I started with GetCursorPos. It assigns PosX to pt->x, and PosY to pt->y, then calls X11drv.GetCursorPos, and assigns the current mouse coords to pt->x and pt->y. The problem is when the button is clicked, PosX and PosY retain the original values forever: A second or so after the left button is clicked: *Input.c current GetCursorPos (490,172) && (490,172) PosX,PosY && pt->X,pt->y *Button1Mask / state 256 / 16 (button is now up) *trace:cursor:X11DRV_GetCursorPos pointer at (489,186) (Where X says the pointer is) *-userdrivercall complete- (X11) Now: (490, 172)- 489,186- PosX,PosY && pt->X,pt->y (* my traces are just printf's) Even though the values are updated, they never get reassigned to PosX and PosY. I'm not sure WHERE that's supposed to happen, nor have I been able to figure out where GetCursorPos is called from. Is it possible that the values, and GetCursorPos are dealt with INTERNAL to MS FoxPro? I also am finding that the Wine server is returning Status Pending, then Status Timeout in WaitforMultipleObjectsEX in synchro.c. This happens a couple times when FoxPro starts up, but is eventually 'broken' out of. The Status_Pending triggers a call to wait_reply() in WaitforMultipleObjectsEx which does: ret = read( NtCurrentTeb()->wait_fd[0], &reply, sizeof(reply) ); GetCursorPos is called about 180 times before ret is set. I can't seem to find any reference to NTCurrentTeb in Wine (grep -nr), even though I found mention of it in the archive. Seems like an internal OS call. I don't know what's calling GetCursorPos, I don't know where pt->x gets assigned to PosX (but that's just a side effect, the mouse moves, it's the button that's stuck), and I don't know why wait_reply is getting a STATUS_TIMEOUT. Any ideas for me? Thanks, Rick

1 0

Re: Listview updates
by Dmitry Timoshkov 23 Sep '02

23 Sep '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > @@ -1034,13 +1035,13 @@ > /* Update Vertical Scrollbar */ > nListHeight = infoPtr->rcList.bottom - infoPtr->rcList.top; > scrollInfo.fMask = SIF_POS; > - if (GetScrollInfo(infoPtr->hwndSelf, SB_VERT, &scrollInfo) == FALSE > + if (GetScrollInfo(infoPtr->hwndSelf, SB_VERT, &scrollInfo) Exclamation mark (!) is missing... -- Dmitry.

1 0

wininet test fails under Win2K SP3 - compiled with gcc 3.2
by Steven Edwards 23 Sep '02

23 Sep '02

$ ./wininet_test.exe http http.c:86:Starting with flags 0x10000000 http.c:88:InternetOpenA <-- http.c:91:InternetOpenA --> http.c:95:InternetConnectA <-- http.c:74:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0022EB 34 4 http.c:98:InternetConnectA --> http.c:103:HttpOpenRequestA <-- http.c:74:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0022ED A4 4 http.c:109:HttpOpenRequestA --> http.c:111:HttpSendRequestA --> http.c:118:HttpSendRequestA <-- http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESOLVING_NAME(10) 0119FB DC 15 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_NAME_RESOLVED(11) 0119FBC C 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20) 0119FC48 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 0 119FDDC 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000 000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 0119FD84 4 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00 000000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 011 9FE04 4 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_COMPLETE(100) 011 9FE40 8 http.c:125:Option 0x17 -> 1 0 http.c:129:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:134:Option 0x16 -> 1 HTTP/1.1 200 OK Date: Mon, 23 Sep 2002 06:45:41 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4. 1.2 X-Powered-By: PHP/4.1.2 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html http.c:139:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:143:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) http.c:148:Option 0x1 -> 1 text/html http.c:151:Entery Query loop http.c:168:ReadFile -> 1 743 http.c:168:ReadFile -> 1 7728 http.c:157: Test failed: InternetQueryDataAvailable failed http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_COMPLETE(100) 011 9FE40 8 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CLOSING_CONNECTION(50) 00 000000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTION_CLOSED(51) 000 00000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 5C 4 http.c:74:Callback 00CC0008 0xdeadbeef INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 8C 4 http.c:176: Test failed: InternetCloseHandle failed http.c:86:Starting with flags 0x0 http.c:88:InternetOpenA <-- http.c:91:InternetOpenA --> http.c:95:InternetConnectA <-- http.c:74:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0022EB 34 4 http.c:98:InternetConnectA --> http.c:103:HttpOpenRequestA <-- http.c:74:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0022ED A4 4 http.c:109:HttpOpenRequestA --> http.c:111:HttpSendRequestA --> http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20) 0022EBEC 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 0 022EBC8 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000 000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 0022ECD0 4 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00 000000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 002 2ECB4 4 http.c:118:HttpSendRequestA <-- http.c:125:Option 0x17 -> 1 0 http.c:129:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:134:Option 0x16 -> 1 HTTP/1.1 200 OK Date: Mon, 23 Sep 2002 06:45:41 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4. 1.2 X-Powered-By: PHP/4.1.2 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html http.c:139:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:143:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) http.c:148:Option 0x1 -> 1 text/html http.c:151:Entery Query loop http.c:168:ReadFile -> 1 743 http.c:168:ReadFile -> 1 436 http.c:168:ReadFile -> 1 3728 http.c:168:ReadFile -> 1 644 http.c:168:ReadFile -> 1 3736 http.c:168:ReadFile -> 1 2097 http.c:168:ReadFile -> 1 403 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 5C 4 http.c:74:Callback 00CC0008 0xdeadbeef INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 8C 4 http.c:176: Test failed: InternetCloseHandle failed http: 23 tests executed, 0 marked as todo, 3 failures. Administrator@PH33R /g/src/wine-dev/wine/dlls/wininet/tests $

1 0

Re: ASIO and wine
by Thomas Wickline 23 Sep '02

23 Sep '02

Tom Hibbert wrote: >On Sun, Sep 22, 2002 at 11:44:53AM -0400, Thomas Wickline wrote: > > >>Cubase will not run with wine as it need's VxD support .. >>ASIO (Audio Stream Input Output) needs Communication between >>audio software and a piece of audio hardware and this is where >>the VxD problem comes in .. >> >>Can someone here confirm this ?? >> >>Tom >> >> > > >Cubase SX is pure 32bit.. i would have thought it didnt use VxDs which >AFAIK were obseleted with win2k... > > I am not 100% sure this was only my thoughts of what would/could happen .. That is why I ask for someone else to confirm . Tom

1 0

email to webmaster@winehq.com dead?
by Andreas Schuldei 22 Sep '02

22 Sep '02

i and others have mailed to webmaster(a)winehq.com to report changes in the daily wine builds for debian. (it was about the fact that i should not read gluck.debian.org but people.debian.org in the apt/sources.list lines) that has been quite a while. i do still get mails by confused users which do not know how to fix their download of wine packages. could someone fix that, please?

1 0

Re: FD_ZERO and FD_SET problems.
by Michael Stefaniuc 22 Sep '02

22 Sep '02

Could you please resubmit it as unified diff (diff -u)? The diff's are more readable and are more robust regarding to changes in the target file. bye michael On Fri, Sep 20, 2002 at 08:10:41PM -1000, Patrick J. McNerthney wrote: > I hope I am doing this correctly. I am porting some Win32 software > using WineLib and ran into some problems with the WinSock headers, > specifically with regards to the use of FD_ZERO and FD_SET (they just > wouldn't compile at all). Attached is the patch that resolved my > problems. > > ChangeLog > Fixed if statement in __WS_FD_SET2 which did not have it's outer set > of parenthesis. > Removed parentheses around type to be cast in __WS_FD_SET macro. > Removed WS macro usage from within other macros because the WS macro > is undefined when these macros are expanded. > > Pat McNerthney > Icicle Software, Inc. -- 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 1

ASIO and wine
by Tom Hibbert 22 Sep '02

22 Sep '02

Hello, I am very interested in creating a home studio system with Linux. I get 1/4 the latency i do using Windows with the same hardware.. there is more control.. etc etc.. there are many reasons why I want to do this. I would especially like to use Cubase SX. The main barrier hampering this (besides copy protection ;) is the lack of ASIO support under Wine. Secondly, timing issues, but that is easy to tweak by the user. I am wondering if there are any progects or plans to implement ASIO in Wine/WineX. If so, I would like to contribute. If not, I will have to go to university and study computer science as well as electronic music. ;) Oh, yes - i know there are a lot of quality open source audio products (Audacity, Psycle, Csound, MAX/MSP come to mind...) I am mainly interested in seeing some VST implementation on Linux because VST is a very widely used and mature base for software synthesisers and effects. I'm told the only barrier to a NATIVE VST-capable app (Yes, the code is all there in the Audacity sources AFAIK) is the porting of a library known as libvstgui... why not run this through Winelib is the next thing i am going to ask the developers of that particular product :) Tom Hibbert Work: someday Home: +649 815 1838 Obtain my GPG Key from: http://cryptocracy.hn.org/pubkey.txt

2 2

Re: fix listview trace crash
by Dimitrie O. Paun 22 Sep '02

22 Sep '02

On September 21, 2002 02:46 am, Rein Klazes wrote: > Hi, > > With these fixes the original reason to debug disappeared as well ;-) > > dlls/comctl32/ : listview.c > Fix some crashes running with --debugmsg +listview > + ZeroMemory(&item, sizeof(item)); We shouldn't need these. In fact, they just hide bugs, and most of them are superfluous anyways. The first hunk is a good find though, I've integrated it in my patch. Alexandre, please use this one instead. ChangeLog -- Fix outputing of a text pointer in debug mode (by Rein Klazes) -- Remove a large bunch of superfluous ZeroMemory calls -- Fix couple of bugs Index: dlls/comctl32/listview.c =================================================================== RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v retrieving revision 1.148 diff -u -r1.148 listview.c --- dlls/comctl32/listview.c 18 Sep 2002 18:29:28 -0000 1.148 +++ dlls/comctl32/listview.c 21 Sep 2002 15:08:20 -0000 @@ -337,7 +337,7 @@ wstr = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); if (wstr) MultiByteToWideChar(CP_ACP, 0, (LPCSTR)text, -1, wstr, len); } - TRACE(" wstr=%s\n", debugstr_w(wstr)); + TRACE(" wstr=%s\n", text == LPSTR_TEXTCALLBACKW ? "(callback)" : debugstr_w(wstr)); return wstr; } @@ -423,7 +423,7 @@ " pszText=%s, cchTextMax=%d, iImage=%d, lParam=%lx, iIndent=%d}", lpLVItem->mask, lpLVItem->iItem, lpLVItem->iSubItem, lpLVItem->state, lpLVItem->stateMask, - debugtext_tn(lpLVItem->pszText, isW, 80), + lpLVItem->mask & LVIF_TEXT ? debugtext_tn(lpLVItem->pszText, isW, 80) : 0, lpLVItem->cchTextMax, lpLVItem->iImage, lpLVItem->lParam, lpLVItem->iIndent); return buf; @@ -605,6 +605,7 @@ BOOL bReturn; item.iItem = iItem; + item.iSubItem = 0; item.mask = LVIF_PARAM; LISTVIEW_GetItemT(infoPtr, &item, TRUE, TRUE); @@ -865,7 +866,6 @@ } /* get item */ - ZeroMemory(&item, sizeof(item)); item.mask = LVIF_TEXT; item.iItem = idx; item.iSubItem = 0; @@ -1557,7 +1557,6 @@ if (adj_sel_only) return TRUE; /* set the selection on items */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.state = LVIS_SELECTED; lvItem.stateMask = LVIS_SELECTED; for(i = lower; i <= upper; i++) @@ -1576,7 +1575,7 @@ LVITEMW lvItem; INT index, i; - ZeroMemory(&lvItem, sizeof(lvItem)); + lvItem.state = 0; lvItem.stateMask = LVIS_SELECTED; remsel.lower = lower; @@ -1734,7 +1733,6 @@ INT oldFocus = infoPtr->nFocusedItem; LVITEMW lvItem; - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.state = LVIS_FOCUSED; lvItem.stateMask = LVIS_FOCUSED; LISTVIEW_SetItemState(infoPtr, nItem, &lvItem); @@ -1830,8 +1828,8 @@ if (nFirst == -1) nFirst = nItem; - item.stateMask = LVIS_SELECTED; item.state = LVIS_SELECTED; + item.stateMask = LVIS_SELECTED; /* FIXME: this is not correct LVS_OWNERDATA * See docu for LVN_ITEMCHANGED. Is there something similar for @@ -1889,8 +1887,6 @@ POINT ptItem; RECT rcSel; - item.stateMask = LVIS_SELECTED; - if ((uView == LVS_LIST) || (uView == LVS_REPORT)) { if (infoPtr->nSelectionMark == -1) @@ -1910,6 +1906,8 @@ nFirst = nLast = -1; } + item.stateMask = LVIS_SELECTED; + for (i = 0; i <= GETITEMCOUNT(infoPtr); i++) { if (nFirst > -1) @@ -2397,8 +2395,6 @@ lpSubItem = (LISTVIEW_SUBITEM *)COMCTL32_Alloc(sizeof(LISTVIEW_SUBITEM)); if (!lpSubItem) return FALSE; - ZeroMemory(lpSubItem, sizeof(LISTVIEW_SUBITEM)); - /* we could binary search here, if need be...*/ for (i = 1; i < hdpaSubItems->nItemCount; i++) { @@ -2692,7 +2688,6 @@ TRACE("(hdc=%x, nItem=%d)\n", hdc, nItem); /* get information needed for drawing the item */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_STATE | LVIF_INDENT; lvItem.stateMask = LVIS_SELECTED | LVIS_STATEIMAGEMASK; lvItem.iItem = nItem; @@ -2874,7 +2869,6 @@ hdc, nItem, rcItem.left, rcItem.top, rcItem.right, rcItem.bottom); /* get information needed for drawing the item */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_STATE; lvItem.stateMask = LVIS_SELECTED | LVIS_FOCUSED; lvItem.iItem = nItem; @@ -3752,7 +3746,7 @@ /* remove it from the selection range */ - ZeroMemory(&item,sizeof(item)); + item.state = LVIS_SELECTED; item.stateMask = LVIS_SELECTED; LISTVIEW_SetItemState(infoPtr,nItem,&item); @@ -3858,10 +3852,10 @@ else { ZeroMemory(&lvItemRef,sizeof(LISTVIEW_ITEM)); - ZeroMemory(&item,sizeof(item)); item.iItem = nItem; item.iSubItem = 0; item.mask = LVIF_PARAM | LVIF_STATE; + item.stateMask = ~0; ListView_GetItemW(infoPtr->hwndSelf, &item); lvItemRef.hdr.iImage = item.iImage; lvItemRef.state = item.state; @@ -3873,7 +3867,7 @@ dispInfo.item.mask = 0; dispInfo.item.iItem = nItem; dispInfo.item.state = lpItem->state; - dispInfo.item.stateMask = 0; + dispInfo.item.stateMask = 0; /* FIXME: why not copy the state mask in here? */ dispInfo.item.pszText = pszText; dispInfo.item.cchTextMax = textlenT(pszText, isW); dispInfo.item.iImage = lpItem->hdr.iImage; @@ -3940,11 +3934,10 @@ else { LVITEMW item; - ZeroMemory(&lvItemRef,sizeof(LISTVIEW_ITEM)); - ZeroMemory(&item, sizeof(item)); item.iItem = nItem; item.iSubItem = 0; item.mask = LVIF_PARAM | LVIF_STATE; + item.stateMask = ~0; ListView_GetItemW(infoPtr->hwndSelf, &item); lvItemRef.hdr.iImage = item.iImage; lvItemRef.state = item.state; @@ -3953,7 +3946,6 @@ } /* get information needed for drawing the item */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT; lvItem.iItem = nItem; lvItem.iSubItem = 0; @@ -3966,7 +3958,7 @@ dispInfo.item.mask = 0; dispInfo.item.iItem = nItem; dispInfo.item.state = lpItem->state; - dispInfo.item.stateMask = 0; + dispInfo.item.stateMask = 0; /* FIXME: why not copy the state mask in here? */ dispInfo.item.pszText = lvItem.pszText; dispInfo.item.cchTextMax = lstrlenW(lvItem.pszText); dispInfo.item.iImage = lpItem->hdr.iImage; @@ -4218,8 +4210,6 @@ if ((nItem >= -1) && (lpFindInfo != NULL)) { - ZeroMemory(&lvItem, sizeof(lvItem)); - if (lpFindInfo->flags & LVFI_PARAM) { lvItem.mask |= LVIF_PARAM; @@ -5131,7 +5121,6 @@ if (uView & LVS_REPORT) { - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_INDENT; lvItem.iItem = nItem; lvItem.iSubItem = 0; @@ -5544,9 +5533,9 @@ TRACE("(nItem=%d)\n", nItem); - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT; lvItem.iItem = nItem; + lvItem.iSubItem = 0; lvItem.cchTextMax = DISP_TEXT_SIZE; lvItem.pszText = szDispText; if (LISTVIEW_GetItemW(infoPtr, &lvItem, TRUE)) @@ -5603,10 +5592,10 @@ if ((nItem >= 0) && (nItem < GETITEMCOUNT(infoPtr))) { - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.iItem = nItem; - lvItem.stateMask = uMask; + lvItem.iSubItem = 0; lvItem.mask = LVIF_STATE; + lvItem.stateMask = uMask; if (LISTVIEW_GetItemW(infoPtr, &lvItem, TRUE)) uState = lvItem.state & uMask; } @@ -6352,8 +6341,6 @@ if ( !(lpItem = (LISTVIEW_ITEM *)COMCTL32_Alloc(sizeof(LISTVIEW_ITEM))) ) return -1; - ZeroMemory(lpItem, sizeof(LISTVIEW_ITEM)); - /* insert item in listview control data structure */ if ( (hdpaSubItems = DPA_Create(8)) ) nItem = DPA_InsertPtr(hdpaSubItems, 0, lpItem); @@ -6718,7 +6705,6 @@ } else { - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.iSubItem = iCol; lvItem.mask = LVIF_TEXT; lvItem.cchTextMax = DISP_TEXT_SIZE; @@ -6783,7 +6769,6 @@ SelectObject(hdc, old_font); /* restore the old font */ ReleaseDC(infoPtr->hwndSelf, hdc); - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.iSubItem = iCol; lvItem.mask = LVIF_TEXT; lvItem.cchTextMax = DISP_TEXT_SIZE; @@ -7190,14 +7175,13 @@ BOOL bResult = TRUE; LVITEMW lvItem; - TRACE("(nItem=%d, lpLVItem=%s)\n", - nItem, debuglvitem_t(lpLVItem, TRUE)); + TRACE("(nItem=%d, lpLVItem=%s)\n", nItem, debuglvitem_t(lpLVItem, TRUE)); - ZeroMemory(&lvItem, sizeof(lvItem)); + lvItem.iItem = nItem; + lvItem.iSubItem = 0; lvItem.mask = LVIF_STATE; lvItem.state = lpLVItem->state; lvItem.stateMask = lpLVItem->stateMask ; - lvItem.iItem = nItem; if (nItem == -1) { @@ -7227,24 +7211,18 @@ */ static BOOL LISTVIEW_SetItemTextT(LISTVIEW_INFO *infoPtr, INT nItem, LPLVITEMW lpLVItem, BOOL isW) { - BOOL bResult = FALSE; - LVITEMW lvItem; + LVITEMW lvItem; - TRACE("(nItem=%d, lpLVItem=%s, isW=%d)\n", - nItem, debuglvitem_t(lpLVItem, isW), isW); + TRACE("(nItem=%d, lpLVItem=%s, isW=%d)\n", nItem, debuglvitem_t(lpLVItem, isW), isW); - if ((nItem >= 0) && (nItem < GETITEMCOUNT(infoPtr))) - { - ZeroMemory(&lvItem, sizeof(LVITEMW)); - lvItem.mask = LVIF_TEXT; - lvItem.pszText = lpLVItem->pszText; + if ((nItem < 0) && (nItem >= GETITEMCOUNT(infoPtr))) return FALSE; + lvItem.iItem = nItem; lvItem.iSubItem = lpLVItem->iSubItem; - if(isW) bResult = ListView_SetItemW(infoPtr->hwndSelf, &lvItem); - else bResult = ListView_SetItemA(infoPtr->hwndSelf, &lvItem); - } - - return bResult; + lvItem.mask = LVIF_TEXT; + lvItem.pszText = lpLVItem->pszText; + + return LISTVIEW_SetItemT(infoPtr, &lvItem, isW); } /*** @@ -7489,7 +7467,6 @@ if (!infoPtr) return -1; SetWindowLongW(hwnd, 0, (LONG)infoPtr); - ZeroMemory(infoPtr, sizeof(LISTVIEW_INFO)); infoPtr->hwndSelf = hwnd; /* determine the type of structures to use */ @@ -8097,9 +8074,8 @@ bGroupSelect = (LISTVIEW_GetItemState(infoPtr, nItem, LVIS_SELECTED) == 0); - ZeroMemory(&item, sizeof(item)); + item.state = bGroupSelect ? LVIS_SELECTED : 0; item.stateMask = LVIS_SELECTED; - if(bGroupSelect) item.state = LVIS_SELECTED; LISTVIEW_SetItemState(infoPtr, nItem, &item); LISTVIEW_SetItemFocus(infoPtr, nItem);

2 3

Patch - stub and workaround to make wineserver compile on cygwin
by Steven Edwards 22 Sep '02

22 Sep '02

This will allow you to run wineserver on cygwin. We still lack tons of stuff before we can have a WINE that really works on Cygwin but over the next few months/years++ as I am learning, I will keep working on this. Changelog: Wineserver - Stub get/set_thread_context in wineserver so it will build/run Change permission error to a Warning when running on Windows/Cygwin Index: context_i386.c =================================================================== RCS file: /home/wine/wine/server/context_i386.c,v retrieving revision 1.23 diff -u -r1.23 context_i386.c --- context_i386.c 14 Aug 2002 20:59:03 -0000 1.23 +++ context_i386.c 22 Sep 2002 03:19:41 -0000 @@ -460,9 +460,24 @@ file_set_error(); } -#else /* linux || __sun__ || __FreeBSD__ */ +#elif defined(__MINGW__) || defined(__CYGWIN__) || defined(_WINDOWS) + +/* retrieve a thread context */ +static void get_thread_context( struct thread *thread, unsigned int flags, CONTEXT *context ) +{ + printf("get_thread_context is a stub on WINDOWS!\n"); + return 0; +} + +static void set_thread_context( struct thread *thread, unsigned int flags, const CONTEXT *context ) +{ + printf("get_thread_context is a stub on WINDOWS!\n"); + return 0; +} + +#else /* linux || __sun__ || __FreeBSD__ || _WINDOWS */ #error You must implement get/set_thread_context for your platform -#endif /* linux || __sun__ || __FreeBSD__ */ +#endif /* linux || __sun__ || __FreeBSD__ || _WINDOWS */ /* copy a context structure according to the flags */ Index: request.c =================================================================== RCS file: /home/wine/wine/server/request.c,v retrieving revision 1.67 diff -u -r1.67 request.c --- request.c 16 Aug 2002 20:02:15 -0000 1.67 +++ request.c 22 Sep 2002 03:21:04 -0000 @@ -483,7 +483,11 @@ } if (!S_ISDIR(st->st_mode)) fatal_error( "%s is not a directory\n", name ); if (st->st_uid != getuid()) fatal_error( "%s is not owned by you\n", name ); +#if defined(__MINGW__) || defined(__CYGWIN__) || defined(_WINDOWS) + fprintf( stderr, "Warning: %s is accessible by other users\n", name ); +#else if (st->st_mode & 077) fatal_error( "%s must not be accessible by other users\n", name ); +#endif /* defined(__MINGW__) || defined(__CYGWIN__) || defined(_WINDOWS) */ } /* create the server directory and chdir to it */

1 0

Re: wine status page
by Brian Vincent 22 Sep '02

22 Sep '02

> that's ok. I've just uploaded your file to winehq > it's up (& running). thanx for your good work If someone wants to forward me the raw HTML I'll edit it to include WWN threads. -brian

4 4

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 22 Sep '02

22 Sep '02

One step at a time... Now I've successfully included my stubbed dll into the wine tree. When I try to link to it, however, I still get undefined references to what should be in the dll. I added my stubbed dll to the my_other_dll_DLLS section of the Makefile.in, just like it were a normal wine dll. Is that all I need to do to link to it? When I run nm on my dll in /usr/local/lib/wine, it only lists entries like: 000131a4 T __wine_stub_mydll_dll_13 It doesn't list any of the exported functions that are listed in the spec file that winedump generated. Does wine automagically match up those stub statements with the exported symbols? Does it matter that the dll is exporting C++ classes, not straight C functions? -Steve Hi Steve, > I upgraded my autoconf, which solved my first problem. Now, > everything runs fine until I get to the make install step, when > I get this error: <snip> The attached patch to winedump corrects the over-enthusiatic insertion of generated DLL entries into dlls/Makefile.in, and renames the MODULE from <dll> to <dll>.dll as per the current build process. You can manually remove the offending lines youself, edit dlls/Makefile.in and remove the 2 lines referring to your DLL after the targets "uninstall::" and "install::". Then append".dll" to the MODULE = line in dlls/<yourdll>/Makefile.in. Alternately, apply the patch and regenerate. I've just tested the process from start to finish and it works for me now. Let me know if you find any other issues. I've sent the patch to wine-patches/Alexandre. > Thanks for making those changes to the README, hopefully they'll get > committed soon so other can avoid the problems I had. np :-) Jon (See attached file: winedump_fix.diff)

2 1

Re: notepad vs write
by Sean Young 21 Sep '02

21 Sep '02

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > "Francois Gouget" <fgouget(a)free.fr> wrote: > > The problem is that write will handle RTF and Word documents correctly, > > while notepad is just a text editor and will only display garbage... > > > > (yes, wordpad will probably have problems with complex word documents, > > but it should work with simple ones) > > I believe that Write is able to handle only old Word 5.x/6.x format files > (and of course RTFs). RTFs should not produce too much trouble (just feed > them to a richedit control). Regarding Word 5.x format here is a snipped > from my very old DOS code which handled those files (*.doc,*.wri) well > (it completely ignores formatting though): I've written a .wri to RTF converter, which is available here: http://www.msxnet.org/word2rtf/write.c It should be almost complete. The output is almost the same as the microsoft converter (including bugs, if desired). Now I have enough information to write write32.cnv, but is there any need for this? Sean

2 2

regression in recent cvs (transparent window) ?
by T'aZ 21 Sep '02

21 Sep '02

i've recently compiled wine cvs, and now, the content of a window from an app is not shown, it's the bug http://bugs.winehq.com/show_bug.cgi?id=1033 cmorgan on irc said me i might post here so that "maybe someone knows if it was their patch that did it" :) -- T'aZ *Just because you are paranoid, it doesn't mean they are not after you.*

1 0

Re: HRGN
by Michael Stefaniuc 21 Sep '02

21 Sep '02

On Fri, Sep 20, 2002 at 05:15:10PM -0400, Dimitrie O. Paun wrote: > Oddly enough, this seem to work... STOP! It dosn't work: [...] ../../windows/painting.c:433: switch quantity not an integer [...] make[2]: *** [../../windows/painting.o] Error 1 make[2]: Leaving directory `/home/michi/work/wine/dlls/user' make[1]: *** [user] Error 2 make[1]: Leaving directory `/home/michi/work/wine/dlls' make: *** [dlls] Error 2 You picked one of the 3 handles that dosn't even compile when switched to a void* (the other two are HICON, HINSTANCE). None of the to be converted handles are so simple to convert, because if it would have been so simple, it would have already been done ;). Before i start working on the conversion of a handle i do an automated compile run for every remaining DECLARE_OLD_HANDLE saving the output of the build. Here some statistic from a compile run from 3 days ago: camus:/scr/wine.test$ for i in wine.H*; do > echo -n "$i: " > diff -u wine/make.out $i/make.out | grep -c ^+ > done wine.HBITMAP: 664 wine.HBRUSH: 428 wine.HDC: 941 wine.HFONT: 460 wine.HICON: 163 wine.HINSTANCE: 200 wine.HKEY: 423 wine.HMENU: 322 wine.HPEN: 216 wine.HRGN: 220 As you can the there are at least 160 lines of warnings to look at. bye michael > > ChangeLog > Convert HRGN to void * > > Index: include/windef.h > =================================================================== > RCS file: /var/cvs/wine/include/windef.h,v > retrieving revision 1.74 > diff -u -r1.74 windef.h > --- include/windef.h 16 Sep 2002 22:47:05 -0000 1.74 > +++ include/windef.h 20 Sep 2002 18:25:30 -0000 > @@ -89,7 +89,7 @@ > DECLARE_HANDLE(HMONITOR); > DECLARE_HANDLE(HPALETTE); > DECLARE_OLD_HANDLE(HPEN); > -DECLARE_OLD_HANDLE(HRGN); > +DECLARE_HANDLE(HRGN); > DECLARE_HANDLE(HRSRC); > DECLARE_HANDLE(HTASK); > DECLARE_HANDLE(HWINEVENTHOOK); -- 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

Re: winedump doc
by Dimitrie O. Paun 21 Sep '02

21 Sep '02

On September 20, 2002 04:13 pm, Eric Pouech wrote: > this patch adds winedump documentation > (Alexandre, you can delete tools/winedump/README if you want) Sorry, but I don't agree with this patch. Unix docs for command line utilities come in the form of man pages (or info pages). Why put in .sgml? Who's gonna read it there? Who's gonna maintain it there? It should go into a file: programs/winedump/windump.man.in or similar... -- Dimi.

2 2

Re: documentation dir
by Dimitrie O. Paun 20 Sep '02

20 Sep '02

On September 18, 2002 04:10 am, Eric POUECH wrote: > IMO, most of the documentation (even the internals description, > status of DLL) should be made in the DocBook form I don't think this is right. Documenetation that is meant for the user should go into .sgml, no disagreement here. Documentation that is meant for the ongoing developement of a DLL (something like the TODO list, or a few comments on the internal structure, or some tips, etc.) should go as plain text as close as possible to the code that it's documenting. I can not stress how important that is. I find this "developer" documentation useful beyon words: as I read through the code, it gives me ideas on what to work, I keep it _updated_. On the other hand, I've never even read 50% of the .sgml documentation even once. But even if I do, it will never have the "current" status of the one embedded in the/close to the code. As I said before, this thing has been tried numerous times before, and everybody reached the conclusion that the documentation pertaining to code should be as close to the code that it's documenting (see javadoc et. Co.). -- Dimi.

3 5

Re: wine status page
by Eric Pouech 20 Sep '02

20 Sep '02

> I have a update for the status page. > I made changes to the php.html file > If you need more info just let me know Thomas that's ok. I've just uploaded your file to winehq it's up (& running). thanx for your good work A+

1 0

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 20 Sep '02

20 Sep '02

Hi Jon I upgraded my autoconf, which solved my first problem. Now, everything runs fine until I get to the make install step, when I get this error: make[2]: Leaving directory `/home/stevenlu/wine/dlls/x11drv' mydll.dll.so \ rm -f /usr/local/lib/libntdll.dll.so make[1]: mydll.dll.so: Command not found make[1]: *** [install] Error 127 make[1]: Leaving directory `/home/stevenlu/wine/dlls' make: *** [dlls/__install__] Error 2 Winedump created dlls/mydll/mydll.so, not mydll.dll.so. Thanks for making those changes to the README, hopefully they'll get committed soon so other can avoid the problems I had. -Steve Hi Steve, On Wed, 18 Sep 2002 18:57, steve.lustbader(a)philips.com wrote: > The README section on inserting the stub dll into the wine tree > seems a little out-dated. It tells me to run autoconf, but > autoconf complains that it cannot find configure.in - is this > step still needed? Yes, any time that you add or delete directories to the base distribution you need to re-run autoconf to generate a new configure script. In your case you are running an older version of autoconf. Make sure that you are running autoconf version 2.53 or higher, or this process will not work. There was a thread a while ago on allowing earlier versions of autoconf to be used to build Wine, but its not seen as too onerous to require a recent version for developers. > If I skip autoconf (which may be causing this problem), when > I run make depend I get: <snip> Yes, you have the dll directory and a Makefile.in in there, but no Makefile, since configure didn't get updated and generate one for you. > I ran the install script that winedump produced, but maybe that's > not up-to-date with respect to the current wine build process? I updated the build process following the big changes earlier this year for building on Win32. I don't believe there are any problems, but there have been some changes since then. If you have any issues let me know and I'll try and iron them out. If I get a moment I'll update the README on requiring a new autoconf also. I was considering allowing generated DLL'd to be built out of the tree but I didn't want to be generating too many files from winebuild (and autoconf files for a whole new dll project can be quite large). Cheers, Jon

2 1

Debug info of so
by Fabian Cenedese 20 Sep '02

20 Sep '02

Hi I changed my application now from calling a Win32 dll to calling a Linux so. But of course I can't load the pdb file I have from the Windows dll. Is there something similar for Linux? How can I generate such a file and how do I tell Wine to use it? I made the so with KDEdevelop. Thanks Fabi

2 1

Call to update the 'Who's Who' page
by Jeremy Newman 20 Sep '02

20 Sep '02

It's time to update the Wine Who's Who page. http://www.winehq.com/about/index.php?who I need all current developers to send me their info for this page. It is optional to be listed here of course. If you are on the list now and do not wish be be listed let me know. I'll also take anyone's suggestions on how to improve this page. Optional info I'd like from everyone. Your name, e-mail, home page url, location, role, and bio. -- __ _WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | / -_) | | / ' \/ _` | ' \ -= jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

1 0

[Alsa-devel] update of "known bugs" list (forw)
by Joerg Mayer 20 Sep '02

20 Sep '02

----- Forwarded message from Takashi Iwai <tiwai(a)suse.de> ----- From: Takashi Iwai <tiwai(a)suse.de> Cc: alsa-devel(a)lists.sourceforge.net Subject: [Alsa-devel] update of "known bugs" list Date: Thu, 19 Sep 2002 17:46:58 +0200 Hi Patrick, the following is the update of known bugs list on the web. could you update the page? * OSS emulation on WINE --> works the following workaround is necessary on some cards/chips, which support only 16bit samples. you need to set the operation mode by writing a configuration onto /proc/asound/card0/pcm0p/oss, i.e. # echo "wine 0 0 direct" > /proc/asound/card0/pcm0p/oss * intel8x0 --> fixed all three entries are solved. * ice1712 --> changed DMX-6fire frontbox is partially working (no spdif yet) * via8233 --> fixed no problems now (on cvs it's merged together with via686 as snd-via82xx driver) New entries: * es1968 capture doesn't work. * ymfpci pcm playback is not audible on toshiba tecra8100. Takashi ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list Alsa-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ----- End forwarded message ----- -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

1 0

Re: get GetDateFormatW somewhat working...
by Vincent Béron 19 Sep '02

19 Sep '02

Le jeu 19/09/2002 à 17:25, Arthur L. Jones a écrit : [...] > > notes: it seems like, if this ever worked correctly, that > OLE_GetFormatA could be implemented by just copying > the ascii buffer and sending it along to OLE_GetFormatW? That's the easiest way of implementing both the W and A variant of an API. There are numerous examples of such behavior in Wine. For the patch, the preferred format is unified (diff -u). You can add a line "diff -u" in your .cvsrc to do it automatically. Vincent

1 0

Problem with redraw/initialization in the X11 driver
by Martin Cracauer 19 Sep '02

19 Sep '02

Hi, first of all let me say that I am impressed by the progress that wine made in the last months and I also see that working things don't get broken for long anymore. Congrats! I have one problem with a game and I think the problem might be easy to solve if you point me to the right piece of code. Basically the game (TacOps4) works fine, including all of OpenPlay.dll based networking, but there is a redraw problem with the X11 driver. When using the game in Wine, I see that Wine often draws white all over the main window of this application, and only parts which are redrawn manually by the game are rendered correctly. I think it is a safe guess that we see overcautious wine code in action here, initially the window to white with good intentions, but the application tries to optimize its redraw strategy and hence leaves all the white that wine draws. I tried switching on and off all the X11 driver options (dga etc.), but the problem was unaffected. The same problem appears in exactly the same way on Linux and FreeBSD. I am using XFree4.2 and the CVS version of DRI. I placed a screenshot showing the problem at http://www.cons.org/tmp/wine-tacops-problem.png You see that the main window is mostly white except for one item which I just dragged from the small window to the main window, where the game redrew just this area of the main window, and a second small area of the main window which the game engine redrew for whatever reason. Any suggestions about Wine code I should mess around with? Maybe there is explicit code which does this whitening that I could disable or make more clever? A demo of this game is available, showing the same symptoms, in can anybody wants to try it. ftp://ftp.battlefront.com/pub/demos/tacops4/tacops4demo_i.exe Mail me if you are unfamiliar with the game and want to see the bug fast, I don't want to clutter up this mail. Thanks! Martin

2 1

Jump to page:

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