wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

Re: Segmentation Fault
by Kye Lewis 28 Oct '02

28 Oct '02

Oh, and one other thing. If I run the setup for who wants to beat up a millionaire (it's a WISE installer), the blue 'Initializing Wise Installation Wizard' screen comes up BEFORE wine faults. > On Sun, 2002-10-27 at 21:14, Kye Lewis wrote: > > I don't know if this will help my Segmentation Fault at all, but when > > runing winedbg c:\\windows\\pbrush.exe, the Debugger actually waits for > > a command from me. > > > > If i take a step, it says: > > > > Single Stepping until exit from function, > > which has no line number information > > Stopped on breakpoint 1 at 0x0040100c (pbrush.exe.Entrypoint in > > c:\windows\pbrush.exe > > > > If i then step again > > > > Invalid address for breakpoint 0, disabling it > > ..... breakpoint 1 ..... > > ..... breakpoint 2 ..... > > Process of pid=0a24dbf0 has terminated > > > > a very odd thing happens if i run, and then step: > > > > another window pops up (gdb) and I get wine_dbg_cmd: Exception c00000005 > > in the Wine Debugger > > the gdb window says 0x402e2b41 in nanosleep () from /lib/i686/libc.so.6 > > > > and stepping in that window steps me through function nanosleep (?!?!?!) > > > > it would seem that it starts to debug wine itself! > > > > unfortunately, this window doesn't allow copy and paste, so i'll have to > > type it out for you (it may be a little incorrect): > > > > __errno_location () at errno.c:48 > > 48 return wine_errno_location(); > > > > (gdb) step > > > > thread_errno_location () at ../../include/winnt.h:1717 > > 1717 __asm__(".byte 0x64\n\tmov1 (0x18),%0" : "=r" (teb)); > > > > (gdb) step > > > > Program recieved signal SIGSEGV, Segmentation fault > > thread_errno_location () at ../../include/winnt.h:1717 > > 1717 __asm__(".byte 0x64\n\tmov1 (0x18),%0" : "=r" (teb)); > > > > (gdb) step > > > > Program recieved signal SIGCONT, Continued > > 0x40305134 in read () from /lib/i686/lib.so.6 > > > > etc... etc... etc... > > > > and it goes through a whole heck of code... > > > > The only thing that comes up in the console is > > > > Can't attach process 8072d90: error 5 > > > > Thanks, > > Kye Lewis > > kyethespy(a)liquid2k.com > > > > > > > > >

1 0

Re: Listview Z8
by Jeff Smith 28 Oct '02

28 Oct '02

Actually, I believe Klingon got rejected. Some junk about it not being a 'real' language or something. Try telling that to all the people that speak it though. Probably more than some of the other languages represented in Unicode. Maybe we should continue through the ASCII character set: 'X' 'Y' 'Z' '[' '\' ']' '^' '_' ... -- Jeff S. >From: "David D. Hagood" <wowbagger(a)sktc.net> >To: wine-devel(a)winehq.com > >Andreas Mohr wrote: > >> >>What a weak and useless suggestion, this will run out of characters in >>no time at all ;-) >>Better use Chinese characters ! > >Bah! You are still weak! Better to use Klingon - I do beleive they've >reserve some Unicode space for them! _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp

1 0

[wine application] wineinput
by yumj 28 Oct '02

28 Oct '02

http://opencjk.org/projects/wineinput/index-e.html

1 0

Treeview bug - question
by Dustin Navea 28 Oct '02

28 Oct '02

Anyone wanna take a stab at the treeview email I sent earlier, since Guy isnt actively developing anymore? I may take a look at it, but I'm not sure if I will be able to do anything with it. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/

1 0

Re: Listview Z8
by David D. Hagood 28 Oct '02

28 Oct '02

Andreas Mohr wrote: > > What a weak and useless suggestion, this will run out of characters in > no time at all ;-) > Better use Chinese characters ! Bah! You are still weak! Better to use Klingon - I do beleive they've reserve some Unicode space for them!

1 0

search for Slava Monich
by Doug Brown 27 Oct '02

27 Oct '02

Hello I used to work with Slava Monich in the period 1992-1997 thereabouts. I am interested to find him now. I found his name on some Wine web pages from Google search on his name and after not finding anything furthermore specific I ask you for help. If you have any latest and greatest contact information for this gentleman, please let me know. I tried him at monich(a)ftp.com but got denied. Thank you very much DHB

