December 2001 - Wine-Devel - list.winehq.org

Wine Tasklist
by Francois Gouget Jan. 4, 2002

Jan. 4, 2002

Hi, I would like to establish two Wine tasklists in Wine's bugzilla. * the first list would contain the items listed in my previous 'Call for Volunteers' emails. This would make it easier to keep track of these tasks. * the second list would contain more complex and general items like 'DCOM support'. For the first list, refer to my previous 'Call for Volunteers' emails. I think I will start it from there and we can update it after that. For the second list, I included a first draft below. I would like your comments on it, especially with regard to the status of some of these items, and suggestions if you see missing items. I know we already have a 'Wine 1.0' and 'Wine 1.x' tasklists'. There may be some overlap but I think the intent is different. * My intent with these two new tasklists is to advertise what we want to do to potential contributors. So the idea is to then add a page to the WineHQ web site that would list all the ways one can contribute to Wine: maintaining an application entry in the Application Database, helping users on the mailing lists, buying Wine based applications, and of course contributing code. And for this last item, these lists would provide a good starting point, both for developpers with little time and for developpers who want to invest themselves more heavily in Wine. * Then unlike the 1.0 and 1.x tasklists, these new lists would not be tied to a specific Wine release or date. I hope to produce a draft of this web page in the coming days. In the meantime let me know if I missed things in the list below. For each item I tried to indicate the rationale behind the task, and point to the corresponding bugzilla report if there is one. Wine tasklist ------------- * Make the registry loadable on demand - when working from a Windows partition the registry is big. - this causes wineserver to allocate a lot of memory - this has a big impact on startup times - a 'database' based registry may be more robust * Rasterizer - to paint into a DIB we have to copy the IB contents into an X bitmap, call X functions to modify the bitmap, often only to have to copy the result back to the DIB when the application tries to read it. Imagine it for eash SetPixel operation! - a rasterizer would be able to perform these operations directly on the DIB and thus provide better performance, at least in some situations. - it would also provide better color accuracy: the X server often only supports a few bit depths so that if the application works on a 24bpp DIB but the X server is in 16bpp mode, 3bits are lost per color component. * Cross process messages - used by many applications - needed for DDE (bug 95) - Alexandre, you worked on this recently, right? Is this working now? - See bug 93 * Out of proc COM - Needed for Installshield 6 - Would probably help with at least some functionality of a host of other applications * DCOM support - same as out of proc COM but network transparent - should be interoperable with Microsoft's implementation so that, in a company setting, processes running in Wine can connect to servers running on whatever Windows server are present. * Better multi-user support - how to get per-user registry files - how much per-user setup is really necessary? (create a '.wine' directory, create per user registry files, who does that, ...) - is it possible to share a single read-only 'c:\' drive? What do we need to get parity with an NT environment? - is it possible to share a read-only 'system.reg' file? - what is the impact of a 'load on demand' registry? Could we share a single registry server? - what would be necessary to share a single - there are many options that need to be investigated and documented... * UNC path handling - for drives '\\.\e:', devices - for network paths - there's been a patch related to this recently but I believe it does not cover all cases - integrate with Samba to handle network UNC paths - provide a way to mount/unmount drives at runtime, especially network drives. One should be able to disable this in the config file (for security reasons). - Support for 'persistent' mounts... will require modifying the way w specify which drives are mounted where. - provide an applet to mount/unmount drives while Wine is running. * Native Alsa support - Alsa is the future of sound in Linux: should be integrated in 2.5 - Could it offer capabilities that OSS does not offer? - Other platforms may not support Alsa any time soon so we must keep OSS too - Anti-rational: Alsa includes an OSS compatibilty mode that seems to work pretty well - see bug 324 * aRts support - On an OSS system when the aRts daemon is running Wine cannot access the sound device - aRts makes it possible to send the sound other the network. This kind of functionality is great for a thin-client environments: setup a server and have the sound sent to each terminal ("You've got mail" ;-). Supporting aRts in Wine would let it integrate perfectly in such an environment. - this could either be native support, or making Wine compatible with artsdsp. The current problem may be related to the -Bsymbolic link option. - see bug 325 * ESounD support - Same thing as for aRts - see bug 326 - Making Wine compatible with artsdsp may also make it compatible with esddsp (and vice versa). * Write a regedit replacement - used by some installers to create registry keys - we can limit the functionality to just that although since Wine has a registry we should probably provide a tool to browse/edit it. - will be more important once we have a database based registry for the load on demand functionality * Write a regsvr32 replacement - used by some installers * Fix the desktop mode - If a process running in desktop mode start another, the new process creates a new desktop - the background is black - one cannot start a specific application in desktop mode. You have to modify the config file. * Compile with STRICT on - better type safety - reveales all the 16/32bits hacks - see bug 90 * Dll separation - to allow us to swap native dlls in and out with less problems - to make the dlls more independent of each other and make it easier to treat them as independent projects - see bug 96 * HEAP_strdup* removal - Alexandre said some day that they will go away - Part of the dll separation? * Move the winsock16 code to wsock32 - winsock16 is more related to wsock32 than to ws2_32 - ws2_32 is the new API. This would leave us with a clean 32bit implementation of the new API that is not encumbered with 16bit hacks. * Check .spec file completeness - we need complete spec file to know where we stand - determine what's new in WinMe, Win2000, WinXP - check that the ordinals/absence of ordinals is correct - I have scripts that can be used as a starting point * Winedbg expression handling - when modifying the contents of a variable there can be mixups where the debugger modifies its own memory instead of that of the debugged process. * Winedbg g++ 3.0 support - The debugging format and the ABI changed in g++ 3.0 and winedbg does not support the new ABI. - This prevents debugging of C++ Winelib applications - This is especially troublesome for MFC Winelib applications - Eric, you worked on this recently, do you know if this is a thing of the past or is it possible that there are still problems (I did not test recently) * Better memory allocator - some memory allocation/release patterns cause the current allocator to be relatively inefficient - see threads on wine-dev (Ove/Gav hit this problem) * Winelib richedit support - one of the things needed by MFC - the API seems at least partly supported, but the headers are very incomplete - see bug 330 * Visual C++ project support - make it possible to generate a Winelib project from a Visual C++ project - this should be done by extending winemaker - see bug 61 * Specify how to compile and package the MFC - many applications use the MFC. To make Winelib useful it is necessary to make it easier to compile the MFC and MFC-based applications - winemaker has some support for the MFC. But it makes suppositions about how the MFC were compiled (library names, etc.). So it is necessary to document how to get something that works well - see bug 110 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

