October 2003 - Wine-Devel - list.winehq.org

{Heap,Global,Local,}ReAlloc status (take 2)
by Dimitrie O. Paun Oct. 14, 2003

Oct. 14, 2003

Hi folks, Oleg has been doing a lot of good work, and we are now down to 73 HeapReAlloc and 73 non-HeapReAlloc entries to review. I'm still not sure how the comctl32.ReAlloc() should behave, any help in getting that resolved would be highly appreciated. Here is the update list: ./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/avifil32/avifile.c: This->idxFmtChanges = GlobalReAllocPtr(This->idxFmtChanges, This->nIdxFmtChanges * sizeof(AVIINDEXENTRY), GHND); ./dlls/avifil32/avifile.c: This->idxFrames = GlobalReAllocPtr(This->idxFrames, This->nIdxFrames * sizeof(AVIINDEXENTRY), GHND); ./dlls/avifil32/avifile.c: (LPDWORD)GlobalReAllocPtr(This->lpBuffer, max(size, This->sInfo.dwSuggestedBufferSize), GMEM_MOVEABLE); ./dlls/avifil32/api.c: pOptions->lpFormat = GlobalReAllocPtr(pOptions->lpFormat, size, GMEM_MOVEABLE); ./dlls/avifil32/api.c: (lpBuffer = GlobalReAllocPtr(lpBuffer, cbBuffer *= 2, GPTR)) != NULL); ./dlls/avifil32/api.c: (lpBuffer = GlobalReAllocPtr(lpBuffer, cbBuffer *= 2, GPTR)) != NULL); ./dlls/avifil32/api.c: (lpBuffer = GlobalReAllocPtr(lpBuffer, cbBuffer *= 2, GPTR)) != NULL); ./dlls/avifil32/extrachunk.c: lp = (LPDWORD)GlobalReAllocPtr(extra->lp, extra->cb + size + 2 * sizeof(DWORD), GHND); ./dlls/avifil32/extrachunk.c: lp = (LPDWORD)GlobalReAllocPtr(extra->lp, extra->cb + cb, GHND); ./dlls/avifil32/getframe.c: This->lpInFormat = GlobalReAllocPtr(This->lpInFormat, This->cbInBuffer, 0); ./dlls/avifil32/getframe.c: (LPBITMAPINFOHEADER)GlobalReAllocPtr(This->lpOutFormat, size, GMEM_MOVEABLE); ./dlls/avifil32/acmstream.c: This->acmStreamHdr.pbSrc = GlobalReAllocPtr(This->acmStreamHdr.pbSrc, ./dlls/avifil32/acmstream.c: This->acmStreamHdr.pbDst = GlobalReAllocPtr(This->acmStreamHdr.pbDst, ./dlls/avifil32/icmstream.c: (LPBITMAPINFOHEADER)GlobalReAllocPtr(This->lpbiPrev,size,GMEM_MOVEABLE); ./dlls/avifil32/icmstream.c: (LPBITMAPINFOHEADER)GlobalReAllocPtr(This->lpbiPrev,size,GMEM_MOVEABLE); ./dlls/avifil32/editstream.c: GlobalReAllocPtr(This->pStreams, (This->nTableSize + 32) * sizeof(EditStreamTable), GMEM_SHARE|GHND); ./dlls/avifil32/editstream.c: pEdit->pStreams = GlobalReAllocPtr(pEdit->pStreams, This->nStreams * sizeof(EditStreamTable),GMEM_SHARE|GHND); ./dlls/comctl32/comctl32undoc.c:LPVOID WINAPI ReAlloc (LPVOID lpSrc, DWORD dwSize) ./dlls/comctl32/comctl32undoc.c: LPSTR ptr = ReAlloc (*lppDest, strlen (lpSrc) + 1); ./dlls/comctl32/comctl32undoc.c: LPWSTR ptr = ReAlloc (*lppDest, len * sizeof(WCHAR)); ./dlls/comctl32/comctl32undoc.c: LPWSTR ptr = ReAlloc (*lppDest, len*sizeof(WCHAR)); ./dlls/comctl32/comctl32undoc.c: lpTemp = ReAlloc (hdsa->pData, nSize); ./dlls/comctl32/comctl32undoc.c: lpTemp = ReAlloc (hdsa->pData, nSize); ./dlls/comctl32/comctl32undoc.c: lpDest = ReAlloc (hdsa->pData, nSize); ./dlls/comctl32/monthcal.c: infoPtr->monthdayState = ReAlloc(infoPtr->monthdayState, ./dlls/comctl32/propsheet.c: psInfo->proppage = (PropPageInfo*) ReAlloc(psInfo->proppage, ./dlls/comctl32/trackbar.c: infoPtr->tics=ReAlloc (infoPtr->tics, ./dlls/comctl32/trackbar.c: infoPtr->tics=ReAlloc( infoPtr->tics, ./dlls/comctl32/treeview.c: newText = (LPWSTR)ReAlloc(wineItem->pszText, buflen); ./dlls/comctl32/treeview.c: LPSTR newText = ReAlloc(wineItem->pszText, len); ./dlls/comctl32/treeview.c: LPSTR newText = ReAlloc(wineItem->pszText, len); ./dlls/comctl32/treeview.c: wineItem->pszText = ReAlloc(wineItem->pszText, ./dlls/comctl32/treeview.c: if (NULL == ReAlloc(editedItem->pszText, iLength + 1)) ./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/toolhelp.c: notifys=(struct notify*)HeapReAlloc( GetProcessHeap(), 0, notifys, ./dlls/kernel/toolhelp.c: notifys=(struct notify*)HeapReAlloc( GetProcessHeap(), 0, notifys, ./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/local16.c: ptr = HeapReAlloc( header->heap, ./dlls/kernel/resource16.c: handle = GlobalReAlloc16( hMemObj, pNameInfo->length << sizeShift, 0 ); ./dlls/kernel/resource16.c: handle = GlobalReAlloc16( hMemObj, pNameInfo->length << sizeShift, 0 ); ./dlls/mpr/mpr_main.c:LPVOID WINAPI MPR_ReAlloc( LPVOID lpSrc, DWORD dwSize ) ./dlls/msvcrt/heap.c: return HeapReAlloc(GetProcessHeap(), HEAP_REALLOC_IN_PLACE_ONLY, mem, size); ./dlls/msvcrt/heap.c: return HeapReAlloc(GetProcessHeap(), 0, ptr, size); ./dlls/netapi32/apibuf.c: *NewBuffer = HeapReAlloc(GetProcessHeap(), 0, OldBuffer, NewByteCount); ./dlls/ntdll/heap.c: * RtlReAllocateHeap (NTDLL.@) ./dlls/ntdll/heap.c:PVOID WINAPI RtlReAllocateHeap( HANDLE heap, ULONG flags, PVOID ptr, ULONG size ) ./dlls/ntdll/loadorder.c: env_list.order = RtlReAllocateHeap(GetProcessHeap(), 0, env_list.order, ./dlls/ntdll/relay.c: *dll = RtlReAllocateHeap(ntdll_get_process_heap(), ./dlls/ntdll/path.c: name = (WCHAR*)RtlReAllocateHeap(ntdll_get_process_heap(), 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/ifs.c: pNewMemory = HeapReAlloc(GetProcessHeap(),0,pv,cb); ./dlls/ole32/memlockbytes.c: This->supportHandle = GlobalReAlloc(This->supportHandle, ./dlls/ole32/ole16.c: ret = MapLS( HeapReAlloc( GetProcessHeap(), 0, MapSL(pv), cb ) ); ./dlls/ole32/memlockbytes16.c: This->supportHandle = GlobalReAlloc16(This->supportHandle, ./dlls/oleaut32/ole2disp.c:INT16 WINAPI SysReAllocString16(LPBSTR16 pbstr,LPCOLESTR16 oleStr) ./dlls/oleaut32/ole2disp.c:int WINAPI SysReAllocStringLen16(BSTR16 *old,const char *in,int len) ./dlls/oleaut32/oleaut.c:int WINAPI SysReAllocStringLen(BSTR* old, const OLECHAR* str, unsigned int len) ./dlls/oleaut32/oleaut.c: DWORD *ptr = HeapReAlloc(GetProcessHeap(),0,((DWORD*)*old)-1,newbytelen+sizeof(WCHAR)+sizeof(DWORD)); ./dlls/oleaut32/oleaut.c:INT WINAPI SysReAllocString(LPBSTR old,LPCOLESTR str) ./dlls/oleaut32/usrmarshal.c: SysReAllocStringLen(pstr, (OLECHAR*)&str->asData, str->clSize); ./dlls/rpcrt4/rpc_binding.c: LPSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst, (len+slen+2)*sizeof(CHAR)); ./dlls/rpcrt4/rpc_binding.c: LPWSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst, (len+slen+2)*sizeof(WCHAR)); ./dlls/setupapi/virtcopy.c: vhstrlist = HeapReAlloc(heap, HEAP_ZERO_MEMORY, vhstrlist, ./dlls/setupapi/virtcopy.c: pvnlist = HeapReAlloc(heap, HEAP_ZERO_MEMORY, pvnlist, ./dlls/setupapi/parser.c: if ((new_array = HeapReAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, array, new_count * elem ))) ./dlls/setupapi/parser.c: if (!(section = HeapReAlloc( GetProcessHeap(), 0, section, size ))) return NULL; ./dlls/setupapi/parser.c: file->sections = HeapReAlloc( GetProcessHeap(), 0, file->sections, ./dlls/setupapi/parser.c: file->fields = HeapReAlloc( GetProcessHeap(), 0, file->fields, ./dlls/setupapi/parser.c: file->strings = HeapReAlloc( GetProcessHeap(), HEAP_REALLOC_IN_PLACE_ONLY, file->strings, ./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), ./dlls/wineps/glyphlist.c: newGlyphList = (GLYPHNAME **) HeapReAlloc(PSDRV_Heap, 0, glyphList, ./dlls/wineps/ppd.c: buf = HeapReAlloc( PSDRV_Heap, 0, buf, ./dlls/wineps/ppd.c: buf = HeapReAlloc( PSDRV_Heap, 0, buf, len + sl + 1 ); ./dlls/wineps/type1.c: str->str = HeapReAlloc(GetProcessHeap(), 0, str->str, str->max_len); ./dlls/wineps/type1.c: t1->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/wineps/type42.c: t42->glyf_blocks = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/wineps/type42.c: t42->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/winmm/lolvldrv.c: HeapReAlloc(GetProcessHeap(), 0, (llTypes[type].lpMlds) ? llTypes[type].lpMlds - 1 : NULL, ./dlls/winmm/time.c: HeapReAlloc(GetProcessHeap(), 0, ./dlls/winmm/mciavi/mmoutput.c: wma->lpAudioIndex = HeapReAlloc(GetProcessHeap(), 0, ./dlls/winmm/wineoss/audio.c: omr->messages = HeapReAlloc(GetProcessHeap(),0,omr->messages, omr->ring_buffer_size * sizeof(OSS_MSG)); ./dlls/winmm/wineoss/audio.c: This->notifies = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/winmm/winearts/audio.c: mr->messages = HeapReAlloc(GetProcessHeap(),0,mr->messages, mr->ring_buffer_size * sizeof(RING_MSG)); ./dlls/winmm/winealsa/audio.c: omr->messages = HeapReAlloc(GetProcessHeap(),0,omr->messages, omr->ring_buffer_size * sizeof(ALSA_MSG)); ./dlls/winmm/winenas/audio.c: mr->messages = HeapReAlloc(GetProcessHeap(),0,mr->messages, mr->ring_buffer_size * sizeof(RING_MSG)); ./dlls/winmm/winejack/audio.c: wwo->sound_buffer = HeapReAlloc(GetProcessHeap(), 0, wwo->sound_buffer, wwo->buffer_size); ./dlls/winsock/async.c: extrabuf=HeapReAlloc(GetProcessHeap(),0,extrabuf,ebufsize) ; ./dlls/winsock/socket.c: extrabuf=HeapReAlloc(GetProcessHeap(),0,extrabuf,ebufsize) ; ./dlls/winsock/socket.c: extrabuf=HeapReAlloc(GetProcessHeap(),0,extrabuf,ebufsize) ; ./dlls/winspool/info.c: pent=HeapReAlloc(GetProcessHeap(),0,pent,strlen(pent)+strlen(buf)+2); ./dlls/winspool/info.c: LPWSTR *new_array = HeapReAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, printer_array, ./dlls/x11drv/xrender.c: glyphsetCache = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/x11drv/xrender.c: entry->realized = HeapReAlloc(GetProcessHeap(), ./dlls/x11drv/xrender.c: entry->bitmaps = HeapReAlloc(GetProcessHeap(), ./dlls/x11drv/xrender.c: entry->gis = HeapReAlloc(GetProcessHeap(), ./dlls/x11drv/clipboard.c: HeapReAlloc(GetProcessHeap(),0,val, total); ./graphics/painting.c: *PtsOut = HeapReAlloc( GetProcessHeap(), 0, *PtsOut, ./graphics/x11drv/xfont.c: !(buffer = HeapReAlloc( GetProcessHeap(), 0, buffer, *buf_size = len ))) ./graphics/x11drv/xfont.c: if( (newCache = (fontObject*)HeapReAlloc(GetProcessHeap(), 0, ./graphics/x11drv/palette.c: mapping = HeapReAlloc( GetProcessHeap(), 0, palPtr->mapping, ./objects/gdiobj.c: if ((new_handle = (HGDIOBJ)(ULONG_PTR)LOCAL_ReAlloc( GDI_HeapSel, h, size, LMEM_MOVEABLE ))) ./objects/gdiobj.c: void *new_ptr = HeapReAlloc( GetProcessHeap(), 0, large_handles[i], size ); ./objects/metafile.c: mh = HeapReAlloc( GetProcessHeap(), 0, mh, size ); ./objects/metafile.c: mh = HeapReAlloc( GetProcessHeap(), 0, mh, ./objects/metafile.c: return (HMETAFILE16)GlobalReAlloc16( hMeta, 0, ./objects/palette.c: int *newMap = (int*) HeapReAlloc(GetProcessHeap(), 0, ./objects/region.c: *firstrect = HeapReAlloc( GetProcessHeap(), 0, *firstrect, (2 * (sizeof(RECT)) * (reg->size))); ./objects/region.c: if (! (dst->rects = HeapReAlloc( GetProcessHeap(), 0, dst->rects, ./objects/region.c: newReg->rects = HeapReAlloc( GetProcessHeap(), 0, newReg->rects, ./objects/region.c: if (!(reg->rects = HeapReAlloc( GetProcessHeap(), 0, reg->rects, ./programs/regapi/regapi.c: lpsCurrentValue=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpsCurrentValue,dwSize); ./programs/regapi/regapi.c: lpsData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpsData,lLen); ./programs/regapi/regapi.c: lpbData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpbData,dwLen); ./programs/regapi/regapi.c: stdInput=HeapReAlloc(GetProcessHeap(), 0,stdInput,curSize+=STDIN_MAX_LEN); ./programs/regapi/regapi.c: stdInput=HeapReAlloc(GetProcessHeap(),0,stdInput,strlen(stdInput)+STDIN_MAX_LEN); ./programs/wineconsole/dialog.c: di->font = HeapReAlloc(GetProcessHeap(), 0, di->font, sizeof(*di->font) * (di->nFont + 1)); ./programs/wineconsole/wineconsole.c: data->cells = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, data->cells, ./programs/wineconsole/curses.c: PRIVATE(data)->line = HeapReAlloc(GetProcessHeap(), 0, PRIVATE(data)->line, ./programs/winhelp/hlp2sgml.c:void* WINAPI HeapReAlloc( HANDLE heap, DWORD flags, void* ptr, DWORD size) ./programs/winhelp/hlpfile.c: bi = HeapReAlloc(GetProcessHeap(), 0, bi, sizeof(*bi) + nc * sizeof(RGBQUAD)); ./programs/winhelp/hlpfile.c: hlpfile->bmps = HeapReAlloc(GetProcessHeap(), 0, hlpfile->bmps, ./programs/winhelp/hlpfile.c: hlpfile->windows = HeapReAlloc(GetProcessHeap(), 0, hlpfile->windows, ./programs/regedit/regproc.c: lpsData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpsData,lLen); ./programs/regedit/regproc.c: lpbData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpbData,dwLen); ./programs/regedit/regproc.c: new_buffer = HeapReAlloc (GetProcessHeap(), 0, line, new_size); ./programs/regedit/regproc.c: *buffer = HeapReAlloc(GetProcessHeap(), 0, *buffer, ./programs/regedit/regproc.c: *val_buf = HeapReAlloc(GetProcessHeap(), 0, *val_buf, *val_size); -- Dimi.

