- Wine-Devel - list.winehq.org

Re: Patch for Wine-20030115 heap allocation on Solaris 8 x86
by John Wehle Jan. 20, 2003

Jan. 20, 2003

> If you get any feedback about a proposed patch on the mailing > list, you need to deal with the feedback one way or another > before the patch will be applied. I'm familiar with that approach from other projects. Unfortunately I haven't received * any * feedback. However, I just did some digging in the wine-devel archive and I see Alexandre Julliard is having an ongoing discussion with Robert Lunnon regarding the Solaris ADDRESS_SPACE_LIMIT issue: http://www.winehq.com/hypermail/wine-devel/2003/01/0179.html so I guess I'll wait and see what Robert comes up with. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john(a)feith.com | | John Wehle | Fax: 1-215-540-5495 | | -------------------------------------------------------------------------

1 0

Re: allocate palette objects on the large heap.
by Christian Costa Jan. 20, 2003

Jan. 20, 2003

Rein Klazes wrote: >Hi, > >Girotel Offline creates 78 palette objects using 1044 bytes each. That >doesn't fit on the 16bit gdi heap. It is not a leak: each object is >freed when the program closes. Using NtObjects (www.smidgeonsoft.com) >shows that under NT2K the program creates the same number of palette >objects. > >Changelog: > > objects: gdiobj.c > Allocate palette objects on the large gdi heap. > >Rein. > > >------------------------------------------------------------------------ > >--- wine/objects/gdiobj.c 2002-12-03 20:18:41.000000000 +0100 >+++ mywine/objects/gdiobj.c 2003-01-19 14:09:46.000000000 +0100 >@@ -693,6 +693,7 @@ > case ENHMETAFILE_MAGIC: > case ENHMETAFILE_DC_MAGIC: > case BITMAP_MAGIC: >+ case PALETTE_MAGIC: > if (!(obj = alloc_large_heap( size, handle ))) goto error; > break; > } > SS2 was suffering the same problem and with your patch, it has gone. Great! :-) Thanks for the patch. Christian. PS: Does 16-bit apps that create palettes still work ?

1 0

Re: * Hack * for Wine-20030115 DOSFS_Hash on Solaris 8 x86
by John Wehle Jan. 20, 2003

Jan. 20, 2003

>> The enclosed * hack * allows wine photoed to load images. It is * not * >> the correct answer. One possible approach is to modify DOSFS_OpenDir_Normal >> to generate "proper" short names after it has read all the directory entries. > Hmm, somehow I don't think this is a proper solution. > The reasoning being that you probably have a Windows partition > in your Wine install with that ~1 path buried somewhere in the registry > or so. I do. > And IMHO if the registry contains such a setting (*from installation > only* - a program most likely wouldn't create a ~1 .3 shortcut pathname > on its own !), then we are SOL and probably should keep it like that instead > of adding hacks that probably don't improve the code a whole lot. Well ... the whole point of wine is compatibility, and in fact the existing code in wine to handle 8.3 names can be view as a hack for the sake of compatibility (long names good, 8.3 bad :-). All I'm suggesting is that the existing 8.3 code could be made more compatible. It's really unfortunate that Solaris (as far as I can tell) doesn't have a way reading the short filename from the DOS filesystem. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john(a)feith.com | | John Wehle | Fax: 1-215-540-5495 | | -------------------------------------------------------------------------

1 0

wrc arguements
by John Westerman Jan. 20, 2003

Jan. 20, 2003

Hi, Can anyone actually compile the minesweeper example with the current winemaker. Mine keeps failing when trying to convert the rc file using wrc. Is it possible the arguements winemaker generates are no longer correct for wrc. Thanks,

2 1

Re: Resubmission
by Eric POUECH Jan. 20, 2003

Jan. 20, 2003