5 9

Re: We *really* need a development model change !
by Andriy Palamarchuk Jan. 3, 2002

Jan. 3, 2002

Alexandre Julliard wrote: > Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: >>Please comment on both my intended posting and the way I programmed the first >>version of the test suite (I'm not extremely happy with the current program; >>if you have any improvements, then get them here ASAP !). > > Look at programs/winetest, that's the tool we should use to write > tests IMO. Just looked at the tool. It only provides gateway from Perl to wine API functions, right? Advantages I see in using script-based tests: 1) tests can be used without recompilation 2) Perl is familiar to many developers 3) programming in scripting language is usually easier than in C 4) Perl is widely used for testing purposes and I expect to find many testing tools in Perl. Cons: 1) Many current Wine contributors don't know Perl 2) one more level of abstraction does not give significant advantages in this application. On the contrary, it is more difficult to locate cause of problems because developer has to go trough one more, often not familiar layer. Absense of strict typing in this layer will hurt a lot. Advantages of using C-based tests: 1) compilation has to be used to run the tests. In some cases this is an advantage. Before running the tests you'd better be sure it at least compiles in both environments. 2) C is the most familiar to developers language and the language itself is simpler than Perl 3) Documentation for Win32 API is C-oriented. Examples, given in documentation are in C or easy translated to C 4) Developers already have some testing code snippets in C Summary: Requirements to the unit testing tool: 1) should help to quickly create tests 2) easy to use, should help to involve as many developers as possible. 3) may be useful for developers, using Wine for there projects Because of the goals I'm more inclined to use C-based test suite. IMHO it is better suited for existing Wine developers audience and will provide us much bigger code pool. I'm even ready to have tests in both - Perl and C. The big question is a tool to test GUI. I did not find any OS Windows GUI testing frameworks :-( Comments, suggestions? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

11 60

[Shrinker] Another landmine
by Robert Baruch Jan. 3, 2002

Jan. 3, 2002

More stepping through the code, comparing Windbg to gdb, and I found another landmine. Shrinker gets the address of the NTDLL procedure LdrAccessResource, and looks for this code: FF74XXXX push [esp+X] E8XXXXXXXX call .... Instead, it finds an unimplemented procedure in Wine. So now I will look at LdrAccessResource (and friends) to see what's involved in implementing it, whatever it is. --Rob

7 11

Mixed-mode CD Labels
by Chris Green Jan. 2, 2002

Jan. 2, 2002

Hi, I've just experimentally, in my own copy of the CVS, changed the code in misc/cdrom.c so that it handles mixed mode CDs the same as data CDs for retrieving CD labels. (In the process of trying to get Age of Empires 1 to run in single-player mode). And surprisingly, it worked! (mind you AOE is not fast under wine, but that's another problem). Does anyone have any comments on this approach? if not I'll submit a patch... regards Chris Green