3 2

Re: Fix some problems found while compiling and linking Wine under Cygwin
by Alexandre Julliard Oct. 14, 2003

Oct. 14, 2003

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > +++ wine/configure.ac Sun Oct 12 10:54:02 2003 > @@ -969,6 +969,7 @@ AC_CHECK_FUNCS(\ > popen \ > pread \ > pwrite \ > + res_init \ > rfork \ > select \ > sendmsg \ > @@ -1148,7 +1150,7 @@ dnl **** Check for types **** > > AC_C_CONST > AC_C_INLINE > -AC_CHECK_TYPES([mode_t, off_t, pid_t, size_t, ssize_t]) > +AC_CHECK_TYPES([mode_t, off_t, pid_t, size_t, ssize_t, struct __res_state]) These checks won't work without including the proper headers first. > +++ wine/dlls/iphlpapi/ipstats.c Sun Oct 12 10:10:28 2003 > @@ -53,37 +53,37 @@ > #include "ifenum.h" > #include "ipstats.h" > > -#ifndef TCPS_ESTABLISHED > +#if !defined TCPS_ESTABLISHED && defined TCP_ESTABLISHED TCP_ESTABLISHED etc. values are an enum under Linux, you can't test them this way. -- Alexandre Julliard julliard(a)winehq.com

1 0

winehq download page
by Ivan Leo Murray-Smith Oct. 14, 2003

Oct. 14, 2003

I sent this patch http://www.winehq.org/hypermail/wine-patches/2003/10/0064.html and can't think a reason in the world for it not to be applied, have I done something wrong or what?

4 3

Wine Start menu
by Robert van Herk Oct. 13, 2003

Oct. 13, 2003

Hi all, As some of you might know I am working on a Wine Start menu, for Linux. I have heard different things on this list about the way Windows treats the start menu. Some told me that it would be better to make a Windows (wine) client that reads the actual start menu by querying a Wine dll, while others told me that this is not neccesairy as all the links are contained in the Start Menu directory. From looking at my Windows installation, I must agree that it seems that all items in Programs are indeed in the Start Menu directory. So, my question is: would it be enough to create just a Linux program that synchronizes with this directory? Can anyone give me an example of a lnk file that IS actually missing in a Start Menu directory, but is there in his Program folder in the Windows start menu? Does anyone know how far people came at parsing the lnk files for Linux? I read something about the .lnk format, but I don't really feel like writing my own link file parser ;-). Does anybody know of parts of other software that could be recycled here? Grtz, Robert

4 4

Re: Wine Start menu
by Rolf Kalbermatter Oct. 13, 2003

Oct. 13, 2003

Robert van Herk <robert(a)robertvanherk.nl> wrote: >As some of you might know I am working on a Wine Start menu, for Linux. > >I have heard different things on this list about the way Windows treats >the start menu. > >Some told me that it would be better to make a Windows (wine) client >that reads the actual start menu by querying a Wine dll, while others >told me that this is not neccesairy as all the links are contained in >the Start Menu directory. > > From looking at my Windows installation, I must agree that it seems >that all items in Programs are indeed in the Start Menu directory. Don't forget that the Start menu is a combination of the Start Menu of the "Current User" and the "All Users" (common) tree. SHGetFolderPath can give you the according pidls to those directories. Unfortunately shell32 does not export any functionality to enumerate those directories directly but the FileMenu_.... functions in shell32 take care about building that menu. One way might be to let those functions build the start menu and then enumerate that menu into an external format. >So, my question is: would it be enough to create just a Linux program >that synchronizes with this directory? Can anyone give me an example of >a lnk file that IS actually missing in a Start Menu directory, but is >there in his Program folder in the Windows start menu? > >Does anyone know how far people came at parsing the lnk files for Linux? >I read something about the .lnk format, but I don't really feel like >writing my own link file parser ;-). Does anybody know of parts of other >software that could be recycled here? You shouldn't need to. IShellLink should be all you need for retrieving information from a .lnk file although it seems currently broken somehow, according to some report a few days ago on wine-devel. But if you could reenumerate the Start Menu created by the shell32 FileMenu_ functions you might not really have to bother to much with this either. Rolf Kalbermatter