2 1

Re: Bug #321: dlls/msvct/vf[w]printf functions
by Jaco Greeff 27 Oct '02

27 Oct '02

On 27 Oct 2002 22:28:33 -0000, "Jaco Greeff" <jaco(a)puxedo.org> wrote : > Changelog: > - Test case for the printf functions to test all known cases of formatting > (test case based on example found on MSDN site) The test case is mostly the same as this example with "\t" replaced with spaces and some extra "\n" characters: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html… Output from a test run attached to this mail. Greetings, Jaco

1 0

Found problem-causing patch for treeview
by Dustin Navea 27 Oct '02

27 Oct '02

Ok, I finally found the patch that is causing treeview to not work on StarCraft (see bug #1073 for more info and the debug output) The hypermail link to the patch is: http://www.winehq.com/hypermail/wine-cvs/2002/03/0070.html I'm not sure which part of the patch caused it but that is the one causing it because cvs 1 second before that patch works fine, cvs the second of the patch does not. If someone could take a look at it and the debug output I would greatly appreciate it. I believe that this bug may also be whats causing native regedit to not show anything, but I'm not sure, that one could be listview related. -Dustin __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/

2 1

Re: Listview Z8
by Shachar Shemesh 27 Oct '02

27 Oct '02

Oh my god!!! he is running out of alphabet letters!!! ;-) Shachar Dimitrie O. Paun wrote: >ChangeLog > Mark immutable objects as const. Fix inconsisten *-style. > >--- dlls/comctl32/listview.c.Z6 2002-10-27 10:29:52.000000000 -0500 >+++ dlls/comctl32/listview.c 2002-10-27 11:24:45.000000000 -0500 >@@ -370,7 +370,7 @@ > static void LISTVIEW_GetOrigin(LISTVIEW_INFO *, LPPOINT); > static BOOL LISTVIEW_GetViewRect(LISTVIEW_INFO *, LPRECT); > static void LISTVIEW_SetGroupSelection(LISTVIEW_INFO *, INT); >-static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *, LPLVITEMW, BOOL); >+static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *, const LVITEMW *, BOOL); > static void LISTVIEW_UpdateScroll(LISTVIEW_INFO *); > static void LISTVIEW_SetSelection(LISTVIEW_INFO *, INT); > static void LISTVIEW_UpdateSize(LISTVIEW_INFO *); >@@ -380,7 +380,7 @@ > static INT LISTVIEW_GetStringWidthT(LISTVIEW_INFO *, LPCWSTR, BOOL); > static BOOL LISTVIEW_KeySelection(LISTVIEW_INFO *, INT); > static UINT LISTVIEW_GetItemState(LISTVIEW_INFO *, INT, UINT); >-static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *, INT, LPLVITEMW); >+static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *, INT, const LVITEMW *); > static LRESULT LISTVIEW_VScroll(LISTVIEW_INFO *, INT, INT, HWND); > static LRESULT LISTVIEW_HScroll(LISTVIEW_INFO *, INT, INT, HWND); > static INT LISTVIEW_GetTopIndex(LISTVIEW_INFO *); >@@ -469,7 +469,7 @@ > /* > * compares a Unicode to a Unicode/ANSI text string > */ >-static inline int textcmpWT(LPWSTR aw, LPWSTR bt, BOOL isW) >+static inline int textcmpWT(LPCWSTR aw, LPCWSTR bt, BOOL isW) > { > if (!aw) return bt ? -1 : 0; > if (!bt) return aw ? 1 : 0; >@@ -517,7 +517,7 @@ > return buffers[index++ % DEBUG_BUFFERS]; > } > >-static inline char* debugrange(const RANGE* lprng) >+static inline char* debugrange(const RANGE *lprng) > { > if (lprng) > { >@@ -527,7 +527,7 @@ > } else return "(null)"; > } > >-static inline char* debugpoint(const POINT* lppt) >+static inline char* debugpoint(const POINT *lppt) > { > if (lppt) > { >@@ -537,7 +537,7 @@ > } else return "(null)"; > } > >-static inline char* debugrect(const RECT* rect) >+static inline char* debugrect(const RECT *rect) > { > if (rect) > { >@@ -580,7 +580,7 @@ > return text; > } > >-static char* debugnmlistview(LPNMLISTVIEW plvnm) >+static char* debugnmlistview(const NMLISTVIEW *plvnm) > { > if (plvnm) > { >@@ -593,7 +593,7 @@ > } else return "(null)"; > } > >-static char* debuglvitem_t(LPLVITEMW lpLVItem, BOOL isW) >+static char* debuglvitem_t(const LVITEMW *lpLVItem, BOOL isW) > { > char* buf = debug_getbuf(), *text = buf; > int len, size = DEBUG_BUFFER_SIZE; >@@ -629,7 +629,7 @@ > return text; > } > >-static char* debuglvcolumn_t(LPLVCOLUMNW lpColumn, BOOL isW) >+static char* debuglvcolumn_t(const LVCOLUMNW *lpColumn, BOOL isW) > { > char* buf = debug_getbuf(), *text = buf; > int len, size = DEBUG_BUFFER_SIZE; >@@ -670,7 +670,7 @@ > } > > >-static char* debuglvhittestinfo(LPLVHITTESTINFO lpht) >+static char* debuglvhittestinfo(const LVHITTESTINFO *lpht) > { > if (lpht) > { >@@ -817,7 +817,7 @@ > return bResult; > } > >-static void customdraw_fill(NMLVCUSTOMDRAW *lpnmlvcd, LISTVIEW_INFO *infoPtr, HDC hdc, LPRECT rcBounds) >+static void customdraw_fill(NMLVCUSTOMDRAW *lpnmlvcd, LISTVIEW_INFO *infoPtr, HDC hdc, const RECT *rcBounds) > { > ZeroMemory(lpnmlvcd, sizeof(NMLVCUSTOMDRAW)); > lpnmlvcd->nmcd.hdc = hdc; >@@ -1045,7 +1045,7 @@ > /*** > * Creates an iterator over the items which intersect lprc. > */ >-static BOOL iterator_frameditems(ITERATOR* i, LISTVIEW_INFO* infoPtr, const RECT* lprc) >+static BOOL iterator_frameditems(ITERATOR* i, LISTVIEW_INFO* infoPtr, const RECT *lprc) > { > UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; > RECT frame = *lprc, rcItem, rcTemp; >@@ -1130,7 +1130,7 @@ > /*** > * Creates an iterator over the items which intersect the visible region of hdc. > */ >-static BOOL iterator_visibleitems(ITERATOR* i, LISTVIEW_INFO *infoPtr, HDC hdc) >+static BOOL iterator_visibleitems(ITERATOR *i, LISTVIEW_INFO *infoPtr, HDC hdc) > { > POINT Origin, Position; > RECT rcItem, rcClip; >@@ -1705,7 +1705,7 @@ > * RETURN: > * None. > */ >-static void LISTVIEW_GetItemMetrics(LISTVIEW_INFO *infoPtr, LVITEMW *lpLVItem, >+static void LISTVIEW_GetItemMetrics(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem, > LPRECT lprcBox, LPRECT lprcState, > LPRECT lprcIcon, LPRECT lprcLabel) > { >@@ -2018,7 +2018,7 @@ > * Success: TRUE > * Failure: FALSE > */ >-static BOOL LISTVIEW_MoveIconTo(LISTVIEW_INFO *infoPtr, INT nItem, LPPOINT lppt, BOOL isNew) >+static BOOL LISTVIEW_MoveIconTo(LISTVIEW_INFO *infoPtr, INT nItem, const POINT *lppt, BOOL isNew) > { > POINT old; > >@@ -3039,7 +3039,7 @@ > /*** > * Tests wheather the item is assignable to a list with style lStyle > */ >-static inline BOOL is_assignable_item(LPLVITEMW lpLVItem, LONG lStyle) >+static inline BOOL is_assignable_item(const LVITEMW *lpLVItem, LONG lStyle) > { > if ( (lpLVItem->mask & LVIF_TEXT) && > (lpLVItem->pszText == LPSTR_TEXTCALLBACKW) && >@@ -3064,7 +3064,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL set_main_item(LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVItem, BOOL isNew, BOOL isW, BOOL *bChanged) >+static BOOL set_main_item(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem, BOOL isNew, BOOL isW, BOOL *bChanged) > { > ITEM_INFO *lpItem; > NMLISTVIEW nmlv; >@@ -3199,7 +3199,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL set_sub_item(LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVItem, BOOL isW, BOOL *bChanged) >+static BOOL set_sub_item(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem, BOOL isW, BOOL *bChanged) > { > HDPA hdpaSubItems; > SUBITEM_INFO *lpSubItem; >@@ -3271,7 +3271,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVItem, BOOL isW) >+static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem, BOOL isW) > { > UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; > LPWSTR pszText = NULL; >@@ -3286,7 +3286,7 @@ > if ((lpLVItem->mask & LVIF_TEXT) && is_textW(lpLVItem->pszText)) > { > pszText = lpLVItem->pszText; >- lpLVItem->pszText = textdupTtoW(lpLVItem->pszText, isW); >+ ((LVITEMW *)lpLVItem)->pszText = textdupTtoW(lpLVItem->pszText, isW); > } > > /* actually set the fields */ >@@ -3311,7 +3311,7 @@ > if (pszText) > { > textfreeT(lpLVItem->pszText, isW); >- lpLVItem->pszText = pszText; >+ ((LVITEMW *)lpLVItem)->pszText = pszText; > } > > return bResult; >@@ -3372,7 +3372,7 @@ > * Success: TRUE > * Failure: FALSE > */ >-static inline BOOL LISTVIEW_FillBkgnd(LISTVIEW_INFO *infoPtr, HDC hdc, const RECT* lprcBox) >+static inline BOOL LISTVIEW_FillBkgnd(LISTVIEW_INFO *infoPtr, HDC hdc, const RECT *lprcBox) > { > if (!infoPtr->hBkBrush) return FALSE; > >@@ -4410,7 +4410,7 @@ > * FAILURE : -1 > */ > static INT LISTVIEW_FindItemW(LISTVIEW_INFO *infoPtr, INT nStart, >- LPLVFINDINFOW lpFindInfo) >+ const LVFINDINFOW *lpFindInfo) > { > UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; > WCHAR szDispText[DISP_TEXT_SIZE] = { '\0' }; >@@ -4540,7 +4540,7 @@ > * FAILURE : -1 > */ > static INT LISTVIEW_FindItemA(LISTVIEW_INFO *infoPtr, INT nStart, >- LPLVFINDINFOA lpFindInfo) >+ const LVFINDINFOA *lpFindInfo) > { > BOOL hasText = lpFindInfo->flags & (LVFI_STRING | LVFI_PARTIAL); > LVFINDINFOW fiw; >@@ -5722,7 +5722,7 @@ > * SUCCESS : new item index > * FAILURE : -1 > */ >-static INT LISTVIEW_InsertItemT(LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVItem, BOOL isW) >+static INT LISTVIEW_InsertItemT(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem, BOOL isW) > { > UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; > INT nItem; >@@ -5934,7 +5934,7 @@ > /* LISTVIEW_SetBkImage */ > > /*** Helper for {Insert,Set}ColumnT *only* */ >-static void column_fill_hditem(LISTVIEW_INFO *infoPtr, HDITEMW *lphdi, INT nColumn, LPLVCOLUMNW lpColumn, BOOL isW) >+static void column_fill_hditem(LISTVIEW_INFO *infoPtr, HDITEMW *lphdi, INT nColumn, const LVCOLUMNW *lpColumn, BOOL isW) > { > if (lpColumn->mask & LVCF_FMT) > { >@@ -6021,7 +6021,7 @@ > * FAILURE : -1 > */ > static INT LISTVIEW_InsertColumnT(LISTVIEW_INFO *infoPtr, INT nColumn, >- LPLVCOLUMNW lpColumn, BOOL isW) >+ const LVCOLUMNW *lpColumn, BOOL isW) > { > COLUMN_INFO *lpColumnInfo; > INT nNewColumn; >@@ -6126,7 +6126,7 @@ > * FAILURE : FALSE > */ > static BOOL LISTVIEW_SetColumnT(LISTVIEW_INFO *infoPtr, INT nColumn, >- LPLVCOLUMNW lpColumn, BOOL isW) >+ const LVCOLUMNW *lpColumn, BOOL isW) > { > HDITEMW hdi, hdiget; > BOOL bResult; >@@ -6178,7 +6178,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL LISTVIEW_SetColumnOrderArray(LISTVIEW_INFO *infoPtr, INT iCount, LPINT lpiArray) >+static BOOL LISTVIEW_SetColumnOrderArray(LISTVIEW_INFO *infoPtr, INT iCount, const INT *lpiArray) > { > FIXME("iCount %d lpiArray %p\n", iCount, lpiArray); > >@@ -6672,7 +6672,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *infoPtr, INT nItem, LPLVITEMW lpLVItem) >+static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *infoPtr, INT nItem, const LVITEMW *lpLVItem) > { > BOOL bResult = TRUE; > LVITEMW lvItem; >@@ -6710,7 +6710,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL LISTVIEW_SetItemTextT(LISTVIEW_INFO *infoPtr, INT nItem, LPLVITEMW lpLVItem, BOOL isW) >+static BOOL LISTVIEW_SetItemTextT(LISTVIEW_INFO *infoPtr, INT nItem, const LVITEMW *lpLVItem, BOOL isW) > { > LVITEMW lvItem; > >@@ -6946,7 +6946,7 @@ > * Success: 0 > * Failure: -1 > */ >-static LRESULT LISTVIEW_Create(HWND hwnd, LPCREATESTRUCTW lpcs) >+static LRESULT LISTVIEW_Create(HWND hwnd, const CREATESTRUCTW *lpcs) > { > LISTVIEW_INFO *infoPtr; > UINT uView = lpcs->style & LVS_TYPEMASK; >@@ -7680,7 +7680,7 @@ > * RETURN: > * Zero > */ >-static LRESULT LISTVIEW_HeaderNotification(LISTVIEW_INFO *infoPtr, LPNMHEADERW lpnmh) >+static LRESULT LISTVIEW_HeaderNotification(LISTVIEW_INFO *infoPtr, const NMHEADERW *lpnmh) > { > UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; > >@@ -8160,7 +8160,7 @@ > * Zero > */ > static INT LISTVIEW_StyleChanged(LISTVIEW_INFO *infoPtr, WPARAM wStyleType, >- LPSTYLESTRUCT lpss) >+ const STYLESTRUCT *lpss) > { > UINT uNewView = lpss->styleNew & LVS_TYPEMASK; > UINT uOldView = lpss->styleOld & LVS_TYPEMASK; > > > > >

3 2

How is Win/Dos syscalls implemented in Wine?
by Peter Andersson 27 Oct '02

27 Oct '02

Hello! Perhaps someone can give me a good answer to this question. Please give me a direct answer, I have allready been trouh the wine FAQ:s , docs, code, etc. I know DOS syscalls is made using interupts (int instruction) but, is Windows/NT syscalls made the same way. How does wine stop these instructions from reaching the unix kernel?

5 22

License query
by Matthew Bloch 27 Oct '02

27 Oct '02

I'm porting a closed-source game to Linux, and as a stop-gap I'd like to get a version out using WINE until I can rewrite the Direct(Sound|Draw|3D) backends with SDL. After reading this post: http://lists.debian.org/debian-devel/2002/debian-devel-200205/msg02823.html and then downloading the source from the winehq.com cvs, I'm confused as to my options. The LICENSE file implies that the ddraw DLL is transgaming's IP but the files themselves have LGPL declarations at the top. In short, am I within my rights to release a statically linked binary which uses the core WINE source code, providing I comply with the other terms of the LGPL? I notice some files have Transgaming's name on them, but appear to be LGPL. I think I'm within my rights, but not sure: the post above gives me most of the information that explains this state of affairs, but not everything. Any further pointers on WINE licensing history would be appreciated. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

2 2

Re: Segmentation Fault
by Kye Lewis 27 Oct '02

27 Oct '02

I don't know if this will help my Segmentation Fault at all, but when runing winedbg c:\\windows\\pbrush.exe, the Debugger actually waits for a command from me. If i take a step, it says: Single Stepping until exit from function, which has no line number information Stopped on breakpoint 1 at 0x0040100c (pbrush.exe.Entrypoint in c:\windows\pbrush.exe If i then step again Invalid address for breakpoint 0, disabling it ..... breakpoint 1 ..... ..... breakpoint 2 ..... Process of pid=0a24dbf0 has terminated a very odd thing happens if i run, and then step: another window pops up (gdb) and I get wine_dbg_cmd: Exception c00000005 in the Wine Debugger the gdb window says 0x402e2b41 in nanosleep () from /lib/i686/libc.so.6 and stepping in that window steps me through function nanosleep (?!?!?!) it would seem that it starts to debug wine itself! unfortunately, this window doesn't allow copy and paste, so i'll have to type it out for you (it may be a little incorrect): __errno_location () at errno.c:48 48 return wine_errno_location(); (gdb) step thread_errno_location () at ../../include/winnt.h:1717 1717 __asm__(".byte 0x64\n\tmov1 (0x18),%0" : "=r" (teb)); (gdb) step Program recieved signal SIGSEGV, Segmentation fault thread_errno_location () at ../../include/winnt.h:1717 1717 __asm__(".byte 0x64\n\tmov1 (0x18),%0" : "=r" (teb)); (gdb) step Program recieved signal SIGCONT, Continued 0x40305134 in read () from /lib/i686/lib.so.6 etc... etc... etc... and it goes through a whole heck of code... The only thing that comes up in the console is Can't attach process 8072d90: error 5 Thanks, Kye Lewis kyethespy(a)liquid2k.com

1 0

Re: dlls/user: w[v]snprintf[A|W] fixes
by David Laight 27 Oct '02

27 Oct '02

> > > Changelog: > > * dlls/user/wsprintf.c Jaco Greeff <jaco(a)puxedo.org> > > - Changed the wsprintf[A|W] and wvsprintf[A|W] functions to > > determine the size of the destination buffer before writing > > to it. Previously the size was hardcoded to 1024 bytes. > > The size is supposed to be hardcoded to 1024, that's how wsprintf > works. You can't make it dynamic since the buffer is allocated by the > application. Seems to me (from info in a later post) that M$ wsprintf uses an internal temporary buffer that has a size of 1024 - thus resticting the user to a buffer size of 1024, The actual size of the user buffer cannot be determined - hence the common 'buffer overflow' issues with sprintf. The C standard now includes snprintf() where the application passes in the length of the target buffer. I guess M$ might follow :-) Some systems also have an asprintf() routine which will malloc() a buffer that the caller must free(). David -- David Laight: david(a)l8s.co.uk

1 0

Segmentation Fault
by Kye Lewis 27 Oct '02

27 Oct '02

Hi, Not really sure if this is the right place to post this, but as i'm signed up to it; My version of wine has suddenly started Seg Faulting on startup. The last thing I tried with wine was netmeeting. This is with cvs version from 26th October at about 2:00 Australian Eastern Standard Time ( not sure what that is GMT - it was about 5 hours before posting this message ) Any help would be appreciated. Thanks, Kye Lewis kyethespy(a)liquid2k.com

3 5

Re: dlls/user: w[v]snprintf[A|W] fixes
by Jaco Greeff 27 Oct '02

27 Oct '02

On 26 Oct 2002 14:57:53 -0700, Alexandre Julliard <julliard(a)winehq.com> wrote : > The size is supposed to be hardcoded to 1024, that's how wsprintf > works. You can't make it dynamic since the buffer is allocated by the > application. >From MSDN: "Pointer to a buffer to receive the formatted output. The maximum size of the buffer is 1024 bytes." The question I need to ask myself now is what function reference did I compare this one to when I searched there?

1 0

[RFC] creating Wine's own 'assert' variant
by Lionel Ulmer 26 Oct '02

26 Oct '02

Hi all, Currently, Wine's code is full of 'asserts'. The problem I have with that if that when such an assert is reached, only the thread being asserted is aborted, but Wine is not 'shut down' properly. Moreover, if I want the debugger to be launched on assert, I would need first to start the application with the debugger and add a breakpoint on some libc internal function. So, don't you think it would be better to have our own 'wine_assert' macro / function that could be configurable (ie abort or start the debugger) and that would also shut-down Wine properly ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

4 5

Re: interrupts in when in NT version
by John K. Hohm 26 Oct '02

26 Oct '02

> Tough all safedisc programs depend on this, I have decided not to make an > official patch. The reason is that additional info is needed for a proper > fix. Safedisc depends on that EXCEPTION_ACCESS_VIOLATION is returned on an > int 0x01 call. But it should be checked what exceptions are raised on > different windows versions when int 0x01 is called. And maybe the same should > be done with other interrupts. > It would be good if somebody could make that test program. Else I will keep > the non proper fix. You may think me a rube, but I just made a test program that calls an arbitrary interrupt and prints the exception information. I don't set up any registers, so perhaps it generates an exception when it ought not in some cases, but anyone else is free to improve it. Source and a VC6-compiled MSVCRT-using version, along with results for all 255 interrupts on Windows XP Professional, is here: http://petra.trnty.edu/~jhohm/intexcep.zip

2 1

Re: dlls/user: w[v]snprintf[A|W] fixes
by Alexandre Julliard 26 Oct '02

26 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> writes: > Changelog: > * dlls/user/wsprintf.c Jaco Greeff <jaco(a)puxedo.org> > - Changed the wsprintf[A|W] and wvsprintf[A|W] functions to > determine the size of the destination buffer before writing > to it. Previously the size was hardcoded to 1024 bytes. The size is supposed to be hardcoded to 1024, that's how wsprintf works. You can't make it dynamic since the buffer is allocated by the application. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: msvcrt: printf family (Bug #321)
by Alexandre Julliard 26 Oct '02

26 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> writes: > * dlls/msvcrt/file.c Jaco Greeff <jaco(a)puxedo.org> > - Allow for the processing of %S and %C format specifiers as per > bug #321 > - Code duplicated/shared between dlls/user/wsprintf.c, > dlls/shlwapi/wsprintf.c and now dlls/msvcrt/file.c That's not correct. wsprintf is not a normal printf, it lacks a lot of features so it's not good enough for msvcrt. We either need a full printf implementation in msvcrt, or we need to patch the %S/%C in the format string and call the libc printf. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: DSTRICT: commdlg
by Dimitrie O. Paun 26 Oct '02

26 Oct '02

On October 26, 2002 11:14 am, Matthew Davison wrote: > - hInst = GetWindowLongA( lpofn->hwndOwner, GWL_HINSTANCE ); > + hInst = (HINSTANCE)(ULONG_PTR)GetWindowLongA( lpofn->hwndOwner, GWL_HINSTANCE ); Why can't you cast here directly to HINSTANCE? -- Dimi.

2 1

Control Panel Application does not start
by Stefan Leichter 26 Oct '02

26 Oct '02

Hello, i am currently tracking down a problem with a program (Nokia PC Suite 4; NclConf.exe) that is unable to start its control panel application. The control panel application should be started by the rundll32.exe. It does not get started because of the path in the filename. The applet is searched in the correct directory but it does not get found because the path was not stripped from the filename. So a filename with path is compared to the filename without path read from the directoy. This will never match. I have attached a logfile with the relevant line (i hope). Will please someone be so kind and look at it and tell me what ithe reason for the problem is. Thanks Stefan -------------------------------------------------------------------------------------------------------------------------- 0831f930:Call shell32.Control_RunDLL(00020025,00400000,40370bb5,0000000a) ret=00401380 0831f930:Call kernel32.LoadLibraryA(403d0028 "\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"") ret=409bb0f4 trace:dosfs:DOSFS_GetFullName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" (last=1) trace:string:lstrcpynA (0x406d1c50, "/wine_app/wine_app", 1024) trace:string:lstrcpynA (0x406d1c63, "Programme/Gemeinsame Dateien/Nokia/NCLTools", 1005) trace:string:lstrcpynW (0x406d2056, L"PROG~1F2\\GEME~SR3\\NOKIA\\NCLTOOLS", 1021) trace:dosfs:DOSFS_FindUnixName /wine_app/wine_app/Programme/Gemeinsame Dateien/Nokia/NCLTools,L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" trace:dosfs:DOSFS_ToDosFCBFormat (L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"", 0x406d1b78) trace:dosfs:DOSFS_OpenDir "/wine_app/wine_app/Programme/Gemeinsame Dateien/Nokia/NCLTools" trace:dosfs:DOSFS_ReadDir Read: long_name: L".", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"." trace:dosfs:DOSFS_ReadDir Read: long_name: L"..", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L".." trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_I.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_I.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_D.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_D.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_E.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_E.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_F.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_F.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_G.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_G.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_N.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_N.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_S.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_S.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_SV.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_SV.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NclConf.exe", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NclConf.exe" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NclConf.cpl", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NclConf.cpl" warn:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" not found in '/wine_app/wine_app/Programme/Gemeinsame Dateien/Nokia/NCLTools' warn:module:MODULE_LoadLibraryExA Failed to load module 'C:\WINDOWS\SYSTEM32'; error=2 0831f930:Ret kernel32.LoadLibraryA() retval=00000000 ret=409bb0f4 0831f930:Call kernel32.FreeLibrary(00000000) ret=409bb088 0831f930:Ret kernel32.FreeLibrary() retval=00000000 ret=409bb088 0831f930:Ret shell32.Control_RunDLL() retval=00000001 ret=00401380

4 7

Re: DSTRICT: commdlg
by Dimitrie O. Paun 26 Oct '02

26 Oct '02

On October 26, 2002 11:14 am, Matthew Davison wrote: > - chf32a->hInstance=chf16->hInstance; > + chf32a->hInstance=(HINSTANCE)(ULONG_PTR)chf16->hInstance; Shouldn't we have a HINSTANCE_32 macro, for uniformity? -- Dimi.

2 1

Re: DSTRICT: commdlg
by Dimitrie O. Paun 26 Oct '02

26 Oct '02

On October 26, 2002 11:14 am, Matthew Davison wrote: > - bRet = DialogBoxIndirectParam16( hInst, lfs->hDlgTmpl16, lpofn->hwndOwner, > + bRet = DialogBoxIndirectParam16( (HINSTANCE16)LOWORD(hInst), lfs->hDlgTmpl16, lpofn->hwndOwner, And here we should have a HINSTANCE_16 macro... -- Dimi.

1 0

Re: DSTRICT: commdlg
by Dimitrie O. Paun 26 Oct '02

26 Oct '02

On October 26, 2002 11:14 am, Matthew Davison wrote: > - FillRect(hDC, &lpp->old3angle, GetClassLongA( hwnd, GCL_HBRBACKGROUND)); > + FillRect((HDC)hDC, &lpp->old3angle, (HBRUSH)GetClassLongA( hwnd, GCL_HBRBACKGROUND)); This is not right. At that point, hDC should be a HDC, if it's not, you have to modify the code around it. Such casting should happen in the WindowProc, all functions should work with the proper type. Alexandre, please do not apply the patch in this form: it silence warnings, and it makes it very difficult to properly correct the code in the future. -- Dimi.

1 0

Re: interrupts in when in NT version
by Zsolt Rizsanyi 26 Oct '02

26 Oct '02

I have forgotten to cc this discussion to wine-devel. But who is interested can catch up from this mail. On Saturday 26 October 2002 14:07, Eric Pouech wrote: > > > > Could somebody answer/test if calling interrupt int 0x01 is allowed > > > > from a win32 program in WinNT environment? I would pretty like to > > > > know that! > > > > > > I don't think it is > > > > Should I write then a patch, which would deny calling of int 0x01 from > > win32 code when winver is NT? > > Would that be applied? > > the rule of thumb is: if there's a program which depends on this to be > implemented, then yes patch will be applied > otherwise, leave it as it is Tough all safedisc programs depend on this, I have decided not to make an official patch. The reason is that additional info is needed for a proper fix. Safedisc depends on that EXCEPTION_ACCESS_VIOLATION is returned on an int 0x01 call. But it should be checked what exceptions are raised on different windows versions when int 0x01 is called. And maybe the same should be done with other interrupts. It would be good if somebody could make that test program. Else I will keep the non proper fix. > > > it was allowed on Win9x, and is used in this context IIRC as a ring 3 > > > to ring 0 transition code (how to create a cheap call gate) > > > > How good it would be if I could understand what you are speaking about :( > > But could you explain what a call gate is? > > If it is too long, then dont bother tough... > > I'll try to make it short > context: > - i386 have 4 levels of privilege => ring 3 (less privilege) up to ring > 0 > - certain operations are only allowed at ring 0 (or 1) > - user code runs in ring 3 > - kernel code runs in ring 0 (to be exact, NT had been designed to have > kernel in ring 0, and device drivers in ring 1, but this has been > altered - some drivers run in ring 0 too) > - you can always call into a less priviledged level (ring 0 => ring 3 > for example) > - the other way around requires what is known as call gates (ring 0 for > example defines the "entry points" in some way) > - most of the interrupt handlers run in ring 0 > > what the safedisc code was doing was: > 0/ code is running in ring 3 > 1/ install an interrupt handler for division by zero (IIRC) > 2/ trigger the division > 3/ have the interrupt handler called, but this is done in ring 0, even > if the code has been loaded from a user space program. here, in the > interrupt handler, you can do any ring 0 operation you want > > that's why I called it a cheap call gate (no real call gate has been > installed, and the code run in ring 0 isn't decided by the kernel but > the app) > > NT doesn't allow this to run. step 1 is not allowed (only the kernel can > decide to change an interrupt handler, which makes lots of sense) Thanks for the detailed explanation. And for completeness I will include here the explanation of Laurent Pinchart why a safedisc program calls int 0x01 : > - the last attempt to detect a debugger uses int 0x01 (enter SMM/ICE mode), > which checks if an external hardware emulator is connected to the > processor. I haven't been able to understand what the code is supposed to > do. Regards Zsolt

1 0

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