5 12

What have I done to my debugger?
by Bill Medland Jan. 1, 2002

Jan. 1, 2002

I'm getting the wrong sort of terminal. Why? I vaguely remember doing something to the registry settings for the debugger about a month ago but I can't remebber what. Since then I have not been tripping it anyway. However I am now investigating a problem that does trip the debugger. However it now comes up with an enormous terminal of some sort with terrible font and bad agreement between font and cursor positioning, so that important data disappears off the right of the screen before wrapping. However in the old days it used to use an xterm. I'd like to go back to that. Did I do that or is it a result of the stuff going on with the debugger? TIA Bill p.s. Merry Christmas to all.

3 6

current cvs doesn't compile with freetype-2.0.3
by Ben Stanley Jan. 1, 2002

Jan. 1, 2002

Hi, I tried compiling current cvs wine on RH 7.2, and it fails... gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o freetype.o freetype.c freetype.c:43:31: freetype/ftnames.h: No such file or directory make[2]: *** [freetype.o] Error 1 make[2]: Leaving directory `/share/building/wine/wine/dlls/gdi' It seems that the autoconf test for freetype/ftnames.h doesn't work properly. The file is not present in the RH package, and is not included in the freetype-2.0.3 tarball either. BTW, I'm not on the list atm. Ben.

2 2

mvcrt.ungetc and stdio buffering
by Waldek Hebisch Dec. 31, 2001

Dec. 31, 2001

Recently I tried to run g77 compiled Fortran program under Wine. It seems that to do any input g77 uses `ungetc'. Currently, Wine msvcrt has unbufferd stdio. I would like to add buffering and implement `ungetc'. Are there any traps (thread safety ??) or will strightforward implementation work ? -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

Re: Using windows dlls in unix shared libraries
by lawson_whitney＠juno.com Dec. 29, 2001

Dec. 29, 2001

On Fri, 28 Dec 2001, Robert Jonsson wrote: > Hi all, > > I just subscribed to this list, I hope my questions aren't evidently > answered elsewhere, I tried to do some homework browsing the docs and > parts of the mailing list, but then again I'm no pro so I might have > missed it. > > The background story: > There is a plugin system for professional audio applications in Windows > called VST. I suppose it does pretty much the same job as a multimedia > codec. With the exception that they have internally generated GUIs! > Perhaps a winamp plugin would be the closest match. > There is a similar format in Linux called LADSPA (www.ladspa.org) > Basically what I seek to do is try and wrap a VST plugin in a LADSPA plugin. > > The question: > I don't know that much about Wine internals, but all the example > applications I've looked at use the wine executable as boot loader. Does I thought to quibble with that, but it is a pretty fair analogy after all. Wine (including wineserver and wine builtin dlls) is a *NIX application, but it does provide "OS" services. It sort of needs an address space or two to kick around if it is going to be able to load native dlls that are not relocatable, FI. > that mean that this is the only way to start a wine application? Well, something has to be sure the wineserver is started. > The way I'd like to use it is like this: > Linuxhost (dlopen ladspaplug) - LADSPAplugin (LoadLibrary vstplugin) - > VSTplugin Can your ladspaplug not fork and exec wine to run your vst wrapper? > > A possible solution would be to startup the VSTplugin in another > application and do IPC between the LADSPAplugin and the > VSTplugin-proxyhost. > Like this: > Linuxhost (dlopen ladspaplug) - LADSPAplugin <----ipc----> > winebased_VSThost (LoadLibrary vstplugin) - VSTplugin > This does however seem akward... Is it possible to do it in an easier way? There isn't all that much to the wine executable these days. Most of Wine is in the builtin dlls and the wineserver. Have a look at <wine>/miscemu/main.c. If you think you can get that to run inside your plugin, maybe you can. Codeweavers did a crossover plugin whosis for linux browsers, I think, that would have had to address the problems. Lawson