different comments : - don't use C++ comments, not all C compilers understand them - it's better to split patches in small coherent pieces (in your last patch, msvideo issue has nothing to do with msacm) (disclaimer: since I won't be back to my PC until end of week, these answers are quick overviews of the patch, so don't take everything for granted) into the details : - msvideo: fix sounds correct - msacm: the path in format.c sounds correct. the hack around the PCM format was needed to get exactly what native msacm was giving as an expected results. basically, the driver was doing less than what it's supposed to do. it should be tested on native windows if the same is actually needed - msacm: regarding the Query flag, I don't think we need all your changes. If really windows accepts here a non NULL pointer, then a changing if ((fdwOpen & ACM_STREAMOPENF_QUERY) && phas) return MMSYSERR_INVALPARAM; info if ((fdwOpen & ACM_STREAMOPENF_QUERY) && phas) phas = NULL; would do. A+

1 0

Re: Re: Re: Some more thoughts on khtml
by fenix＠club-internet.fr Jan. 20, 2003

Jan. 20, 2003

>De: Adam Treat <manyoso(a)yahoo.com> >Sujet: Re: Re: Some more thoughts on khtml >A: Adam Treat <manyoso(a)yahoo.com> >Copie à: wine-devel(a)winehq.com, qt-interest(a)trolltech.com >Date: Mon, 20 Jan 2003 06:28:09 -0800 (PST) > >--- Adam Treat <manyoso(a)yahoo.com> wrote: >> >> --- fenix(a)club-internet.fr wrote: >> > >Why not just port the GPL version of Qt to Windows? The kde-cygwin project is doing that >> > And, i don't like the port idea, because trolltech use Qt under windows as main product, and >> > porting the GPL version to windows ... >> >> *sigh* yes, i agree this is a problem. I don't want to hurt Trolltech, I just wish Qt could be >> used as a GPL cross-platform lib. Am still looking for a creative solution that would work for >> both Trolltech and the community, so if anyone has any ideas... ;) > >hehe, maybe Trolltech could release a 'Shared Source' version of Qt for windows... It'd allow >people to try Qt (the latest version) and prohibit commercial software... After all, when on a >different platform 'do as the locals do' ;) As they have released a limited time free version for windows (only for non-commercial projects), i think they won't release a 'shared source' version :( Raphael

1 0

Re: rpc_K01-r1.diff
by Greg Turner Jan. 20, 2003

Jan. 20, 2003

On Monday 20 January 2003 09:33 am, Greg Turner wrote: > Note to Ove: widl_scraps.h contains those things that I needed, > but which were not generated by midl. correction: "not generated by /widl/." -- gmt "Everything that is really great and inspiring is created by the individual who can labor in freedom." --Albert Einstein

1 0

Re: 1995-era Microsoft MFCKIT installer fails to unpack one of its DLLs
by lists.mrkidd＠attbi.com Jan. 20, 2003

Jan. 20, 2003

Does the file /home/dank/c/ms-setup.t/RBHEAP.DLL exist? In the first trace, it looks like it gets created ok when the installer extracts it, but then when Wine tries to load WBRUN20, and therefore RBHEAP.DLL, it fails to find the file. Mason Kidd > On to the next button on the MSVC4.0 installer: MFC. > Clicking it runs d:\mfckit\disk1\setup.exe, which appears to be a > win16 executable. It exits quickly under Wine, saying > Could not load 'RBHEAP.DLL' required by 'WBRUN20', error= 2 > Tsk. Running it under XP works, of course. Now, \mfckit\disk1 > does contain the file rbheap.dl_, which presumably something is supposed > to unpack on the fly. In hopes of seeing what's going on, I ran > this installer under Debugging Tools for Windows' logger; the > result is at http://www.kegel.com/linux/mfckit.txt > Here are the lines from mfckit.txt that reference rbheap.dll or a file > descriptor > open to it or rbheap.dl_: > > Thrd4 0FFB56F5 GetPrivateProfileStringA( "Files" "rbheap.dl_" "" 0x00000080 > "D:\MFCKIT\DISK1\SETUP.LST") -> 0x0000000A ( "rbheap.dll") > Thrd4 0FFB503E CreateFileW( "D:\MFCKIT\DISK1\RBHEAP.DL_" GENERIC_READ > FILE_SHARE_READ | > FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL OPEN_EXISTING 0x00000000 > NULL) -> > INVALID_HANDLE_VALUE [FAIL] > Thrd4 0FFB505D CreateFileW( "D:\MFCKIT\DISK1\RBHEAP.DL_" GENERIC_READ > FILE_SHARE_READ | > FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL OPEN_EXISTING 0x00000000 > NULL) -> 0x000000C4 > Thrd4 0FFB50A7 SetFilePointer( 0x000000C4 0 [0x00000000] NULL FILE_BEGIN) -> > 0x00000000 > Thrd4 0FFB48B9 GetFileAttributesW( "C:\ms-setup.t\rbheap.dll") -> > FILE_ATTRIBUTE_READONLY | > FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM | FILE_ATTRIBUTE_DIRECTORY | > FILE_ATTRIBUTE_ARCHIVE | > FILE_ATTRIBUTE_ENCRYPTED | FILE_ATTRIBUTE_NORMAL | FILE_ATTRIBUTE_TEMPORARY | > FILE_ATTRIBUTE_SPARSE_FILE | FILE_ATTRIBUTE_REPARSE_POINT | > FILE_ATTRIBUTE_COMPRESSED | > FILE_ATTRIBUTE_OFFLINE | FILE_ATTRIBUTE_NOT_CONTENT_INDEXED > Thrd4 0F007B35 GetFileAttributesW( "C:\MS-SETUP.T\RBHEAP.DLL") -> > FILE_ATTRIBUTE_READONLY | > FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM | FILE_ATTRIBUTE_DIRECTORY | > FILE_ATTRIBUTE_ARCHIVE | > FILE_ATTRIBUTE_ENCRYPTED | FILE_ATTRIBUTE_NORMAL | FILE_ATTRIBUTE_TEMPORARY | > FILE_ATTRIBUTE_SPARSE_FILE | FILE_ATTRIBUTE_REPARSE_POINT | > FILE_ATTRIBUTE_COMPRESSED | > FILE_ATTRIBUTE_OFFLINE | FILE_ATTRIBUTE_NOT_CONTENT_INDEXED > Thrd4 0FFB503E CreateFileW( "C:\MS-SETUP.T\RBHEAP.DLL" GENERIC_READ | > GENERIC_WRITE FILE_SHARE_READ > | FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL CREATE_ALWAYS > FILE_ATTRIBUTE_NORMAL NULL) > -> 0x00000124 > Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_CURRENT) -> > 0x00000000 > Thrd4 0FFB4459 ReadFile( 0x000000C4 0x00000008 [0x032AFC2C] -> 0x00000008 > 0x00000000) -> TRUE ( > 0x0003BB70) > Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_BEGIN) -> > 0x00000000 > Thrd4 0FFB503E CreateFileW( "D:\MFCKIT\DISK1\RBHEAP.DL_" GENERIC_READ > FILE_SHARE_READ | > FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL OPEN_EXISTING 0x00000000 > NULL) -> > INVALID_HANDLE_VALUE [FAIL] > Thrd4 0FFB505D CreateFileW( "D:\MFCKIT\DISK1\RBHEAP.DL_" GENERIC_READ > FILE_SHARE_READ | > FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL OPEN_EXISTING 0x00000000 > NULL) -> 0x000000C4 > Thrd4 0FFB50A7 SetFilePointer( 0x000000C4 0 [0x00000000] NULL FILE_BEGIN) -> > 0x00000000 > Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_END) -> > 0x0000189C > Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_BEGIN) -> > 0x00000000 > Thrd4 0FFB4459 ReadFile( 0x000000C4 0x0000000E [0x032AFC2C] -> 0x0000000E > 0x00000000) -> TRUE ( > 0x0003BB28) > Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_END) -> > 0x0000189C > Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_BEGIN) -> > 0x00000000 > Thrd4 0FFB4459 ReadFile( 0x000000C4 0x0000000E [0x032AFC2C] -> 0x0000000E > 0x00000000) -> TRUE ( > 0x0003BB2C) > Thrd4 0FFB4584 SetFilePointer( 0x000000C4 14 [0x032AFC48] -> 0 FILE_BEGIN) -> > 0x0000000E > Thrd4 0FFB4584 SetFilePointer( 0x00000124 0 [0x032AFC48] -> 0 FILE_BEGIN) -> > 0x00000000 > Thrd4 0FFB4459 ReadFile( 0x000000C4 0x00008000 [0x032AFC2C] -> 0x00008000 > 0x00000000) -> TRUE ( > 0x0320FB41) > Thrd4 0FFB4459 ReadFile( 0x000000C4 0x00008000 [0x032AFC2C] -> 0x00008000 > 0x00000000) -> TRUE ( > 0x0320FB41) > Thrd4 0FFC117C WriteFile( 0x00000124 0x03217B60 0x00002B30 [0x032AFC40] -> > 0x0FFDDB70 0x00000000) -> > TRUE > Thrd4 0FFB48B9 GetFileAttributesW( "C:\ms-setup.t\rbheap.dll") -> > FILE_ATTRIBUTE_ARCHIVE > Thrd4 0FFBABDD SetFileAttributesW( "C:\ms-setup.t\rbheap.dll" > FILE_ATTRIBUTE_READONLY | > FILE_ATTRIBUTE_ARCHIVE) -> TRUE > Thrd4 0FFB503E CreateFileW( "C:\MS-SETUP.T\RBHEAP.DLL" GENERIC_READ > FILE_SHARE_READ | > FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL OPEN_EXISTING 0x00000000 > NULL) -> 0x000000DC > Thrd4 0FFB54DC GetProfileIntA( "ModuleCompatibility" "RBHEAP" 0) -> 0 > Thrd4 0FFB48B9 GetFileAttributesW( "C:\ms-setup.t\rbheap.dll") -> > FILE_ATTRIBUTE_READONLY | > FILE_ATTRIBUTE_ARCHIVE > Thrd4 0FFBABDD SetFileAttributesW( "C:\ms-setup.t\rbheap.dll" > FILE_ATTRIBUTE_ARCHIVE) -> TRUE > Thrd4 0F007D27 CreateFileW( "C:\ms-setup.t\rbheap.dll" 0x00010000 0x00000000 > [0x00000000] NULL > OPEN_EXISTING FILE_ATTRIBUTE_NORMAL NULL) -> 0x0000012C > > Looks pretty clear that whatever we're tracing is indeed unpacking the file and > writing it to c:\ms-setup.t\rbheap.dll. (I think we're tracking the wow module > which is running the win16 program.) > > Likewise, I ran it under Wine with --debugmsg +win,+profile,+file,+dosfs,+relay; > the resulting log is at http://www.kegel.com/linux/mfckit-wine.txt > Here are the lines from mfckit-wine.txt that mention rbheap at all: > > trace:profile:PROFILE_Load New key: name='rbheap.dl_', value='rbheap.dll' > trace:file:FILE_DoOpenFile RBHEAP.DLL OF_READ OF_SHARE_COMPAT > trace:file:FILE_DoOpenFile RBHEAP.DLL 0000 > trace:dosfs:DOSFS_DoGetFullPathName passed 'RBHEAP.DLL' > trace:dosfs:DOSFS_DoGetFullPathName got C:\ms-setup.t\RBHEAP.DLL > trace:dosfs:DOSFS_DoGetFullPathName returning 'C:\ms-setup.t\RBHEAP.DLL' > trace:dosfs:DOSFS_GetFullName RBHEAP.DLL (last=1) > trace:dosfs:DOSFS_FindUnixName /home/dank/c/ms-setup.t,RBHEAP.DLL > warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in > '/home/dank/c/ms-setup.t' > trace:dosfs:DOSFS_FindUnixName /home/dank/c/windows/system,RBHEAP.DLL > warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in > '/home/dank/c/windows/system' > trace:dosfs:DOSFS_FindUnixName /home/dank/c/windows,RBHEAP.DLL > warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/home/dank/c/windows' > trace:dosfs:DOSFS_GetFullName C:\MS-SETUP.T\RBHEAP.DLL (last=1) > trace:dosfs:DOSFS_FindUnixName /home/dank/c,MS-SETUP.T\RBHEAP.DLL > trace:dosfs:DOSFS_FindUnixName (/home/dank/c,MS-SETUP.T\RBHEAP.DLL) -> > ms-setup.t (MS-SETUP.T) > trace:dosfs:DOSFS_FindUnixName /home/dank/c/ms-setup.t,RBHEAP.DLL > warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in > '/home/dank/c/ms-setup.t' > trace:dosfs:DOSFS_GetFullName c:\windows\RBHEAP.DLL (last=1) > trace:dosfs:DOSFS_FindUnixName /home/dank/c,windows\RBHEAP.DLL > trace:dosfs:DOSFS_FindUnixName (/home/dank/c,windows\RBHEAP.DLL) -> windows > (WINDOWS) > trace:dosfs:DOSFS_FindUnixName /home/dank/c/windows,RBHEAP.DLL > warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/home/dank/c/windows' > trace:dosfs:DOSFS_GetFullName c:\windows\system\RBHEAP.DLL (last=1) > trace:dosfs:DOSFS_FindUnixName /home/dank/c,windows\system\RBHEAP.DLL > trace:dosfs:DOSFS_FindUnixName (/home/dank/c,windows\system\RBHEAP.DLL) -> > windows (WINDOWS) > trace:dosfs:DOSFS_FindUnixName /home/dank/c/windows,system\RBHEAP.DLL > trace:dosfs:DOSFS_FindUnixName (/home/dank/c/windows,system\RBHEAP.DLL) -> > system (SYSTEM) > trace:dosfs:DOSFS_FindUnixName /home/dank/c/windows/system,RBHEAP.DLL > warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in > '/home/dank/c/windows/system' > trace:dosfs:DOSFS_GetFullName e:\\RBHEAP.DLL (last=1) > trace:dosfs:DOSFS_FindUnixName /tmp,RBHEAP.DLL > warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/tmp' > trace:dosfs:DOSFS_GetFullName e:\test\RBHEAP.DLL (last=1) > trace:dosfs:DOSFS_FindUnixName /tmp,test\RBHEAP.DLL > warn:dosfs:DOSFS_FindUnixName 'test\RBHEAP.DLL' not found in '/tmp' > trace:dosfs:DOSFS_GetFullName f:\\RBHEAP.DLL (last=1) > trace:dosfs:DOSFS_FindUnixName /home/dank,RBHEAP.DLL > warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/home/dank' > warn:file:FILE_DoOpenFile 'RBHEAP.DLL' not found or sharing violation > warn:file:FILE_DoOpenFile (RBHEAP.DLL): return = HFILE_ERROR error= 2 > Could not load 'RBHEAP.DLL' required by 'WBRUN20', error=2 > > No such unpacking going on here. Under Wine, nothing ever references > RBHEAP.DL_. > > Anyone see anything like this before, or have a suggestion on how to track this > down further? > > -- > Dan Kegel > http://www.kegel.com > http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 > >

1 0

Re: Re: Some more thoughts on khtml
by fenix＠club-internet.fr Jan. 20, 2003

Jan. 20, 2003

Hi >What's the use of win32 port of the GPL version of QT for wine? We don't want >wine to depend on Qt, if we wanted this we could just use the normal Unix >version of Qt. i totaly agree with you :) I don't see any need for porting Qt to windows >The khtml-win32 project is much more usefull for wine. That project is >actually porting the qt wrapper Apple made for use in Safari to Windows. When >that port is done, it could be used in Wine. helping that port can speed up wine/khtml integration :) >Roderick > >On Monday 20 January 2003 14:38, Adam Treat wrote: >> --- fenix(a)club-internet.fr wrote: >> > Hi, >> > >> > >Just two things for those thinking about khtml: >> > > >> > >1) The kdebindings package contains C-language bindings for khtml >> > > (kde_HTML*), so C++ wouldn't be a requirement for calling khtml >> > > (this does not affect the qt-replacement api of course). >> > >> > yes, as qtc in kdebindings is for qt :) >> > >> > >2) There is a project to port KWC to win32: KHTML Win32 Native, see >> > > http://sourceforge.net/projects/khtml-win32/ Maybe it is possible to >> > > use that. >> > >> > yes, but it's a really slow project (no cvs access, and only one guy). >> > Maybe we have to help this project >> >> Why not just port the GPL version of Qt to Windows? The kde-cygwin project >> is doing that right now and it isn't terribly hard (if you know the Windows >> API ;). I think if some wine developers got involved it could be >> accomplished very quickly as Qt is almost completely platform agnostic ... >> it only would require a port of 10 files or so... >> >> See: >> 1. http://lists.kde.org/?l=kde-core-devel&m=104072112729044&w=2 >> 2. http://lists.kde.org/?l=kde-cygwin&m=104273412430620&w=2 >> 3. http://lists.kde.org/?l=kde-cygwin&m=104273881706572&w=2 >> >> BTW, I have setup a project and already started porting the build stuff to >> use mingw32. Currently, am stuck in the qfile_win.cpp and qdir_win.cpp >> (copies of the qfile_unix.cpp and qdir_unix.cpp) with the general functions >> that abstract file creation/deletion for windows ... but then I don't know >> any Windows API ;) >> >> Cheers, >> >> Adam >> >> > > ciao >> > > Jörg >> > >> > Raphael >> > >> > >-- >> > >Joerg Mayer <jmayer(a)loplof.de> >> > >I found out that "pro" means "instead of" (as in proconsul). Now I know >> > >what proactive means. >> >> __________________________________________________ >> Do you Yahoo!? >> Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >> http://mailplus.yahoo.com > > >