1 0

Re: configuring wine
by Ivan Leo Murray-Smith Oct. 13, 2003

Oct. 13, 2003

It's true, winesetuptk is very usable (It's a wizard), and winecfg look more complicated than anything in windows. I did read that some very simple programs could run without a windows like filesystem. As winecfg is a winelib app, I suppose it may be possible to run it without a windows like filesystem, so wine could look for a registry (Winecfg works with a registry, not a config file), if it doesn't find it, it starts a wizard-like version of winecfg that allowsthe users to get wine ready to run, like winesetuptk does. > The way winesetuptk does it seems less likely to result in mistakes by users. That's very important for usability and it's why the first time one runs wine he should get a configuration wizard. The "Power user" winecfg (What is currently in the CVS) could be in the wine menu with the wine programs (How this menu is generated, with ros explorer or a specific linux/winelib app isn't really important) with the configuration wizard. This way, users just wanting to change the configuration can start the wizard again, and anybody wanting to tweak the configuration can use the "power user" version http://www.hostedscripts.com/scripts/antispam.html

1 0

Re: winesetuptk
by Ivan Leo Murray-Smith Oct. 13, 2003

Oct. 13, 2003

> If an app installs msvcrt, use it before Wine's builtin one? That could theoreticly create legal problems, but it's OK for me. > I used the default values of documentation/samples/config. If those need > changes, it's best to do so there. I don't really care, but I personally prefer using builtin only (But that's a personal view) > Then those people use rpms or debs. And in that case, it's usually > already configured out of the box if the packager knows what he's doing. I (Following the example of codeweavers, at least until preview 4 that's the last I tried) use winesetuptk for packages. If you give a default config, you impose something that users may not want and may not know how to change. If you use winesetuptk, you give the user a choice of using a real or fake windows setup, and the user can also choose where to have it. The only difference is that codeweavers has a fancy pop up that asks you to run winesetuptk if it doesn't find a config file, and I'm not codeweavers, so I use the "By Alexandre" vanilla source (Otherwise it wouldn't be a official build anymore). Anyway, the config will go soon, so there isn't much point in discussing this.

1 0

RE: winnt.h file
by Steven Edwards Oct. 13, 2003

Oct. 13, 2003

Hello Geoff, Comments are inline --- Geoff Peters <Geoff(a)logic.bm> wrote: > Steven - Thanks for the reply. I have 2 C files I am trying to port > to Solaris, one is done (compiles OK), the other one I am working on > has a dependency on wininet.h, along with it comes a huge raft of > other dependencies. I obtained most of these libraries from > http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/?cvs… The w32api package is only for developing Windows application using Mingw on Windows or cross-compiling Windows apps from a GNUtool chain. Winelib is a better solution for your problem. > There is one block of code that is dependent on this wininet.h > library - I am not a C developer (java!), so I'm kinda stumped as to > whether I should attempt to re write the offending piece of code > using a similar Solaris C API (I am assuming the wininet.h contains > most of the HTTP functions for windows), or simply try to match up > the correct libraries - again coming from Java I am having a hard > time understanding different libraries for different platforms to > perform the same functions. The winnt.h header file I am using is the > latest release you had posted on the above link - I just recently > tried to incorporate pieces of > http://cvs.winehq.com/cvsweb/~checkout~/wine/include/winnt.h?rev=1.172&cont… > which have a context defined for SPARC - which seems to be whats > missing from the redhat winnt.h Yes the structures and defines in winnt.h are Windows and WINE only. It will be nearly impossible to use them in a 100% native application. > In case you can offer any suggestions, I have attached a copy of the > C code I am attempting to port, the last function listed (int > call_cc_gateway) is the one that contains the references to wininet.h > > Haven't really looked at WINE, do you think it would help me out?? I think it could help alot. The first thing you may want to try and do is run your win32 application under WINE on a x86 linux box. If it works there then it should recompile as a Winelib application. The issue then becomes does Wine and Winelib work on Sparc. ATM I think the port is incompleate although we did have some people at Sun who were working on it and Wine does run under Solaris for x86. You can try and port your Win32 application if you can get a WINE to build for Solaris on Sparc. Another option would be to look at what functions Wines wininet.dll imports and see if you can develop a native implementation of wininet that sits on top of the Unix TCP/IP implementation rather than on Wine Winsock. We will try to help you as much as possible if you want to go the Winelib route on the Sparc as we really want to see the Solaris on Sparc port working. Thanks Steven > Geoff Peters, SCJP Phone : (441) 296-9640 > Applications Developer Fax : (441) 292-1509 > Logic Communications E-mail : geoff(a)logic.bm > 12 Par-La-Ville Road WWW : http://www.logic.bm > Hamilton, Bermuda HM JX > > > -----Original Message----- > From: Steven Edwards [mailto:steven_ed4153(a)yahoo.com] > Sent: Monday, October 13, 2003 11:37 AM > To: Geoff Peters; Steven_Ed4153(a)yahoo.com > Subject: Re: winnt.h file > > > Hello, > Are you trying to use Winelib to port your project to solaris? I can > try and help if you are taking this method. If you are using parts of > the w32api package to try and create a native application without > WINE > it may be a little harder. Can you send me your winnt.h header? > > Thanks > Steven > > > --- Geoff Peters <Geoff(a)logic.bm> wrote: > > Hi - Got your email from the cvs.sourceforge.net version info for > the > > winnt.h file. I have a question - wondering if you could help me or > > point me to someone that could - I am porting a win32 app to > Solaris, > > seem to be doing OK with the API's in the repository, however I am > > getting the following error on compilation using gcc on Solaris 8 > > (SPARC): > > > > In file included from /opt/portal/6.2/include/windef.h:246, > > from /opt/portal/6.2/include/windows.h:49, > > from call_tellan_cc_gateway.c:5: > > /opt/portal/6.2/include/winnt.h:1950: #error "undefined processor > > type" > > > > Obviously doesn't recognize the SPARC processor - any idea how I > > could work around this?? > > > > Thanks for your time, Geoff > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com > > ATTACHMENT part 2 application/octet-stream name=call_tellan_cc_gateway.c __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

1 0

Re: winesetuptk
by Ivan Leo Murray-Smith Oct. 13, 2003

Oct. 13, 2003

How can msvcrt possibly be native in a without windows setup? Anyway, if you want winver as win98, we might as well have winelook at win98 too. >Which can lead to the question, >what's the purpose of it if wineinstall can do it? wineinstall is a command line tool for installing wine from source code. Most people would say it's a "For geeks only" thing. You can start winesetuptk without knowing what a shell is, and you can set it up with a few clicks of the mouse, it's usually used by people using binary packages, you know, those people that only use computers as tools and don't know/care about source code and tweaking configurations, and that could never use wineinstall.

3 2

RH7.3 packages
by Vincent Béron Oct. 13, 2003

Oct. 13, 2003

Some time ago somebody asked here about RedHat 7.3 Wine packages. I said I'd do it, pending some hardware upgrade on one of my box. That time has now come, and they are available on the sf.net download page. Only i386 and src for now, no athlon nor i686. Vincent

1 0