1 0

Re: We *really* need a development model change !
by Andriy Palamarchuk Dec. 29, 2001

Dec. 29, 2001

Simplicity is one of the goals of the testing framework, but besides being simple the framework should be powerful enough for such big project. I'm looking for existing library which would suit our needs. Unit test framework "Check" looks promising. It provides many features which I'd love to use for our tests, including: - protection of the test address space - tests crashed do not put down the whole test suite and are reported. At the same time you can request to run tests in the same address space what is good for debugging. - grouping tests in suites, tree-like grouping of the test suites. You can choose to run only subset of the tests - having "set up" and "tear down" sections which can be used to set up tests and free resourses after. - a few forms of output - from silent to detailed Individual test looks like (section from manual): START_TEST(test_create) { fail_unless (money_amount(five_dollars) == 5, "Amount not set correctly on creation"); fail_unless (strcmp(money_currency(five_dollars),"USD") == 0, "Currency not set correctly on creation"); } END_TEST They also give information how to configure the tests with autoconf. The issues which need to be resolved: 1) License - GPL. Is it Ok to have the test suite under GPL? 2) Environment - POSIX. The library uses POSIX calls to manage processes, in particular functions fork, _exit, write, read, close, getppid, getpid, pipe. Calls "fork" , "_exit" and "getppid" are used only when test runs in FORK mode. We don't need to have address space protection under Windows - tests there should not crash. The rest of functions are used for communication between the test launcher and tests and can be implemented with using corresponding Win32 calls. After implementing these changes the framework can be used in pure Win32 environment, without Cygwin. Let me know if you are interested. I'll start to work on the port. Meantime we can start to use the framework under Wine and on Windows with Cygwin. More information about Check you can find here: http://check.sourceforge.net/ - home page http://sourceforge.net/project/showfiles.php?group_id=28255 - tutorial Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

2 1

Getting "Practice Exam" software working
by Dax Kelson Dec. 29, 2001

Dec. 29, 2001

We have a training room full of students who are taking a cisco networking design class. The class is basically all lecture so they don't normally use a computer, but tomorrow the students need to take a practice exam. The student workstations are running Red Hat Linux 7.2. Their student books come with a CDROM with a practice exam program that is, of course, a windows app. I've tried with the Wine that shipped with RH7.2, todays CVS snapshot, and Codeweaver's preview 5 all with the same results. It *almost* works. I would rather get it working so we don't have install windows just for them to run this one app. The problem starts up ok as seen in the screenshots 1 through 3 below. http://www.gurulabs.com/files/snapshot1.png http://www.gurulabs.com/files/snapshot2.png http://www.gurulabs.com/files/snapshot3.png http://www.gurulabs.com/files/snapshot4.png <- Problem here The problem is the sample questions and answers don't show up. http://www.gurulabs.com/files/snapshot5.png The "exhibits" seem to work fine. I'm using 100% builtin. There are no warnings or outputs that are displayed when exam question window starts. Any help would be greatly appreciated. Please save me from having to install windows on 13 computers. :) Dax Kelson

2 1

Using windows dlls in unix shared libraries
by Robert Jonsson Dec. 28, 2001

Dec. 28, 2001

Hi all, I just subscribed to this list, I hope my questions aren't evidently answered elsewhere, I tried to do some homework browsing the docs and parts of the mailing list, but then again I'm no pro so I might have missed it. The background story: There is a plugin system for professional audio applications in Windows called VST. I suppose it does pretty much the same job as a multimedia codec. With the exception that they have internally generated GUIs! Perhaps a winamp plugin would be the closest match. There is a similar format in Linux called LADSPA (www.ladspa.org) Basically what I seek to do is try and wrap a VST plugin in a LADSPA plugin. The question: I don't know that much about Wine internals, but all the example applications I've looked at use the wine executable as boot loader. Does that mean that this is the only way to start a wine application? The way I'd like to use it is like this: Linuxhost (dlopen ladspaplug) - LADSPAplugin (LoadLibrary vstplugin) - VSTplugin A possible solution would be to startup the VSTplugin in another application and do IPC between the LADSPAplugin and the VSTplugin-proxyhost. Like this: Linuxhost (dlopen ladspaplug) - LADSPAplugin <----ipc----> winebased_VSThost (LoadLibrary vstplugin) - VSTplugin This does however seem akward... Is it possible to do it in an easier way? Btw, I know about the avifile project, don't know the history but it is based on wine right? However, to my knowledge avifile supports only a very limited amount of API calls, ie no graphics/window calls (perhaps except some trivial ones). Which would probably make it pretty hard to implement the above...

