Folks, After a bit of hacking, I've got the Visual-MinGW project to compile, and link just fine. Problem is that it does not run. Dies right away with a segmentation fault, so I think I've messed something up with the building part. So, to help you help me, I've included the following: -- the command lines used to build the darn thing -- the script I've created to start the program -- an attempt to run it -- the last lines of a strace on the program Help with this would be greatly appreciated. BUILDING ======== I've not included the makefile, it's irrelevant I think, as long as the actual gcc invocations are here, right? [dimi(a)dimi src]$ make g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o CList.o CList.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o editor.o editor.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o main.o main.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o process.o process.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o project.o project.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o winui.o winui.cpp winui.cpp: In constructor `CShellDlg::CShellDlg()': winui.cpp:2062: warning: comparison between signed and unsigned integer expressions /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lntdll -lmsvcrt gcc -W -Wall -fPIC -DSTRICT -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm SCRIPT ====== #!/bin/sh appdir="/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src" winedir="/home/dimi/dev/wine/wine" LD_LIBRARY_PATH="$winedir/dlls:$winedir/library:$winedir/unicode:$LD_LIBRARY_PATH" WINEDLLPATH="$winedir/dlls" WINESERVER="$winedir/server/wineserver" WINELOADER="$winedir/miscemu/wine" export LD_LIBRARY_PATH WINEDLLPATH WINESERVER WINELOADER # and run the application exec "$WINELOADER" "$appdir/$0.exe.so" "$@" RUNNING ======= Not very exciting, is it? :( [dimi(a)dimi src]$ ./visual-mingw Segmentation fault STRACE ====== open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw", O_RDONLY|O_LARGEFILE) = 9 ioctl(9, VFAT_IOCTL_READDIR_BOTH, 0xbfffe6d0) = -1 ENOTTY (Inappropriate ioctl for device) close(9) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9 fstat64(9, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 280 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 0 close(9) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src", O_RDONLY|O_LARGEFILE) = 9 ioctl(9, VFAT_IOCTL_READDIR_BOTH, 0xbfffe6d0) = -1 ENOTTY (Inappropriate ioctl for device) close(9) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9 fstat64(9, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 1160 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 0 close(9) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [RTMIN], 8) = 0 write(4, "\24\0\0\0\0\0\0\0\0\0\0\0\30\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 close(6) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src/visual-mingw.exe.so", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\300\0"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0775, st_size=284747, ...}) = 0 old_mmap(NULL, 265292, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x40560000 mprotect(0x40596000, 44108, PROT_NONE) = 0 old_mmap(0x40596000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x36000) = 0x40596000 old_mmap(0x4059d000, 15436, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4059d000 close(6) = 0 open("/home/dimi/dev/wine/wine/dlls/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/library/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/unicode/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0644, st_size=76534, ...}) = 0 old_mmap(NULL, 76534, PROT_READ, MAP_PRIVATE, 6, 0) = 0x40205000 close(6) = 0 open("/usr/lib/libstdc++.so.5", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\246"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0755, st_size=4181584, ...}) = 0 old_mmap(NULL, 727004, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x405a1000 mprotect(0x40639000, 104412, PROT_NONE) = 0 old_mmap(0x40639000, 86016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x98000) = 0x40639000 old_mmap(0x4064e000, 18396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4064e000 close(6) = 0 open("/home/dimi/dev/wine/wine/dlls/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/library/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/unicode/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libgcc_s.so.1", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\10\23\0"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0755, st_size=854160, ...}) = 0 old_mmap(NULL, 32288, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x40248000 mprotect(0x4024f000, 3616, PROT_NONE) = 0 old_mmap(0x4024f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x7000) = 0x4024f000 close(6) = 0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ -- Dimi.
--- "Dimitrie O. Paun" <dpaun(a)rogers.com> a écrit : > Folks,
After a bit of hacking, I've got the Visual-MinGW project to compile, and link just fine. Problem is that it does not run. Dies right away with a segmentation fault, so I think I've messed something up with the building part.
did you give a try with winedbg ?
RUNNING ======= Not very exciting, is it? :(
[dimi(a)dimi src]$ ./visual-mingw Segmentation fault
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
if winedbg doesn't even start, we can say without risk of error that you have a problem in your wine tree. it's 'make distclean' time. --- "Dimitrie O. Paun" <dpaun(a)rogers.com> a écrit : > On November 20, 2002 03:55 am, Sylvain Petreolle wrote:
did you give a try with winedbg ?
winedbg doesn't start. a +debugmsg +relay doesn't give anything, I think the seg fault happens during the loading. Check out the strace output...
-- Dimi.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On November 20, 2002 02:01 pm, Sylvain Petreolle wrote:
if winedbg doesn't even start, we can say without risk of error that you have a problem in your wine tree. it's 'make distclean' time.
No, my tree is perfect, everything works OK. The problem is with _this_ app only, I'm doing something wrong during building: compilation and/or linking. Or maybe the startup script? -- Dimi.
On November 20, 2002 05:58 pm, Dimitrie O. Paun wrote:
Or maybe the startup script?
No, it's not the startup script. If I just replace the appdir with notepad's, everything works fine. So the script is just fine. It's the building people... Can it be because it's a C++ app? -- Dimi.
On November 20, 2002 06:05 pm, Dimitrie O. Paun wrote:
It's the building, people... Can it be because it's a C++ app?
Yes, it's the C++ thingy that screws it up. I've compiled putty just the same, and it works perfectly. Now, this is a very simple application, really, why would it die like this? -- Dimi.
--- "Dimitrie O. Paun" <dpaun(a)rogers.com> a écrit : > On November 20, 2002 02:01 pm, Sylvain Petreolle wrote:
if winedbg doesn't even start, we can say without risk of error that you have a problem in your wine tree. it's 'make distclean' time.
No, my tree is perfect, everything works OK. The problem is with _this_ app only, I'm doing something wrong during building: compilation and/or linking. Or maybe the startup script?
I don't understand you here. you said winedbg doesnt start. winedbg doesn't start. a +debugmsg +relay doesn't give anything, I think the seg fault happens during the loading. Check out the strace output... ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On November 20, 2002 08:33 pm, Sylvain Petreolle wrote:
I don't understand you here. you said winedbg doesnt start.
Sorry, I wasn't clear. If I do: [dimi(a)dimi src]$ /home/dimi/dev/wine/wine/programs/winedbg/winedbg It comes up just fine. But if I do: [dimi(a)dimi src]$ /home/dimi/dev/wine/wine/programs/winedbg/winedbg visual-mingw.exe.so It just stays there forever... -- Dimi.
Hi Dimi, I have been doing some work on OWNERDATA listviews with Outlook and have found something with my test programs. Even if i create a Dialog with DialogBoxW to contain the listview, and return NFR_UNICODE for WM_NOTIFYFORMAT my windows 2000 box still calls notifies with LVN_GETDISPINFOA and NOT LVN_GETDISPINFOW. I wondered if you had found a counter example in your own tests, or if you had just assumed that windows would act rationally. If it was an assumption then I will happily make a patch that mimic the behavior of my test program. If you have your own windows test program that shows other behavior maybe you can send it to me and we can see what is wrong with my test program. thanks -aric
On November 21, 2002 10:19 am, Aric Stewart wrote:
I wondered if you had found a counter example in your own tests, or if you had just assumed that windows would act rationally. If it was an assumption then I will happily make a patch that mimic the behavior of my test program. If you have your own windows test program that shows other behavior maybe you can send it to me and we can see what is wrong with my test program.
Actually, I don't have a test for the WM_NOTIFYFORMAT. In fact, I was just looking at it, trying to compare it to the Treeview case which doesn't work at the moment, and I think the one in Listview is buggy, at least according to the documentation. To cut a long story short: yeah, a patch is greatly appreciated! :) BTW, this is the problem with the Treeview as well, if I understand correctly. It is asked in WM_NOTIFYFORMAT to be Unicode, but when it does, nothing works. So my question is: when is a control supposed to be Unicode? WTF is going on here??? -- Dimi.
Here is a patch which preserves alot of your structure. it works to correct my bug in Outlook. -aric Dimitrie O. Paun wrote:
On November 21, 2002 10:19 am, Aric Stewart wrote:
I wondered if you had found a counter example in your own tests, or if you had just assumed that windows would act rationally. If it was an assumption then I will happily make a patch that mimic the behavior of my test program. If you have your own windows test program that shows other behavior maybe you can send it to me and we can see what is wrong with my test program.
Actually, I don't have a test for the WM_NOTIFYFORMAT. In fact, I was just looking at it, trying to compare it to the Treeview case which doesn't work at the moment, and I think the one in Listview is buggy, at least according to the documentation. To cut a long story short: yeah, a patch is greatly appreciated! :)
BTW, this is the problem with the Treeview as well, if I understand correctly. It is asked in WM_NOTIFYFORMAT to be Unicode, but when it does, nothing works. So my question is: when is a control supposed to be Unicode? WTF is going on here???
Index: dlls/comctl32/listview.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/listview.c,v retrieving revision 1.330 diff -u -r1.330 listview.c --- dlls/comctl32/listview.c 18 Nov 2002 19:51:11 -0000 1.330 +++ dlls/comctl32/listview.c 21 Nov 2002 16:30:44 -0000 @@ -764,8 +764,10 @@ } /* - Send notification. depends on dispinfoW having same - structure as dispinfoA. + With testing on Windows 2000 it looks like the notify format + has nothing to do with this message. It ALWAYS seems to be + in ansi format. + infoPtr : listview struct notificationCode : *Unicode* notification code pdi : dispinfo structure (can be unicode or ansi) @@ -774,61 +776,49 @@ static BOOL notify_dispinfoT(LISTVIEW_INFO *infoPtr, INT notificationCode, LPNMLVDISPINFOW pdi, BOOL isW) { BOOL bResult = FALSE; - BOOL convertToAnsi = FALSE, convertToUnicode = FALSE; - INT realNotifCode; + BOOL convertToAnsi = FALSE; INT cchTempBufMax = 0, savCchTextMax = 0; LPWSTR pszTempBuf = NULL, savPszText = NULL; if ((pdi->item.mask & LVIF_TEXT) && is_textT(pdi->item.pszText, isW)) - { - convertToAnsi = (isW && infoPtr->notifyFormat == NFR_ANSI); - convertToUnicode = (!isW && infoPtr->notifyFormat == NFR_UNICODE); - } + convertToAnsi = isW; - if (convertToAnsi || convertToUnicode) + if (convertToAnsi) { - if (notificationCode != LVN_GETDISPINFOW) - { - cchTempBufMax = convertToUnicode ? - MultiByteToWideChar(CP_ACP, 0, (LPCSTR)pdi->item.pszText, -1, NULL, 0): - WideCharToMultiByte(CP_ACP, 0, pdi->item.pszText, -1, NULL, 0, NULL, NULL); + if (notificationCode != LVN_GETDISPINFOW) + { + cchTempBufMax = WideCharToMultiByte(CP_ACP, 0, pdi->item.pszText, + -1, NULL, 0, NULL, NULL); } - else - { - cchTempBufMax = pdi->item.cchTextMax; - *pdi->item.pszText = 0; /* make sure we don't process garbage */ - } + else + { + cchTempBufMax = pdi->item.cchTextMax; + *pdi->item.pszText = 0; /* make sure we don't process garbage */ + } - pszTempBuf = HeapAlloc(GetProcessHeap(), 0, - (convertToUnicode ? sizeof(WCHAR) : sizeof(CHAR)) * cchTempBufMax); + pszTempBuf = HeapAlloc(GetProcessHeap(), 0, sizeof(CHAR) * + cchTempBufMax); if (!pszTempBuf) return FALSE; - if (convertToUnicode) - MultiByteToWideChar(CP_ACP, 0, (LPCSTR)pdi->item.pszText, -1, - pszTempBuf, cchTempBufMax); - else - WideCharToMultiByte(CP_ACP, 0, pdi->item.pszText, -1, (LPSTR) pszTempBuf, - cchTempBufMax, NULL, NULL); + + WideCharToMultiByte(CP_ACP, 0, pdi->item.pszText, -1, (LPSTR) + pszTempBuf, cchTempBufMax, NULL, NULL); + savCchTextMax = pdi->item.cchTextMax; savPszText = pdi->item.pszText; pdi->item.pszText = pszTempBuf; pdi->item.cchTextMax = cchTempBufMax; } - if (infoPtr->notifyFormat == NFR_ANSI) - realNotifCode = get_ansi_notification(notificationCode); - else - realNotifCode = notificationCode; - TRACE(" pdi->item=%s\n", debuglvitem_t(&pdi->item, infoPtr->notifyFormat != NFR_ANSI)); - bResult = notify_hdr(infoPtr, realNotifCode, (LPNMHDR)pdi); + TRACE(" pdi->item=%s\n", debuglvitem_t(&pdi->item, infoPtr->notifyFormat != + NFR_ANSI)); + + bResult = notify_hdr(infoPtr, get_ansi_notification(notificationCode), + (LPNMHDR)pdi); - if (convertToUnicode || convertToAnsi) + if (convertToAnsi) { - if (convertToUnicode) /* note : pointer can be changed by app ! */ - WideCharToMultiByte(CP_ACP, 0, pdi->item.pszText, -1, (LPSTR) savPszText, - savCchTextMax, NULL, NULL); - else - MultiByteToWideChar(CP_ACP, 0, (LPSTR) pdi->item.pszText, -1, - savPszText, savCchTextMax); + MultiByteToWideChar(CP_ACP, 0, (LPSTR) pdi->item.pszText, -1, + savPszText, savCchTextMax); pdi->item.pszText = savPszText; /* restores our buffer */ pdi->item.cchTextMax = savCchTextMax; HeapFree(GetProcessHeap(), 0, pszTempBuf);
On November 21, 2002 11:33 am, Aric Stewart wrote:
Here is a patch which preserves alot of your structure. it works to correct my bug in Outlook.
Wow! It's hard to believe this is the case... WTF is this so? I mean, did you find a reasonable explanation to this behaviour? Did you have a chance to test with XP (comctrl 6.0)? -- Dimi.
Yeah it is sort of amazing. I have a test program under windows if you would like to see the Visual studio project. It has _UNICODE defined in the project, I create a main window with CreateWindowW Inside that window i do a DialogBoxW. That dialog box has a listview which is OWNERDATA. I look at WM_NOTIFYFORMAT and trace and return what is returned by DefWindowProc (which conforms to wine and the docs by returning NFR_UNICODE) then watching the notifies come in when i SetItemCount i see only the A GetDispInfo notify.. i tried all sorts of variations on the W and A creations to see if i saw any difference and I did not. Also this patch fixes the bug in Outlook... -aric Dimitrie O. Paun wrote:
On November 21, 2002 11:33 am, Aric Stewart wrote:
Here is a patch which preserves alot of your structure. it works to correct my bug in Outlook.
Wow! It's hard to believe this is the case... WTF is this so? I mean, did you find a reasonable explanation to this behaviour? Did you have a chance to test with XP (comctrl 6.0)?
On Thu, 2002-11-21 at 11:13, Aric Stewart wrote:
Yeah it is sort of amazing.
I have a test program under windows if you would like to see the Visual studio project. It has _UNICODE defined in the project, I create a main window with CreateWindowW Inside that window i do a DialogBoxW. That dialog box has a listview which is OWNERDATA.
I look at WM_NOTIFYFORMAT and trace and return what is returned by DefWindowProc (which conforms to wine and the docs by returning NFR_UNICODE)
then watching the notifies come in when i SetItemCount i see only the A GetDispInfo notify..
i tried all sorts of variations on the W and A creations to see if i saw any difference and I did not.
Also this patch fixes the bug in Outlook...
-aric
Dimi, Do you think that this patch will fix my treeview problem(s)? Or should the same sort of thing be done to treeview as a test to see if it will? -Dustin
On November 21, 2002 06:27 am, Dustin Navea wrote:
Do you think that this patch will fix my treeview problem(s)? Or should the same sort of thing be done to treeview as a test to see if it will?
Yes, the same sort of patch should be done for treeview. I'll try to do one soon. -- Dimi.
On November 21, 2002 12:13 pm, Aric Stewart wrote:
i tried all sorts of variations on the W and A creations to see if i saw any difference and I did not.
Also this patch fixes the bug in Outlook...
Yes. And beyond this, it correlates perfectly with the treeview problems we have been experiencing lately, so it does look like the 'right' fix. I'll let you know if a similar fix corrects the treeview issues. -- Dimi.
participants (4)
-
Aric Stewart -
Dimitrie O. Paun -
Dustin Navea -
Sylvain Petreolle