- Wine-Devel - list.winehq.org

Compiling Wine: tokenize.c problem
by Paul Barclay Nov. 22, 2003

Nov. 22, 2003

I hope this is the right list for this. Version 20031118 redhat 9 After running ./tools/wineinstall everything goes ok until i get the following: . . . . make[2]: Leaving directory `/home/pbarclay/downloads/wine-20031118/dlls/mshtml' make[2]: Entering directory `/home/pbarclay/downloads/wine-20031118/dlls/msi' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o tokenize.o tokenize.c tokenize.c:46: `TK_ABORT' undeclared here (not in a function) tokenize.c:46: initializer element is not constant tokenize.c:46: (near initialization for `aKeywordTable[0].tokenType') tokenize.c:46: initializer element is not constant tokenize.c:46: (near initialization for `aKeywordTable[0]') tokenize.c:47: `TK_AFTER' undeclared here (not in a function) tokenize.c:47: initializer element is not constant tokenize.c:47: (near initialization for `aKeywordTable[1].tokenType') tokenize.c:47: initializer element is not constant tokenize.c:47: (near initialization for `aKeywordTable[1]') tokenize.c:48: `TK_ALL' undeclared here (not in a function) . . . . tokenize.c:296: `TK_ILLEGAL' undeclared (first use in this function) tokenize.c:305: `TK_BITOR' undeclared (first use in this function) tokenize.c:308: `TK_CONCAT' undeclared (first use in this function) tokenize.c:313: `TK_COMMA' undeclared (first use in this function) tokenize.c:317: `TK_BITAND' undeclared (first use in this function) tokenize.c:321: `TK_BITNOT' undeclared (first use in this function) tokenize.c:336: `TK_STRING' undeclared (first use in this function) tokenize.c:341: `TK_DOT' undeclared (first use in this function) tokenize.c:348: `TK_INTEGER' undeclared (first use in this function) tokenize.c:353: `TK_FLOAT' undeclared (first use in this function) tokenize.c:370: `TK_ID' undeclared (first use in this function) make[2]: *** [tokenize.o] Error 1 make[2]: Leaving directory `/home/pbarclay/downloads/wine-20031118/dlls/msi' make[1]: *** [msi] Error 2 make[1]: Leaving directory `/home/pbarclay/downloads/wine-20031118/dlls' make: *** [dlls] Error 2 Could somebody offer a way to fix this? Thanks PB ________________________________________________________________________ E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ________________________________________________________________________

1 0

Re: help with linking needed
by Ralf Juengling Nov. 22, 2003

Nov. 22, 2003

> I have successfully compiled sources of a Windows application, but > when starting up, it tries to locate and link to a windows dll > to access some C library functions: > > ... > err:module:import_dll No implementation for cw3230.DLL._strlen imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._strncpy imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._strtok imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._tolower imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._toupper imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:LdrInitializeThunk Main exe initialization failed, status > c0000135 > > First of all: Where does the name "cw3230.DLL" come from -- Wine didn't > install such a dll on my system? Okay, I found the answer to this myself, it is quite embarrassing: Amid the sources that I got there was also the executable compiled on a Windows system by a Borland compiler. Since the winelib-generated make file creates a shared library and not an executable, the spurious native Windows executable was not overwritten by my built. The wineapploader script then started wine with the native Windows executable instead of the shared library "memview.exe.so", and the missing DLL reported above is probably Borlands C runtime library or part of it. So forget about the other questions in my previous posting. Now the problem is that the applicaiton doesn't start but immediately fails with a Segmentation Fault. The problem seems to be in the function GetFullName in files/dos_fs.c; here are the last four lines of a startup trace: 0009:trace:nls:WideCharToMultiByte cp 65010 L"memview.exe" -> "memview.exe" 0009:trace:dosfs:DOSFS_FindUnixName (/local/builts/phaeaco-20031119/src/memview,L"memview.exe") -> L"memview.exe" (L"MEMVIEW.EXE") 0009:trace:heap:RtlFreeHeap (0x401e0000,00000002,401e0918): returning TRUE 0009:trace:dosfs:DOSFS_GetFullName returning /local/builts/phaeaco-20031119/src/memview/memview.exe = L"Z:\\LOCAL\\BUILTS\\PHAE~WVJ\\SRC\\MEMVI\ EW\\MEMVIEW.EXE" Segmentation fault (Note: I had renamed the file "memview.exe.so" to "memview.exe"). I haven't looked into and tried to fix GetFullName yet but will do so next week. Of course, I hope somebody who knows the code well will come up with a fix before I try. :-) Thanks for the Wine, Ralf

1 0

Re: help with linking needed
by Ralf Juengling Nov. 22, 2003

Nov. 22, 2003

> I have successfully compiled sources of a Windows application, but > when starting up, it tries to locate and link to a windows dll > to access some C library functions: > > ... > err:module:import_dll No implementation for cw3230.DLL._strlen imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._strncpy imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._strtok imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._tolower imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._toupper imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:LdrInitializeThunk Main exe initialization failed, status > c0000135 > > First of all: Where does the name "cw3230.DLL" come from -- Wine didn't > install such a dll on my system? Okay, I found the answer to this myself, it is quite embarrassing: Amid the sources that I got there was also the executable compiled on a Windows system by a Borland compiler. Since the winelib-generated make file creates a shared library and not an executable, the spurious native Windows executable was not overwritten by my built. The wineapploader script then started wine with the native Windows executable instead of the shared library "memview.exe.so", and the missing DLL reported above is probably Borlands C runtime library or part of it. So forget about the other questions in my previous posting. Now the problem is that the applicaiton doesn't start but immediately fails with a Segmentation Fault. The problem seems to be in the function GetFullName in files/dos_fs.c; here are the last four lines of a startup trace: 0009:trace:nls:WideCharToMultiByte cp 65010 L"memview.exe" -> "memview.exe" 0009:trace:dosfs:DOSFS_FindUnixName (/local/builts/phaeaco-20031119/src/memview,L"memview.exe") -> L"memview.exe" (L"MEMVIEW.EXE") 0009:trace:heap:RtlFreeHeap (0x401e0000,00000002,401e0918): returning TRUE 0009:trace:dosfs:DOSFS_GetFullName returning /local/builts/phaeaco-20031119/src/memview/memview.exe = L"Z:\\LOCAL\\BUILTS\\PHAE~WVJ\\SRC\\MEMVI\ EW\\MEMVIEW.EXE" Segmentation fault (Note: I had renamed the file "memview.exe.so" to "memview.exe"). I haven't looked into and tried to fix GetFullName yet but will do so next week. Of course, I hope somebody who knows the code well will come up with a fix before I try. :-) Thanks for the Wine, Ralf

1 0

Configuration parameters
by Dimitrie O. Paun Nov. 22, 2003

Nov. 22, 2003

Hi folks, I've finally managed to do the table I've promised for so long. My appologies for the delay. This has been mind numbing work, and as such I haven't payed that much attention to the values I've filled in those columns. Please send me your comments so I can post a final version of this to the WineHQ site soon. Note: best viewed in a web browser, but an editor that can display about 150 columns would do just fine as well. -- Dimi.

7 20

Re: winmm: move MCI settings from system.ini to the registry
by Eric Pouech Nov. 22, 2003

Nov. 22, 2003

Dimitrie O. Paun wrote: > Eric, > > I think these values (*.drv) sit under > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI > and not under > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI32 > as you suggested. On NT, MCI key is for 16 bit drivers and MCI32 key is for 32 bit drivers. The registry key for Win9x is not the same (it's HKML\System\CurrentControlSet\Control\MediaResources\mci). And most of the programs for Win9x still want to advertize their drivers in system.ini and not especially in the registry, so we'll have to provide some backup for that too. And to add the final touch, native drivers are 16bits (even on NT, at least 'til 2k, didn't check on XP), wine's are 32 bits. Wine current code should take of this (ie load a 16 bit driver when a 32 bit was requested, and do all the 16 <=> 32 transformation). So, what I'd suggest is to support all the schemes for configuring drivers, in this order of (decreasing) priority: registry-NT key (16+32), registry-Win9x key (16+32), system.ini (16+32). We also need to be consistent about this for all the drivers (and not only the MCI ones), which mean a deeper look at the code (video, acm...). I also think, since we're about to use the native registry settings, that we need to support the "Disabled" key in driver configuration, otherwise we might get lots of errors (for not correctly working devices). I won't have too much time to look at this in details right now, so if someone wants to jump in, I'll be happy to give him (her ?) a hand. A+ -- Eric Pouech

1 0

RFC: {Global,Local}{Re,}Alloc()
by Dimitrie O. Paun Nov. 22, 2003

Nov. 22, 2003

Hi folks, There are a few places in Wine where we're not using the Heap*() functions, but rather the old {Global,Local}{Re,}Alloc() ones. IIRC we need to do so in controls/edit.c for compatibility with old Win16 code, but why do we do so in places like: * print dialog * ole32 * shell32 * shlwapi Here is a list of places where {Global,Local}ReAlloc() are used. I'd like to replace them with Heap* functions where it is possible, but before I do, I need to know where we need the old calls. ./controls/edit.c: hloc32W_new = LocalReAlloc(es->hloc32W, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./controls/edit.c: if ((hNew32W = LocalReAlloc(es->hloc32W, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT))) { ./controls/edit.c: hloc32A_new = LocalReAlloc(es->hloc32A, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./controls/edit.c: hloc16_new = LOCAL_ReAlloc(hInstance, es->hloc16, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./dlls/commdlg/printdlg.c: *hmem = GlobalReAlloc(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg.c: *hmem = GlobalReAlloc(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg.c: lppd->hDevMode = GlobalReAlloc(lppd->hDevMode, ./dlls/commdlg/printdlg.c: lppd->hDevMode = GlobalReAlloc(lppd->hDevMode, ./dlls/commdlg/printdlg16.c: *hmem = GlobalReAlloc16(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg16.c: lppd->hDevMode = GlobalReAlloc16(lppd->hDevMode, ./dlls/kernel/local16.c: hseg = GlobalReAlloc16( hseg, 0x10000, GMEM_FIXED ); ./dlls/kernel/local16.c:HLOCAL16 LOCAL_ReAlloc( HANDLE16 ds, HLOCAL16 handle, WORD size, WORD flags ) ./dlls/kernel/local16.c:HLOCAL16 WINAPI LocalReAlloc16( HLOCAL16 handle, WORD size, UINT16 flags ) ./dlls/kernel/local16.c: return LOCAL_ReAlloc( CURRENT_DS, handle, size, flags ); ./dlls/kernel/local16.c:DWORD WINAPI Local32ReAlloc16( HANDLE heap, DWORD addr, INT16 type, ./dlls/kernel/resource16.c: handle = GlobalReAlloc16( hMemObj, pNameInfo->length << sizeShift, 0 ); ./dlls/kernel/resource16.c: handle = GlobalReAlloc16( hMemObj, pNameInfo->length << sizeShift, 0 ); ./dlls/ole32/hglobalstream.c: This->supportHandle = GlobalReAlloc(This->supportHandle, ./dlls/ole32/ifs.c: Malloc32.SpyedBlocks = (LPVOID*)LocalReAlloc((HLOCAL)Malloc32.SpyedBlocks, NewLength, GMEM_ZEROINIT); ./dlls/ole32/memlockbytes.c: This->supportHandle = GlobalReAlloc(This->supportHandle, ./dlls/ole32/memlockbytes16.c: This->supportHandle = GlobalReAlloc16(This->supportHandle, ./dlls/shell32/shell32_main.c: hargv=GlobalReAlloc(hargv, size, 0); ./dlls/shell32/shellole.c: addr = (LPVOID) LocalReAlloc((HANDLE) pv, cb, GMEM_ZEROINIT | GMEM_MOVEABLE); ./dlls/shlwapi/clist.c: lpTemp = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)pItem, ulSize, ./dlls/shlwapi/clist.c: lpIter = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)*lppList, ./dlls/shlwapi/clist.c: lpList = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)*lppList, ulNewSize, ./dlls/user/dde/misc.c: hData = GlobalReAlloc((HGLOBAL)hData, new_sz + sizeof(DDE_DATAHANDLE_HEAD), ./objects/gdiobj.c: if ((new_handle = (HGDIOBJ)(ULONG_PTR)LOCAL_ReAlloc( GDI_HeapSel, h, size, LMEM_MOVEABLE ))) ./objects/metafile.c: return (HMETAFILE16)GlobalReAlloc16( hMeta, 0, -- Dimi.

3 2

Re: wn20031121_197.xml
by Brian Vincent (C) Nov. 21, 2003

Nov. 21, 2003

> If I am not mistaken, I offered him commit access a while ago. He was > content at the time to have my slow butt commit. The offer still > stands. Yeah.. maybe it's time I take you up on it. Up until recently I didn't have reliable shell access. Now I've got a nice shell account and have reliable access from home. CVS access won't make my life any easier, however. I still have to mail Zack Brown the issues for his Kernel Traffic site. But adding a few steps shouldn't be a big deal. I think Eric always did the commits himself a few years ago. > I try to commit as soon as I see the XML, but when he sends it to > wine-patches at midnight on a Friday, well... it just may not get up > until Monday morning. Or, more likely, 2am on Saturday. I'm usually not drunk enough by midnight to finish a WWN issue ;) CVS access might be a good thing since my winter schedule is going to be changing quite a bit. The late Thursday/early Friday approach might be harder. One nice thing about posting these by midday on Friday is that we probably get a few more people reading them as opposed to publishing them on a Saturday. -brian

1 0

Re: wn20031121_197.xml
by Shachar Shemesh Nov. 21, 2003

Nov. 21, 2003

Vincent Béron wrote: >Le ven 21/11/2003 à 14:44, Shachar Shemesh a écrit : > > >>Wouldn't you say that it's time to give Vincent commit access to the web >>site? >> >> > >That'd be Brian, not me. > >Vincent > > > Luckily, it has recently rained, and so there is plenty of mud for my face. Sorry about that. On a totally different subject - wouldn't you say it was time to give Brian Vincent commit access to the web site? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

2 1

Re: wine/ graphics/x11drv/xfont.c graphics/x11drv/ ...
by Dimitrie O. Paun Nov. 21, 2003

Nov. 21, 2003

On November 20, 2003 07:17 pm, Alexandre Julliard wrote: > Get rid of a bunch of TSX functions. Yay! Getting rid of the TSX functions seems to be within our reach now. I hope this is the plan, right? :) -- Dimi.

3 6

Re: wn20031121_197.xml
by Shachar Shemesh Nov. 21, 2003

Nov. 21, 2003

Wouldn't you say that it's time to give Vincent commit access to the web site? Brian Vincent wrote: >wn20031121_197.xml > >-brian > > >------------------------------------------------------------------------ > ><?xml version="1.0" ?> ><kc> > ><title>Wine Traffic</title> > > >

1 0