1 0

err:heap:HEAP_CreateSystemHeap system heap base address 0x65430000 not available
by Rein Klazes Dec. 26, 2001

Dec. 26, 2001

Date: Wed, 26 Dec 2001 12:51:22 +0100 X-Agent-Group: X-Agent-Format: 0 0 0 0 0 500000 0 0 1 0 "*" 0 Hi, This patch makes a two of my programs fail with the subject error message: | ChangeSet ID: 1008789390367047399282455 | CVSROOT: /opt/cvs-commit | Module name: wine | Changes by: julliard(a)wine2. 01/12/19 14:16:30 | | Modified files: | dlls/kernel : kernel32.spec | dlls/ntdll : Makefile.in debugtools.c ntdll.spec rtl.c | dlls/ole32 : ifs.c | graphics/win16drv: font.c | include : heap.h ntddk.h winbase.h winnt.h | memory : heap.c selector.c | Added files: | dlls/ntdll : heap.c | | Log message: | Moved heap functions to ntdll. | Got rid of internal heap flags. | Reimplemented MapLS to not depend on the segptr heap. Both programs use native win98 commctrl,comctl32 dll's. One of them is CDmage, available at http://cdmage.cjb.net Any suggestions? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 2

We *really* need a development model change !
by Andreas Mohr Dec. 26, 2001

Dec. 26, 2001

Hi all, due to the number of regressions I found few days ago, it occurred to me that we really need an API test suite now. Thus I went ahead and implemented a test functionality for LoadModule16(). The result: 7 of the 21 tests that I implemented were FAILING !! That's ONE THIRD. And that for such a highly basic function as LoadModule16(). That's quite incredible. I guess we really should change our development model from trying tons of programs to *systematically* testing functions and Windows mechanisms now. If we can show everyone where stuff is failing, it might be a lot easier to attract new people. I attached a preview of the posting I intend to post on *tons* of Windows devel newsgroups ("Call For Volunteers"). That way we might actually get hold of hundreds of Windows developers helping us implement a complete test suite (complete tests of up to 12000 Windows functions). Not to mention the additional PR we might get out of this... If this works, then we'd need someone in charge of managing the assignment of specific windows functions to specific programmers. I won't do that (very limited time). Anyone from Codeweavers up to the task ? Or maybe someone non-developer and rather foreign to the Wine devel could do that task ? About the program: My goal was to get a program with very easy parsing interface: fields separated by colons, nothing fancy and difficult to implement, ... A .exe can be found at: http://home.nexgo.de/andi.mohr/download/wt_ldr16.exe Please comment on both my intended posting and the way I programmed the first version of the test suite (I'm not extremely happy with the current program; if you have any improvements, then get them here ASAP !). As 12000 Windows functions is an enormous number, I think we should really start doing this NOW instead of years later once Wine really needs this. Wine does not extremely need this yet, but we're getting pretty damn close to that already. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

3 2

Re: We *really* need a development model change !
by Andriy Palamarchuk Dec. 26, 2001

Dec. 26, 2001

C Unit test frameworks I found after a quick search: http://check.sourceforge.net/ http://people.codefactory.se/~spotty/cunit/ http://freshmeat.net/projects/autounit/ C++: http://sourceforge.net/projects/cppunit/ Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

2 1

Re: We *really* need a development model change !
by Andriy Palamarchuk Dec. 26, 2001

Dec. 26, 2001