1 0

Re: Re: Some more thoughts on khtml
by fenix＠club-internet.fr Jan. 20, 2003

Jan. 20, 2003

> >--- fenix(a)club-internet.fr wrote: >> Hi, >> >> >Just two things for those thinking about khtml: >> > >> >1) The kdebindings package contains C-language bindings for khtml >> > (kde_HTML*), so C++ wouldn't be a requirement for calling khtml >> > (this does not affect the qt-replacement api of course). >> >> yes, as qtc in kdebindings is for qt :) >> >> >2) There is a project to port KWC to win32: KHTML Win32 Native, see >> > http://sourceforge.net/projects/khtml-win32/ Maybe it is possible to >> > use that. >> >> yes, but it's a really slow project (no cvs access, and only one guy). Maybe we have to help >> this project > >Why not just port the GPL version of Qt to Windows? The kde-cygwin project is doing that right >now and it isn't terribly hard (if you know the Windows API ;). I think if some wine developers >got involved it could be accomplished very quickly as Qt is almost completely platform agnostic >.... it only would require a port of 10 files or so... > >See: >1. http://lists.kde.org/?l=kde-core-devel&m=104072112729044&w=2 >2. http://lists.kde.org/?l=kde-cygwin&m=104273412430620&w=2 >3. http://lists.kde.org/?l=kde-cygwin&m=104273881706572&w=2 I don't think it's a good idea :( Now, we only need a few classes and code for porting KWQ to windows specific code (and more platform optimised than Qt). While Qt need 10-15 huge base classes to be ported, and platform "tuning " on top level code (platform independent). And, i don't like the port idea, because trolltech use Qt under windows as main product, and porting the GPL version to windows ... In past, i have already done much of Qt (2.x version) porting under windows for a personal project. A first implementation is really easy but for a real industrial one, you need too much code with too much problems (you have to understand well what the top levels classes do, etc...) >BTW, I have setup a project and already started porting the build stuff to use mingw32. The mingw32 guy use a mix of win32 and unix compat layers (yakk) :( >Currently, am stuck in the qfile_win.cpp and qdir_win.cpp (copies of the qfile_unix.cpp and >qdir_unix.cpp) with the general functions that abstract file creation/deletion for windows ... but >then I don't know any Windows API ;) lol as i said before, i think helping the kwq-win32 project is the right way >Cheers, > >Adam > regards, Raphael

2 2