Andreas Mohr wrote: > I guess we really should change our development model from trying tons of > programs to *systematically* testing functions and Windows mechanisms now. > If we can show everyone where stuff is failing, it might be a lot easier > to attract new people. I *completely* support this idea. Benefits of such test suite are enormous. Existing developers can contribute a lot by adding test snippets for the functions they create. Now they create such snippets anyway and throw them away. > I attached a preview of the posting I intend to post on *tons* of Windows > devel newsgroups ("Call For Volunteers"). That way we might actually get > hold of hundreds of Windows developers helping us implement a complete > test suite (complete tests of up to 12000 Windows functions). > Not to mention the additional PR we might get out of this... Lets ask for help only after the suite structure is more/less defined and we'll be able to give people something to work on. Comments: - Don't want to reinvent the weel. Is there any existing test suite framework we can use? Sorry, I can't suggest any for C but I'm very impressed with JUnit in Java. It is even Ok if the framework is GPLed or LGPLed - I don't think any company will make buziness based on the test suite. - I /personally/ prefer CL interface only for such suite - it would be better if the suite print summary information and information about failed tests only - make the test suite more "visible" for existing developers. Ask them to run the test suite before submitting a patch? - I think the suite test will consist from a few separate applications because different tests may have different requirements to GUI configuration, processes, etc. We need a way to run all the applications in one batch. - define variable which indicates whether the suite runs under Wine. Such indicator can be used for Wine "white-box" testing. - it would be greate to have functionality to support output comparison? For some functionality it is easier to write tests to compare output instead of doing explicit checks (e.g. tests, involving a few processes). The output can be redirected to file and files compared. If we use files we need to store files for Wine and a few versions of Windows :-( - the suite applications size will be pretty big. Is it better to move it to separate CVS tree? - what about running the suite weekly (or daily) automatically and publishing the results to wine-devel? - most developers on this list have access to one version of Windows. Is it difficult to create "testing farm" with remote access to a few versions of windows? This would help developers to test their code on a few platforms. Existing environments in the companies, involved in the project can be used. - I remember long time ago there was a post on wine-devel about using Perl or Perl-like language for unit testing. What is current status of that project? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

2 2

Cooperation between Odin & Wine
by Sander van Leeuwen Dec. 26, 2001

Dec. 26, 2001

Hi, As some of you might remember I'm the lead developer of the Odin project. (project for OS/2 with the same goals as Wine). Odin is partly based on Wine code. The core dlls (gdi32, user32, kernel32) + some special dlls (winmm, directx, winsock) use some Wine code, but is basically incompatible with Wine for obvious reasons. Most of the remaining dlls are based entirely on Wine code. The last few years there has been little cooperation between both projects for several reasons. One of them is that we have far fewer active developers and cooperation sometimes proved to be difficult. Some source files of the two project had grown apart since changes were never merged back into Wine. Now, I'm trying to change this situation, but am wondering how to proceed. I can post bug fixes to this list, but it will be difficult for me to actually test these changes in Wine itself. (too time consuming) Posting diff files is not always possible due to the major differences between source files. Merging changes from Wine into our source tree is no problem. We can do that ourselves. However, it would be nice if compiler incompatibilites (we use IBM VisualAge C++, not GCC) could be resolved. There aren't many, but the IBM compiler is not always as flexible as GCC and of course doesn't understand any GCC extensions. It would be a big help if incompatible code could be changed. Switching compilers is not an option for us. I can post a (small) list of changes we had to make. The license of our project is not compatible with Wine, but the dlls that are largely based on Wine (such as comctl32, shell32, ole) are an exception to the project license. The sources of those dlls are released under the Wine license. In case there is ever interest in the other sources, then you can just ask me. I'd be happy to 'donate' them to Wine. For more information about Odin you can visit http://odin.netlabs.org (some information is outdated though). There you can find out where to download the sources (cvs). The next post from me will contains some patches for bugs in Wine that I've recently found. Sander

2 2

CVS server
by Dimitrie O. Paun Dec. 26, 2001

Dec. 26, 2001

It looks like we're running an old version of CVS on the server, as it complains it does not understand #cvs up -C is it possible to upgrade it? That would be a good idea irrespective of the -C problem, as the new versions fixed quite a few (nasty) bugs. -- Dimi.

2 1

Re: Wine Tasklist (UNC)
by Mike McCormack Dec. 26, 2001

Dec. 26, 2001

Hi Francois, I think the best way to handle UNC pathes is to do it properly; Wine should talk SMB/NBT directly to other machines on the network, not through Linux's VFS layer. This approach would give high level of flexability to Wine. We could: * support NetDDE and DCOM with a common code base * use Windows file permissions and security properly * support unicode share names properly * support named pipes, etc across the network * eliminate SMB<->VFS<->SMB problems eg. parsing /etc/fstab There's three options: 1) write our own SMB code (wineserver talks NetBIOS/SMB) i have a short snippet of code to resolve NetBIOS names in CreateFile, but that is only the beginning of the effort. 2) link with a LGPL'ed CIFS implementation. http://www.ubiqx.org/libcifs/ (very incomplete, but maybe possible later, may still have threading issues) 3) get Samba to provide us with a Unix domain socket to talk with. (SambaTNG looks like the best bet there.) i have experimented with linking Wine to samba's libsmbclient and use it to open files. That works (i have a test patch), has threading and licensing issues (it's GPL). This would be alot of work, but i think it's the only way to do it properly. Mike > * UNC path handling > - for drives '\\.\e:', devices > - for network paths > - there's been a patch related to this recently but I believe it does > not cover all cases > - integrate with Samba to handle network UNC paths > - provide a way to mount/unmount drives at runtime, especially > network drives. One should be able to disable this in the config > file (for security reasons). > - Support for 'persistent' mounts... will require modifying the way w > specify which drives are mounted where. > - provide an applet to mount/unmount drives while Wine is running. ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Re: Bulletproof the debugger.
by Michael Stefaniuc Dec. 26, 2001

Dec. 26, 2001

On Fri, Dec 21, 2001 at 01:52:12PM -0800, Medland, Bill wrote: > Bill Medland (medbi01(a)accpac.com) > Don't ask me why but on my setup vsnprintf returned a value greater than This is the new and correct behavior according to the C99 standard. All snprintf function should return in error case the number of characters that would have been written to the buffer if the size of buffer would have been big enough. This change while usefull will brake a lot of things. IMO the glibc is still using the old behavior. bye michael > the size of the buffer (much bigger), resulting in the debugger tripping > a segment violation. > Considering the location of this code I see no problem with using belts and > braces; it isn't going to be executed much but when it is we want it to work > (despite braindead operating systems) -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 3

Patches for several bugs
by Sander van Leeuwen Dec. 26, 2001

Dec. 26, 2001

Hi, Here are the bug fixes I promised. There are more, but I can post those at a later time. - controls\button.c CB_Paint, line 806 hBrush = SendMessageW( GetParent(hwnd), WM_CTLCOLORSTATIC, hDC, (LPARAM)hwnd ); if (!hBrush) /* did the app forget to call defwindowproc ? */ hBrush = DefWindowProcW( GetParent(hwnd), WM_CTLCOLORSTATIC, hDC, (LPARAM)hwnd ); -> (Auto)Check, (Auto)Radio & (Auto)3State buttons send WM_CTLCOLORSTATIC instead of WM_CTLCOLORBTN (verified in NT4) (fixes opening dialog buttons in Opera 6 (choose interface)) - dll\user32\text.c TEXT_GrayString, line 499 if(!hdc) { DeleteDC(memdc); return FALSE; } -> DC leak - COMCTL32: Comboex, rebar, tooltips, toolbar: NEVER delete the font object received by WM_SETFONT -> See attached diff files for comboex, rebar & toolbar. Our tooltips has too many differences for diff to produce usable output, but the changes are similar to the other three. - COMCTL32: Tooltips: wrong COMCTL32_Free calls -> 4 calls with wrong pointer: COMCTL32_Free(&lpttsi); should be COMCTL32_Free(lpttsi); - user32: frame tracking * - Only draw changed track frame instead of clearing the old one and * drawing the new one (less flickering) * - Send WM_MOVING when moving a window * - Send WM_SIZING only when sizing a window * - Fixed handling of rectangles changed by WM_SIZING/MOVING -> Can't easily produce diff file. Too many changes. (check src\user32\wintrack.cpp in our CVS tree) - USER32: groupbox redrawing fixes -> I am not 100% sure the same happens in Wine, but it looks like that. When an application changes the font or the text of a groupbox (smaller font or fewer characters), then the old text has to be erase properly or else you'll still see part of it. If I remember correctly, that could be seen in Opera 5.12 (property dialogs) -> Again, too many changes to produce a diff file. (check src\user32\button.cpp, BUTTON_SetText & BUTTON_SetFont) - USER32: static control -> our version supports more styles (SS_CENTERIMAGE, SS_REALSIZEIMAGE) and features (SS_ENHMETAFILE) (src\user32\static.cpp) Sander

1 0

Re: DOS packing patch (fix)
by Lionel Ulmer Dec. 25, 2001

Dec. 25, 2001

Hi all, I am a bit worried by this patch : I looked at how "pshpack1.h" works, and it uses the '#pragma pack(1)' method when compiling with GCC. > +/* WARNING: one byte packed structs from here !! (i.e. not DWORD aligned) */ > +#include "pshpack1.h" > + And I wonder if this really works as with the latest versions of GCC (2.95.3 onwards AFAIK), '#pragma pack(1)' is ignored (at least on my self-compiled GCC :-) ) and you need to use the '__attribute((__packed__))' construction after each structure. But well, I may say completely stupid things as otherwise a lot of bugs would exist in Wine... Lionel PS: Merry Christmas all :-) -- Lionel Ulmer - http://www.bbrox.org/

1 0

16 bit comm issue
by Mike McCormack Dec. 24, 2001

Dec. 24, 2001

Hi, There's a problem with the current 16bit comm architecture which i'm not sure how to solve correctly. If a 16bit Windows programs uses EnableCommNotification to receive WM_COMMNOTIFY messages then sits in a message loop waiting for them, it will never receive them because there is no chance for APC that sends the message (COMM16_ReadComplete) to run. I have a patch for this problem which puts an alertable wait in GetMessage(16), which i posted in October. What is the problem with this method, and is there a better solution to the problem? Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

DOS stuff pretty much broken [Re: wine/ dlls/kernel/kernel_main.c dlls/kernel/wp ...]
by Andreas Mohr Dec. 24, 2001

Dec. 24, 2001

On Tue, Dec 04, 2001 at 02:54:50PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 1007495689308334133587778 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine2. 01/12/04 14:54:50 > > Modified files: > dlls/kernel : kernel_main.c wprocs.spec > dlls/ntdll : Makefile.in ntdll.spec > dlls/winedos : Makefile.in dosvm.c int09.c module.c > winedos.spec > graphics : dispdib.c > include : callback.h miscemu.h > miscemu : main.c > msdos : Makefile.in dosmem.c dpmi.c int20.c int21.c > int2f.c interrupts.c ioports.c > Added files: > dlls/winedos : devices.c dosaspi.c dosexe.h int10.c int16.c > int17.c int19.c int20.c int21.c int29.c int31.c > int33.c ioports.c vga.c vga.h xms.c > Removed files: > include : dosexe.h vga.h > msdos : devices.c dosaspi.c int10.c int16.c int17.c > int19.c int29.c int33.c vga.c xms.c > > Log message: > Moved most of the real-mode stuff to dlls/winedos. > > Patch: http://cvs.winehq.com/patch.py?id=1007495689308334133587778 This one probably breaks a whole heap of older Win3.x apps. When I started the Win98 setup.exe for fun, it choked on int 0x21 "list of lists" (DOS_LOLSeg not initialized). Trouble is that we initialize DOS variables in case of DOS programs *only*. This is rather fatal IMHO, especially in the case of List Of Lists, which is a pretty important structure with lots of information that some Win 3.x programs might rely on. Thus DOS stuff should be reorganized somehow. Any suggestions ? IMHO probably winedos should get loaded as soon as DOS3Call() gets called even once. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 1

fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.
by Laurent Pinchart Dec. 24, 2001

Dec. 24, 2001

When trying to install The Longest Journey (an adventure game), I ran into a problem with modal message boxes. The installer displays at some point a task modal message box, but for some reason the box disapears almost instantly, and I'm stuck with a focused installshield screen on which I can't do anything as the task modal msgbox is invisible and unfocused. I'd like to implement the modal message boxes to fix my problem, but I don't know where to start. Could someone give me a few indication about what would be required to achieve a proper behaviour or modal message boxes ? Thanks. Laurent Pinchart

4 8

Terrible bug: WinExec16, DOS programs
by Andreas Mohr Dec. 24, 2001

Dec. 24, 2001

Hi all, I just found out that WinExec16 doesn't even support starting DOS programs. Whereas LoadModule16 doesn't seem to support loading DOS programs (error 22, which is not documented for LoadModule16), WinExec16 definitely does launch command.com on Win98SE. Not so when using Wine. What to do about that ? More specifically, which functions to change how exactly to support this ? (the whole interoperation between WinExec, WinExec16, LoadModule*, LoadLibrary*,CreateProcess etc. is highly problematic). This thing makes me get slightly worried about our Win16/DOS compatibility as a whole... :-\ -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0