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

Windows screensaver.
by gleb＠nbase.co.il Dec. 24, 2001

Dec. 24, 2001

Hello all, Perhaps this was asked before, but I didn't find the answer. Is it possible to run windows screensaver in linux using wine? If not, how hard it will be to write support for this? Thanks, -- Gleb.

2 2

Re: License debate conclusion
by James Tabor Dec. 23, 2001

Dec. 23, 2001

Dan Kegel wrote: > > Roger Fujii wrote: > > I'm sad. The LGPL seems like the clearest hope we have of protecting > Wine against companies that want to take it and never contribute code > back. Its protection might not be airtight -- but it would clearly > communicate the spirit. And my impresson was that the majority of > Wine developers agree. > > > - Dan Hum????????? Like the ODIN Project! James

1 0

Re: License debate conclusion
by Dan Kegel Dec. 23, 2001

Dec. 23, 2001

James wrote: > > Dan Kegel wrote: > > I'm sad. The LGPL seems like the clearest hope we have of protecting > > Wine against companies that want to take it and never contribute code > > back. Its protection might not be airtight -- but it would clearly > > communicate the spirit. And my impresson was that the majority of > > Wine developers agree. > > Like the ODIN Project! Good point. The ODIN project's license is at http://odin.netlabs.org/License.phtml There was some talk of sharing code between Wine and Odin in 1999; see http://www.winehq.com/News/1999-50.html#0 We might want to update http://www.winehq.com/others.html to reflect the current status and license of the Odin project. I'm not quite sure whether the Odin license is compatible with the LGPL. It looks fairly GPL compatible, but I didn't look hard. - Dan

1 0

Re: License debate conclusion
by Roger Fujii Dec. 23, 2001

Dec. 23, 2001

Alexandre Julliard <julliard(a)winehq.com> wrote: > > My conclusion is that there clearly isn't enough support in the > developers community to justify changing the license. So I'm not going > to proceed with any change, either now or in the foreseeable future. hurrah. before this is concluded, I will add one thing just for the sake of archival (in case this comes up again). If ALL of wine were strictly LGPLed, basically, *all* propriatary extensions could no longer be included. Why? Because the output of winebuild will be LGPLed, thus no propriatary programs could use its output in creating a shared library. winebuild is like bison in this case, and the output of bison has a special exemption so that you can use it in something other than *GPLed programs. This inadvertant problem is precisely why *GPLed stuff has to be scrutinized carefully if you care about commercial relationships (most *GPL projects don't care) and is why commerical interests are wary of projects with a *GPL license. -r

6 6

[Fwd: Re: License debate conclusion]
by lee Dec. 23, 2001

Dec. 23, 2001

> I think it's clear that Wine cares, and should be careful not to alienate > companies like Codeweaver and Transgaming. One way to deal with Transgaming > might be to start a campaign to get people to buy Transgaming subscriptions, > or perhaps try to rummage up enough of a one-time payment to get Transgaming > to contribute their current changes back. I suspect that there's some > such arrangement they'd be happy with. I tried to do just that and got rejected ( error after submitting and didn't want to try 'again' until they contact me ) by the online payment system for some odd reason....I wonder how many others have experineced this ( I checked my input twice and had all *'s filled out )........granted it could be isolated in that I made some minor goof on form..-we'll see. just a fyi in case it wasnt' me.. lee -===

1 0

Re: [PATCH] forward tab notification to the parent
by Andreas Mohr Dec. 23, 2001

Dec. 23, 2001

On Sat, Dec 22, 2001 at 02:31:56PM +0000, Gerard Patel wrote: > The following patch : > ChangeSet ID: 1008622332606314052827656 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine2. 01/12/17 15:52:12 > > Modified files: > dlls/comctl32 : tab.c > > Pass on all unhandeled messages to the owner. > > leads to bad regressions with some apps. > > The attached patch has the same positive effect on hh.exe > but without the regressions. Confirmed: That patch had horrible effects on desk.cpl. Applying your patch fixed it. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

fixme:win32:DeviceIoControl Unimplemented control 256 for VxD
by Matts Kivik Dec. 23, 2001

Dec. 23, 2001

[root(a)localhost Visual Pinball]# wine Vpinball.exe +relay +snoop +vxd x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403b4be8,00010022,2):stub fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403b50c4)->(00000000,00001008) fixme:commdlg:GetFileName95 Flags 0x00000002 not yet implemented fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device NWLINK wine: Unhandled exception, starting debugger... I get the following errors when trying to run a windows program called Visual Pinball. Wine release 20011108. In addition to the crash, the toolbars are not drawn. Some tools in the toolbars are drawn when I "hoover" over them with the mouse. I another thread I have read that the VNETBIOS call is to check the MAC adress, but what is the NWLINK doing ? _____________________________________________________________ Want a new web-based email account ? ---> http://www.firstlinux.net

1 0

Re: CVS regression.
by Gerard Patel Dec. 23, 2001

Dec. 23, 2001

At 02:30 PM 22/12/2001 -0800, you wrote: >I'm in the processess of doing a cvs regression to find out what broke >half-life in the main wine. The first problem appears in the "2001-11-8 >EDT" cvs, but it's not the same promlem as I was having with the current >cvs. That one occured between the "2001-11-15 EDT" cvs and the "2001-11-13 >EDT". > >But unless anyone has any ideas I though I'd start working on what patch >did it, and I was wondering if "2001-11-13 EDT" was the cvs at the >begining or end of the day (before or after that days pathces were >applied). And if the dates in the wine.cvs newsgroup are accurate. > >I'm rather new at this so any advice would be welcome. Did you read documentation/cvs-regression ? I updated some weeks ago to add precisely that you can use times up to the second so that it's possible to apply each patch separately. I use http://www.winehq.com/hypermail/wine-cvs/ to find exact patches times. > >P.S. The error i'm looking for is a timeout of a CriticalSelection when >you try to join a mulitplayer game. The one I found in the "2001-11-8 EDT" >cvs is an unhandeled exception when it first goes to the "Loading..." >screen. > Unfortunately, it is not impossible that a first breakage is completed by another a few days after. The more important breakage to find is the first (unless the second breakage is an attempt to fix the first) Another possibility is that the 2 problems are only different manifestations of a single problem; you can have a thread crash nicely, triggering the debugger, or in different circumstances nastily, without much messages. In the latter case, it can happen that another thread is blocked by the crashed thread and displays a critical section wait timeout. It will not be possible for me to help you more until next year, I'll not have internet access until then. Good luck. Gerard

1 0

CVS regression.
by Daniel Sabo Dec. 22, 2001

Dec. 22, 2001

I'm in the processess of doing a cvs regression to find out what broke half-life in the main wine. The first problem appears in the "2001-11-8 EDT" cvs, but it's not the same promlem as I was having with the current cvs. That one occured between the "2001-11-15 EDT" cvs and the "2001-11-13 EDT". But unless anyone has any ideas I though I'd start working on what patch did it, and I was wondering if "2001-11-13 EDT" was the cvs at the begining or end of the day (before or after that days pathces were applied). And if the dates in the wine.cvs newsgroup are accurate. I'm rather new at this so any advice would be welcome. P.S. The error i'm looking for is a timeout of a CriticalSelection when you try to join a mulitplayer game. The one I found in the "2001-11-8 EDT" cvs is an unhandeled exception when it first goes to the "Loading..." screen.

1 0

For review... CD interfaces in wine
by eric pouech Dec. 22, 2001

Dec. 22, 2001

not ready yet for cvs inclusion (yet), this patch implements two things: - it replaces the wine internal & proprietary cdrom interface (used in MCICDA and MSCDEX/int2F) with the proper win32 ioctl:s calls - it allows opening any device with CreateFile (using the name "\\.\E:") (this is still very hackish, but not worse than what already existed) patch posted for review/comments/enhancements... (before I go on vacation, in case someone would work on something equivalent) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 22, 2001

Dec. 22, 2001

> On Fri, 21 Dec 2001, Patrik Stridvall wrote: > [...] > > > > However, just because it doesn't combine to something normal > > > > doesn't mean that is doesn't combine. > > > > > > And how does it combine exactly? Both the book and the > critic are > > > available independently. > > > > > > You can still read the book independently from the critic so > > > they are obviously two separate pieces of work, not a single one. > > > > > > Or how do you define 'combine'? > > > > I do not define combine in any general way. It depend on > what my intent > > is and on the circumstances. I do not expect others to > nessarily define > > combine in the same way either. > > I would say that piece of work 1 combines with piece of > work 2 if it > alters piece of work 1 and results in an entity that a user would > consider to be a single piece of work of the same type. > > Now I believe this is a more restrictive and reasonable > definition of > 'combine' and should match general expectations better than your > 'everything combines with everything if I decide so' definition. What a user would consider a single piece of work depends on the user so it is very vague and unsuitable definition in a court of law. > [...] > > > So you agree that gratis, open-source and commercial > works are all > > > entitled to the same copyright protection. The last two > paragraphs of > > > your email seemed to imply differently to me. > > > > Yes, it is entitled to the _same_ copyright protection. > > Good. We agree on something! :-) > > > > However since you give away your work gratis to the end user by > > your free choice, you have the right to stop doing this(1), > > if anything I sell to the end user bothers you. > > Yes, or as the copyright owner I have another alternative: choose a > license that restricts what you can do with my work. I can even choose > to use multiple licenses and tell you to which one you must abide by > depending on how much money you give me. And no matter how much or how > little you pay me, you must abide by this license, this at least we > agree on, so that's good. > And if I say that you must not redistribute work based on mine then > you must comply. And basically saying 'take his work and then apply my > modifications' still has the same effect: the user magically > gets a copy > of your work which is clearly based on mine. So the end > result is still > that you are redistributing a work based on mine which is > precisely was > forbidden by the license agreement. No, the license is not a contract, and even if it was it can't override the original contract that you implicitly made with society to get any copy protection at all. The license can only be about the rights granted to you by society to your work and while you certainly can deny me, as normal commercial licenses do, that right do redistribute, you can only deny me the right to do derived works to the extent copyright law defines a derived work.

1 0

License debate conclusion
by Alexandre Julliard Dec. 21, 2001

Dec. 21, 2001

OK folks, I think we are way past the end of the useful part of this discussion, and it's time to come to a conclusion. I'll ask people who want to continue arguing the fine points of the LGPL to please do it by private mail. My conclusion is that there clearly isn't enough support in the developers community to justify changing the license. So I'm not going to proceed with any change, either now or in the foreseeable future. Thanks to everybody who participated to the discussion, and now let's go back to writing code... -- Alexandre Julliard julliard(a)winehq.com

1 0

Latest OSS changes and Pajam Sam, again
by Ori Pessach Dec. 21, 2001

Dec. 21, 2001

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, For what it's worth, I've been testing those troublesome games from Humongous with newer versions of Wine. Up until Nov. 9th, they worked fine. Afterwards, they started failing with a difficult to diagnose error message on startup, saying that the sound card was not detected. I tested this with OSS and ALSA sound drivers. The latest version fails after playing a sound on startup. I get two error dialogs - the first says: "The sound card driver is refusing to accept our sample", the second says "The sound card driver will not unprepare our sample header". I'm also still getting "err:wave:OSS_AddRingMessage buffer overflow !? " messages. I have the feeling that these messages should give someone who's familiar with the code a bit more to go on. waveOutUnprepareHeader() seems like a good place to start, and I'll look at it myself when I have the time for it (not soon), unless somebody else figures it out first. Bye, Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.oripessach.com iD8DBQE8Ip0kzA/uWWyw6uQRAgeUAJ9K2NvscRvz0ciAvvsWqVF/3M1qBACfe8QA k8KtoVC5TIP2cYhONTWbLlk= =17aJ -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> On Fri, 21 Dec 2001, Patrik Stridvall wrote: > [...] > > > - a critic's book about the original is not a derived piece > > > of work. It > > > is clearly specific to the original book but does not > modify it and > > > clearly does not combine with it to form a single piece of work. > > > (no real equivalent to this one, closest thing would be an > > > application/script that uses another, like a script that > calls 'ls') > > > > This is not all clear IMHO. What a single piece of work is not > > well defined. Sure a combined work will not be a book since a book > > normally is something that can be read in linear order and combining > > with the critisism will not likely form a normal linear book. > > > > However, just because it doesn't combine to something normal > > doesn't mean that is doesn't combine. > > And how does it combine exactly? Both the book and the critic are > available independently. > > You can still read the book > independently from > the critic so they are obviously two separate pieces of work, not a > single one. > > Or how do you define 'combine'? I do not define combine in any general way. It depend on what my intent is and on the circumstances. I do not expect others to nessarily define combine in the same way either. However, the problem is that you (or rather the law) must define what combine means for your: "Can't legally distribute, is derived work" to have any meaning. > [...] > > > > > > From my point of view open-source is not any different from any > > > commercial work. Obviously there are legal means to obtain > > > the original > > > work in both cases (whether you have to pay for it is irrelevant). > > > Otherwise the point is moot. > > > > > > But saying that open-source is different would mean that > > > because you > > > are not making a direct profit from this work, you are > not entitled to > > > any protection under copyright law. You can't mean that, can you? > > > > But you _have_ protection from copyright, everybody that > _distribute_ your > > work must fullfill the license otherwise you can sue them. > > So you agree that gratis, open-source and commercial works are all > entitled to the same copyright protection. The last two paragraphs of > your email seemed to imply differently to me. Yes, it is entitled to the _same_ copyright protection. However since you give away your work gratis to the end user by your free choice, you have the right to stop doing this(1), if anything I sell to the end user bothers you. (1) Of course you, by your free choice, choose to give the end user the right to redistribute as well so, he can legally give it to his "friends" all other the world, but that is not my problem either. Note that I not saying that your choice was wrong, but you shouldn't complain that rights that you gave up by _free_ choice have been used against you.

2 1

Re: Visual FoxPro 5 apps
by Rick Romero Dec. 21, 2001

Dec. 21, 2001

I just noticed that my Foxpro 5 post is on WWN, so I thought I'd share the thread from the wine-users list... Rick On 5 Dec 2001 at 13:34, Rick Romero wrote: > On Wed, 2001-12-05 at 13:22, gerard patel wrote: > > On 05 Dec 2001 11:55:10 -0600, Rick Romero <rick(a)valeoinc.com> wrote: > > > > <snip window problems> > > > > >Now I've tried a few different distro's, and quite a few different > > >releases of wine (been compiling from cvs for the last couple months), > > >so I don't think it's just me... BUT. > > > > Try with Wine from 01 june 2001. > > Huge changes have caused several severe regressions > > after this date and they are mostly unfixed. > > Well, I downloaded Wine-20010510, and the MDI windows work PERFECTLY. > They're highlighted blue when active > The scrollbars work > The mouse click is released. > > Although overall, it doesn't work near as well.. > > > > > If your app has the same glitches with Wine as of 01 june > > 2001, its problems are not related to the general regression. > > In this case try to do this, I'll take a look. > > In the other case, it's unnecessary as I'm already aware of > > these problems. > > If I'm not imposing too much, could you point me in the right direction? > > I don't know if I could come up with anything of 'acceptable patch > quality', but I'd like to try. > > Is the problem in mdi.c? > If it was only a simple bug, I'll have it killed since a long time. I'm mostly in the dark, but I think it's more the progressive passage to a whole new design that has caused a string of regressions. Gerard ----- Valeo, Inc. will be closed for the Holiday season starting on December 20, 2001 through January 1, 2002 resuming business on January 2, 2002. We wish you a Happy Holiday Season! -- Rick Romero IT Manager Valeo, Inc. ph 262.695.4841 fax 262.695.4850 rick(a)valeoinc.com

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> On Fri, 21 Dec 2001, Patrik Stridvall wrote: > > > There are many thing that are important in the world not just one, > > so it was just a reaction of your persistance that the spirit of > > something is the only thing that matters. > > I focused on the spirit to put some sense in the discussion, > go get to the > point where we agree to disagree, but you don't seem to want that. > > In computers we have interfaces and implementations. It's healthy to > separate the two. Yes, but this doesn't mean that this is always possible. > In our case, the interface is the spirit of > the LGPL, > while the implementation is the LGPL itself. > > If there are 'Gapping Holes' anywhere, they are in your > arguments. You say > you agree with the interface, but you disagree violently with the > implementation. On the other hand, when I ask you for a different > implementation, you can't it can not be done. I say that it can't be done without having a copyright law that will be unacceptable in other ways. > Patrik, you > can not agree > with an unimplementable interface, for crying out loud!!! You > have to make > up your mind and choose! I would very much like to have "Peace on earth", but I don't think it every will be "Peace on earth". You can call that illogical if you wish. It is up to you.

1 0

license discussions
by Marcus Meissner Dec. 21, 2001

Dec. 21, 2001

Hi, Could we please create a new mailing list wine-license, where all the people who care about licenses can discuss them? Ciao, Marcus

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > Does it nessararily follow that you wish to accept any means to > > achieve this? Including, say, to be really extreme: > > "Nuke the middle east, then it will be peace there" > > and after enough nukes it probably WILL be peace, > > so it would be entire in line with peace on earth. Right? > > Patrik, if you think licensing software under the LGPL is > equivalent to > nuking the middle east out of existence, you need to take a _deep_ > breath, drink some cold water, and stay away from those pills. > > Since we're here, this is the type of attitude that really > destroys the > credibility of much of your arguments. It was purposely extreme to illustrate that you can fullfill the spirit of something good with very bad results. There are many thing that are important in the world not just one, so it was just a reaction of your persistance that the spirit of something is the only thing that matters. > I mean, exagerations > of the form: > 'LGPL gives you nothing, it's a pile of crap' despite the > enormous effort > put in it by various lawyers and law professors from reputable > universities, will not buy you many friends. Do you really > think that the > entire law establishment in the US has all gone mad and can't see the > 'Gapping Hole' in the LGPL, and you were the chosen one to see it? I'm sure they all have worked very hard, however as in the extreme example above, all means to achieve something is not nessarily good, if seen as a whole. The meant this time is the doctrine of derived work, which since it is one of the few means they got it was naturely the choice. However, a to strong doctrine of derived work, is not good from other points of views so it will be entirely possibly that the courts will not rule in their favour.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > No, its not irrelevant because it will effect the advise the company > > lawyers give their clients. > > But know you are inconsistent with yourself. You've been > claiming that it > is the very spirit of the LGPL that would scare companies > away, and I can > see some merit to that idea. No, I have been say that the _means_ to implement the spirit of LGPL might scare away companies. > You've also been claiming that > the LGPL may > not be enforceable, thus in mathematical terms, > the expected value of the LGPL < the intended meaning of the LGPL > it follow directly, that the more you are right, the less negative the > advise of the lawyers. Only if lawyers have certain mathematical properties, which they certainly do not have. Actual most functions don't have such properties either. > So, if you 100% right, the LGPL would become BSD, and the > lawyers would > give the same advise, as for the BSD. If you are 100% wrong, > then we do > get the full protection of the LGPL, and we're happy. > Anything in between > is a linear combination of the two. In any case, there really > is no point > about bitching the doctrine of derived work. QED. LGPL can only be BSD if the doctrine of derived work is very weak, so it does have something to do with that. > In fact, choosing the LGPL is a very nice way of hedging our > bets agains > future changes in copyright law. And this is so because of > the negative > feedback loop that the LGPL introduces agains the copyright > law. Brilliant. Now you are contradicting your self. You said earlier IIRC something about that you shouldn't believe that the license Wine chooses effect copyright law.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > Sure it is true that what people (read: companies) believe > is true is > > more important than what really is true. > > So, in fact, you indirctly agree that arguing about the doctrine of > derived work as part of this discussion is irrelevant. No, its not irrelevant because it will effect the advise the company lawyers give their clients. You seem to wish to use ignorance (or uncertainty) as weapon to protect Wine, but know this: Ignorance (or uncertainty) cuts both ways. Gav has said that Transgaming or for that matter Corel would have use Wine if it had been LGPL:ed. Perhaps this was because of ignorance, perhaps not. Anyway even if you would be able to convince Gav that he was/is wrong, you must realize that Gav IIRC have researched legallity issues extensively so it is entirely likely that somebody else spending similar resources would come to the same, in your opinion wrong, conclusion. In short: Ignorance (or uncertainty) is a dangerous weapon. > All you seem to be saying is that you think that the _spirit_ > of the LGPL > would be detrimental to Wine since it will drive companies away. > > Right? No. I have been trying to explain just because to are for the spirit of something it is not nessarily so that you support all possible means to acheive something and sometimes any acceptable means to acheive something might not exists. Do you support the spirit of: "Peace on earth!" Does it nessararily follow that you wish to accept any means to achieve this? Including, say, to be really extreme: "Nuke the middle east, then it will be peace there" and after enough nukes it probably WILL be peace, so it would be entire in line with peace on earth. Right?

2 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > But why should I do that? > > I can for example write a script that download Wine for the > end user user > > and apply the patch automatically. > > The patch would be considered a derivative work, so distributing it > would also violate the LGPL. That again is dependent of the doctrine of derived work have any meaning since the patch is written by me and only contains my work. Just because you build upon somebody else work doesn't mean it is a derivation. Anyway since it denies my right to speech it must be constitional within the context of the first amendment which is IMHO very unlikely that a strong doctrine of derived work is. The copyright clause exception only reserves only gives congress the right to give exclusive rights to _their_ work not to the work of others (read: me). Note by patch I do not nessarily mean a patch like (diff -u) that contains the (LGPL:ed) context of the patch. An "ed-script" or whatever similar will do. Anyway the LGPL:ed context of a (diff -u) patch might very well be consider fair use so that might not be relevant.

4 4

Re: CryptoAPI (no, this has nothing to do with licensing! YAY!)
by David Elliott Dec. 21, 2001

Dec. 21, 2001

On 2001.12.20 11:52 Travis Michielsen wrote: [BIG SNIP] > Actually I too, have been hacking away at the CryptoAPI (advapi32.dll) > and > was going to submit a full patch for it at the end of the week. My > patch, > however, has almost a completely different approach to the problem! > Attached is my version (not quite complete or clean). > > These are the main differences and issues I see between our patches: > > 1) I can successfully acquire/release a context (tested with MSDN sample > code). I have not experienced any problems with <loading> a CSP. Umm, yes, I can successfully acquire and release when testing with the MSDN sample as well, but not with RSAENH.DLL that IE wants. > 2) Currently the ms CSPs can perform but all launch pstores.exe - the > protected stores service. This is fine except that it eventually crashes > > with an unhandled exception c0000005 and then becomes unwilling to start > again. Pardon my ignorance, but I didn't realize that that was what pstores did. > 3) Dependancy functions of pstores and M$ providers not implemented: > (advapi:RevertToSelf, ntdll:NtOpenProcessToken, advapi:SetThreadToken, > mpr:WNetGetCachedPassword, etc.) Yup, if pstores is necessary, we'll need pstores working, so that's something to add to the task list. > 4) I do not create any list of providers. This should not be required as > the > registry is supposed to contain the list of available providers. Once a > handle is acquired then we can gain access to the provider by this > handle. > Note: Key and hash objects need to link to the provider handle, when they > are > created. As for the key and hash: Yes, I am well aware of this, there is a blatant FIXME in the code since I haven't gotten there yet. And I don't know where you get that I am making a list of all CSPs. What I am doing is making a list of any CSPs which are in use and storing the appropriate function pointers in that object. I could simply do a loadlibrary each time the CSP is loaded and store all of that information for every context. But I thought it would be better to do it the way I did so that if multiple contexts are acquired from the same provider we don't have duplicate information in memory. > 5) I have not yet considered thread or process safing/locking. Nor have I > > done any reference counting. Well, I am not so sure about my thread safety but I think theoretically it is okay. I wrote the thread safety in from the beginning. > 6) Seting and getting Key/Hash/Prov Params doesn't consider flags not > used by > the CSP and have meaning in advapi32.dll. Haven't even really gotten that far yet. > 7) I currently do not allow a CSP to drop any of the stardard functions. > > This only affects a few functions, however, as MSDN states these > functions > are *required* for the CSP to have. If they are not implemented they > must > set the last error as ERROR_CALL_NOT_IMPLEMENTED. Well, CSP.DLL from the CSPDK does not provide a couple things. Originally I required every function to be provided but when I found that CSP.DLL did not provide one of them I decided to err the other way and only require the bare essentiallys like Acquire/ReleaseContext. > 8) You seem to make not use > ?????????? > Anyway I think the correct thing to do right now is to co-ordinate our > work > to make a single patch and implementation. > YES, definitely. Sorry to be stepping on your toes here. Most of the CryptAcquireContext function, specifically the parts that look up which CSP we need to load, I implemented rather quickly months ago. I didn't have time to do anything until a few days ago when I wrote everything else and posted it on wine-devel. > I am currently testing this code against windows 98. > Well, I have Win95osr2 running under Win4Lin and I use that as my C: drive in Wine as well. It works a lot better having everything stored on an ext2 drive than on vfat. I have not yet taken a look at your code but will do so as soon as I finish reading the rest of today's wine-devel. -Dave

1 0

Re: timed-out non-overlapped ReadFile
by Mike McCormack Dec. 21, 2001

Dec. 21, 2001

Hey Lawson, Cool. i just wanted to get apps like yours back to their working state. Ideally i need to add a bit more code for the case (ReadIntervalTimeout = -1) that waits until at least some data is received before returning.... more trouble :-) The timeouts for non overlapped ReadFile should help alot of the recent problems reported on wine-users... hopefully. Mike Original message from: lawson_whitney(a)juno.com .. >Sorry if that sounded like faint praise. The app works as well with >both patches as it did before with neither, and probably there is some >other app that needs non-overlapped ReadFile to time out. > >Thanks! > >Lawson ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: timed-out non-overlapped ReadFile
by lawson_whitney＠juno.com Dec. 21, 2001

Dec. 21, 2001

On Fri, 21 Dec 2001, Mike McCormack wrote: > > This patch handles the special case where > ReadIntervalTimeout=MAXDWORD, ReadTotalTimeoutConstant=0 and > ReadTotalTimeoutMultiplier=0 a little better. We should just wait > until we get some data, then read it and return in that case. > > Mike > > ChangeLog: > * handle ReadIntervalTimeout=MAXDWORD special case a bit better > Sorry if that sounded like faint praise. The app works as well with both patches as it did before with neither, and probably there is some other app that needs non-overlapped ReadFile to time out. Thanks! Lawson Slowly but with considerable uncertainty.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> > You forgot that the end user still need to legally get hold of > > the work somehow. For normal commercial stuff this involves > > paying for it and the author will get payed just like he did in > > the old non-digital world for _each_ copy. > > I did not forget that. Good because this is _very_ important. > But I still do not think a book author would > allow you to publish a patch that would modify the last chapter to > provide a different ending. Why, if people like the alternative ending and recomend it to other he might get increase sales because presumeable they want to read the begining. Anyway, we a talking about what is legal and what is not, so that doesn't matter. > The point is that whatever way you use to distribute your > modifications, they are specific to the original work, alter it and > combines with it to provide a single new work. And these are the > criteria I would use to define a 'derived piece of work'. > > And since > derived pieces of work reuse the original work it seems only fair that > they can only do so if they respect the license of the original work. I might sound good from a open source perspective but it nearly isn't as attrative applied to normal commercial works. > Let's take a couple of common sense examples and assume that the > original work is a book. > - a bottle of black ink is not a derived piece of work. Obviously you > can alter the book quite a bit by dropping its content on it > and the ink > will definitely merge with the book. But just as obviously the ink is > not specific to your book. > (computer science equivalent: a file compression utility) First of all since we have a physical object we defintively in addition have the doctrine of first sale so inkstaining your book and reselling it is specifically allowed by law. By selling it the author lost control over that copy. > - a critic's book about the original is not a derived piece > of work. It > is clearly specific to the original book but does not modify it and > clearly does not combine with it to form a single piece of work. > (no real equivalent to this one, closest thing would be an > application/script that uses another, like a script that calls 'ls') This is not all clear IMHO. What a single piece of work is not well defined. Sure a combined work will not be a book since a book normally is something that can be read in linear order and combining with the critisism will not likely form a normal linear book. However, just because it doesn't combine to something normal doesn't mean that is doesn't combine. > - as long as you have the right to sell the original book, you should > have the right to sell it bundled with other books. The reason is that > this does not alter the original book and that it does not form a > combined piece of work. > (linux distributions) Again, you seem to miss that just because thing does not combine in normal ways it doesn't mean that they don't combine. > - but leaflet that replaces the last chapter of the book to provide a > different ending is a derived piece of work. The reason is that it is > specific to the original book, alters the story (the original work of > which the physical book is nothing but a printed > representation) told by > the book, and combines with it to form a new work (a new story with a > different ending). Thus you can only distribute it with permission of > the original author, even if you do not distribute the original book > with your leaflet. > (that's your patch example) Here it combines in a linear readable way. In short: Everything combines with everything else is some way, so unless you define some exact criteria on where the legal border talking about what can combine is rather pointless. The only trend, in your examples, I can see is that you wish to give work that combine in linear readble way more protection, for some, not mentioned, reason. Can you please explain why? > > No particular problem, > > except that some companies might be greedy and want more, > > but hey, do you really wish to give them more? > > I did not express any wishes and in any case they are irrelevant: I > do not have the power to give companies more or less. Now, when I'm > world-dictator for life... :-) :-) > > Open source is more problematic since the end user legally can > > get hold of the work for free and thus any distribution > > restrictions is meaningless since the end user doesn't distribute. > > From my point of view open-source is not any different from any > commercial work. Obviously there are legal means to obtain > the original > work in both cases (whether you have to pay for it is irrelevant). > Otherwise the point is moot. > > But saying that open-source is different would mean that > because you > are not making a direct profit from this work, you are not entitled to > any protection under copyright law. You can't mean that, can you? But you _have_ protection from copyright, everybody that _distribute_ your work must fullfill the license otherwise you can sue them.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 20, 2001

Dec. 20, 2001

> I see exactly what you mean. You mean a binary patch that says > things like: > * delete bytes 2294 to 2297 > * replace bytes 38455 to 39345 with "...." > * insert "...." at offset 41753 Yes. > Such a patch is very specific to a given source version > but does not > include any of the original source. Yes, but that is not a very problematic restriction. > Well, if you can legally use such a patch to work-around the LGPL > license, then you can use it to get past *any* license: GPL, AFPL, MS > shared-source, .... whatever. And this is not only true of > source files, > this is also true of binary files: you can apply such a patch to > executables, libraries, mp3s, mpegs, ... It means what you mean by get past, but OK for the sake of argument: Yes. > This has already been done and the author very quickly got into hot > water. IIRC it was less that two years ago, about a GPL game and an > individual who published a mod as a patch to the game binaries but > refused to publish his source. I'm not sure how it ended. You can > probably research it in your copious amounts of spare time, I think > there was an article on it on Slashdot at the time. I rememember. Of course it was impopular, I do not question that. The question is: Was it it illegal? > But I can assure you that no company in a 'developped' > country would > try such a thing. In the form above perhaps not so likely, but doing a proprietory Crypto API implementation with a patch to make Wine use it, much more likely. > If such a stunt were recognized as legal > then it would > spell the end of copyright of all electronic forms of songs, movies, > books, ... You can be sure that the RIAA, MPAA and all the other > entertainment companies in the world out would never allow such a > thing... and for once I say that they would be right. Please calm down. You forgot that the end user still need to legally get hold of the work somehow. For normal commercial stuff this involves paying for it and the author will get payed just like he did in the old non-digital world for _each_ copy. No particular problem, except that some companies might be greedy and want more, but hey, do you really wish to give them more? Open source is more problematic since the end user legally can get hold of the work for free and thus any distribution restrictions is meaningless since the end user doesn't distribute. But hey, do you really think this so important that you wish to give companies more power than they already have?

2 1

CryptoAPI (no, this has nothing to do with licensing! YAY!)
by David Elliott Dec. 20, 2001

Dec. 20, 2001

A while ago I started hacking out an implementation of CryptoAPI. It sat idle for a while and a few days ago I decided to start doing a bit more hacking again. The basics of ADVAPI32's CryptoAPI part is that it does nothing except provide an interface for applications to call into CSPs without actually loading the CSPs themselves. At the moment the TESTCSP.EXE with its accompanying CSP.DLL is starting to work. These are from Microsoft's CSPDK and include source code. I have not tried compiling the source with Winelib, that is a later project. At the moment this code keeps track of which CSPs are loaded and which CSP an HCRYPTPROV handle uses. This allows testcsp to load up csp.dll and do a few things, but not everything. What bothers me though is that it does not get Intenret Explorer to load up the RSA CSP. The LoadLibrary fails because the DllMain function in the CSP returns FALSE. I speculate this has something to do with the fact that a real CSP needs to have its image verified before it will load. Or maybe it is something different entirely. Anyway, still left to be done are to keep track of Key and Hash handles (trivially easy) and maybe some other stuff. As far as putting this into the tree goes, I don't think it would harm anything, although I noticed that the GenRandom function had a useless implementation in it. It now has what I believe to be the correct implementation, but if loading the CSP fails that CryptGenRadom isn't going to work. Did somebodies appication actually depend on this behavior or was it implemented just to have something there? In any case, this still needs to be cleaned up a bit, but I am hoping to get some input on why I cannot load a real CSP as this is all completely useless (well, not completely, but for my purposes) if a real CSP cannot be loaded. -Dave

3 4

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 20, 2001

Dec. 20, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So almost all functions would look like > > void CryptFoo() > > { > > #if HAVE_LIBCRYPTO32 > > CRYPT32_CryptFoo(); > > #else > > /* Old Wine code */ > > #endif > > } > > > > with a few minor exception. > > > > So you mean that I can't legally do that despite the fact that > > the LGPL is meant to allow linking to proprietary licenses. > > The LGPL allows using LGPLed code from proprietary applications. It > does not allow making the LGPLed code dependent on proprietary code > for its own functionality. > > > I think you have misunderstood something seriously. > > Please, this is the absolute worst argument from you > > as of yet. You can't seriously believe this. > > > > Also note that the code that I wrote above was supplied > under the LGPL, > > so I don't see how you can claim that I violated the LGPL. > > Of course you cannot violate the license of your own code, don't be > silly. Exactly. > But if you put this code in an LGPL library written by someone > else and distribute the end result, you have to make a good faith Yes and DISTRIBUTE the end result is the key. But why should I do that? I can for example write a script that download Wine for the end user user and apply the patch automatically. > effort to ensure that the library works properly even in the absence > of your proprietary library. This means you need to implement the > #else case and release that under the LGPL. Go read the square root > example in section 2 of the LGPL. Perhaps, but I need not distribute so it doesn't matter. The point that I have been tried to make all along that only the doctrine of can make my trickery illegal. Without it, it doesn't matter that I use Wine in a, hmm, let call it a non standard way. Anyway I think this discussion, at least the one between you and me, are running around in circles and doesn't move forward at all, so lets just end it. > > Could it be that they rely on that that the dotrine of derived work > > will save them from people trying to use the lopeholes in > the licenses? > > Sure, maybe you understand the law better than all the lawyers who > looked into this issue. I'm not betting on it. It is not primarily understanding that is the issue here. I have said that I believe, and have tried to explain why, that a strong doctrine of derived work is not good for society, because it leads to all sort of absurd consequences. Therefore is believe (or rather hope) that the courts will se sanity and only constitionally allow a very weak doctrine of derived work and thus render viral licenses such as LGPL of most (all?) of its power since it will be quite easy avoid the requirements with a little trickery. Note that this will almost exclusivly effect viral open source license since normal commersial work will get their $100 or whatever regardless since there is no trickery that can legally avoid it.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 20, 2001

Dec. 20, 2001

> But, I hear you say, 'why change the license if it doesn't > give you any > protection?' Well, this is where your reasoning is flawed, because the > LGPL gives you quite a bit of protection. And this is because > there is at > least a 50% chance that it is enforceable, and this is > _good_enough_ in > practice. This is trivial to see: the market place is littered with > unenforceable EULAs, yet they seem to do the job. Why? Because big > companies will have not desire whatsoever to test these > licenses in court, > since they have to much too loose (remember, big companies = > have $$$), > while small companies can build on a business plan based on such shaky > grounds, as no one is going to fund such ventures. Add to > this the immense > public pressure, and you have Protection, with a capital P. Sure it is true that what people (read: companies) believe is true is more important than what really is true. The problem is that the example of things you could do that I consider trickery might be considered perfectly normal for some companies, in fact something are not really something strange at all if you applied to the normal world. I adjust the thing I bought a little and then resell it. Then their lawyers tell them that it is unclear if they can do it. Many might not not bother at all and thoose are lost to Wine, some might risk it a later find themselves it a situation that they can neither move forward nor backwards because of "public presure", and because of the amount of money invested they have little choice but to say the LGPL is absurd, we don't not believe we ingfringe on somebodies rights and move forward hoping that somebody doesn't sue them. > And just for shits and giggles, if you think _any_ license > will give you > absolute protection, you are sadly mistaken. And the reason > this can not > happen is rather simple: the laws change. I have said it before and I say it again: I have no illusions that something gives absolute protection.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 20, 2001

Dec. 20, 2001

> David Elliott <dfe(a)tgwbd.org> writes: > > > Okay, that makes a bit more sense. Although couldn't one argue that > > it still does work since it could fall back to the original LGPL > > createwindow? > > Sure, if this is the case it's OK. You can perfectly provide a > user32_better library that implements a new CreateWindow, and links to > user32 for the rest. But the modified user32 you ship must work > properly, it cannot be dependent on your proprietary user32_better for So as an alternative trickery: I distrubute everything just like the example above it just happends that user32 is a symbolic link to user32_orginal. This would be alright wouldn't it? So now I just can distribute a script that move the symbolic link user32 from user32_original to user32_better. Problem solved in a way even more convienient for my end user.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 20, 2001

Dec. 20, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So what you basicly saying is that a Crypto API that is a > part of ADVAPI32 > > can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can. > > > > Isn't that quite an absurd state to make? Or rather the > perfect illustration > > of the absurdities of LGPL. > > No, I think it makes perfect sense. If your code is sufficiently > independent that it can be put in a separate library, then the LGPL > gives you the right to release it under another license. But in order > to do that, you have to demonstrate that the code is really as > independent as you claim it to be; and requiring you to put it in a > separate library is the best way to ensure that. Somehow I guess you would say that. OK, so now are down to independence. So independence is an issue of whether something is on either side of an artifical barrier in this cases the DLL boundary? Note that you your condition: "If your code is sufficiently independent that it can be put in a separate library" can always be fullfilled with a little trickery. For example: void CryptFoo() { CRYPT32_CryptFoo(); } and release the code above under the LGPL. Note that we now return to the doctrine of derived work for nothing except for it can ever make this illegal. > You known, no matter how much you may disagree with the FSF or their > license, they are not a bunch of idiots. They have been through this > long before you, and have spent a lot of time (and lawyers) to make > sure that it worked as they wanted. You can certainly find minor > issues and border cases, but the LGPL is not the useless crap you seem > to think it is. They had a goal and I'm sure a lot of competent people did the best they could be accieve it. However, you can do the impossible no matter how hard you try.

4 3

TrueColor <16bpp modes
by François Gouget Dec. 20, 2001

Dec. 20, 2001

There is a problem with <16bpp TrueColor modes: some windows applications will just check BITSPERPIXEL and if it's < 16 they will assume that we are running with a 2/16/256 color palette. What are the affected modes: * 15bpp: rgb555 and bgr555 * 8bpp: VNC's bgr233 mode! This patch is an ugly hack but it seems to work relatively well. The trick is to lie to the application about the screen depth. If we have a TrueColor mode but a <16bpp screen depth then we return 16bpp anyway. But then the application is going to create 16bpp bitmaps, and CreateBitmap will try to create a 16bpp pixmap... and this is likely to fail. So in CreateBitmap we reestablish the truth and put the right depth in bitmap.bmBitsPixel. Actually some X servers, especially the 4 series seem to support many pixmap bit depth so this may not always be necessary. Anyway, we then rely on the code in dib.c to do the conversions from one format to the other. The last bit in bitblt.c may not be necessary. It seemed useful once but I'm not convinced anymore. Well, if anyone's interested in hacking more on this, have fun (and let me know if you find interesting stuff or have questions :-). -- François Gouget fgouget(a)codeweavers.com Index: graphics/x11drv/bitmap.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/bitmap.c,v retrieving revision 1.34 diff -u -r1.34 bitmap.c --- graphics/x11drv/bitmap.c 2001/09/07 15:28:10 1.34 +++ graphics/x11drv/bitmap.c 2001/12/20 00:31:19 @@ -156,6 +156,14 @@ GDI_ReleaseObj( hbitmap ); return 0; } + /* In case we lied to the application wrt. the screen depth, then it's + * time to patch things up before X complains it does not support this + * color depth. Of course it means we'll have to convert depths from + * DIB to Bmp. + */ + if (bmp->bitmap.bmBitsPixel==16 && screen_depth<16 && (X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL)) + bmp->bitmap.bmBitsPixel=screen_depth; + if ((bmp->bitmap.bmBitsPixel != 1) && (bmp->bitmap.bmBitsPixel != screen_depth)) { ERR("Trying to make bitmap with planes=%d, bpp=%d\n", Index: graphics/x11drv/init.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/init.c,v retrieving revision 1.41 diff -u -r1.41 init.c --- graphics/x11drv/init.c 2001/07/29 20:25:15 1.41 +++ graphics/x11drv/init.c 2001/12/20 00:31:22 @@ -190,7 +190,11 @@ case VERTRES: return screen_height; case BITSPIXEL: - return screen_depth; + /* Some applications assume that if the bpp<16 then we are using a + * palette. This is wrong, we could be in 15bpp, or even bgr233 in VNC. + * So we just lie to them. + */ + return (screen_depth<16 && X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) ? 16 : screen_depth; case PLANES: return 1; case NUMBRUSHES: @@ -202,10 +206,11 @@ case NUMFONTS: return 0; case NUMCOLORS: - /* MSDN: Number of entries in the device's color table, if the device has - * a color depth of no more than 8 bits per pixel.For devices with greater - * color depths, -1 is returned. */ - return (screen_depth > 8) ? -1 : (1 << screen_depth); + /* MSDN: Number of entries in the device's color table, if the + * device has a color depth of no more than 8 bits per pixel. For + * devices with greater color depths, -1 is returned. + */ + return (X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) ? -1 : (1 << screen_depth); case PDEVICESIZE: return sizeof(X11DRV_PDEVICE); case CURVECAPS: Index: graphics/x11drv/bitblt.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/bitblt.c,v retrieving revision 1.37 diff -u -r1.37 bitblt.c --- graphics/x11drv/bitblt.c 2001/10/03 18:45:41 1.37 +++ graphics/x11drv/bitblt.c 2001/12/20 00:31:19 @@ -626,7 +626,7 @@ pdata += swap ? start+width-1 : start; if (image->depth == depthDst) /* color -> color */ { - if (X11DRV_PALETTE_XPixelToPalette && (depthDst != 1)) + if (!(X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) && X11DRV_PALETTE_XPixelToPalette && (depthDst != 1)) if (swap) for (i = 0; i < width; i++) *pdata-- = X11DRV_PALETTE_XPixelToPalette[XGetPixel( image, i, row )]; else for (i = 0; i < width; i++)

1 0

timed-out non-overlapped ReadFile
by lawson_whitney＠juno.com Dec. 20, 2001

Dec. 20, 2001

Mike, None of your recent comms pathces has made the slightest difference to my app, but this little one breaks it. It dials, the modem connects, but the app never sees RLSD AKA CD AKA TIOCM_CAR. I reversed overlapped_good.diff II, because AFAIK that is not in the CVS yet, but it didn't matter. I don't think I have any other stray comms patches, but ICBW. +comm,+file trace attached. Lawson ---oof---

1 0

Re: Add color cursor support
by Alexandre Julliard Dec. 20, 2001

Dec. 20, 2001

Duane Clark <dclark(a)leewardfpga.com> writes: > The main ugly hack that is performed here is in determining whether a > pixel is a foreground or background pixel. This is done by adding the > red, green and blue values for each pixel, and testing whether they > exceed an arbitrary threshold. This should probably be a reasonably > safe method, since presumably any cursor will have a high level of > contrast between foreground and background colors. It's reasonable, but you should be doing this locally in the X image before transferring it to the server; painting the pixmap in the server pixel by pixel is going to be quite slow. And you may want to have a look at CURSORICON_IconToCursor, it does something similar. -- Alexandre Julliard julliard(a)winehq.com

4 3

Re: overlapped ReadFile should ignore EAGAIN
by Mike McCormack Dec. 20, 2001

Dec. 20, 2001

Hi Alexandre, Apologies, i thought explicitly about the error handling issue, and should have made a note about why i did it that way. Since the async handler code will handle problematic fds correctly, rather than duplicating all the checks, i thought it would be easier to fall thru to the existing checks in check_async_list and FILE_ReadAsyncService. Do you think it would be better to pick up any problems early? Did you look at my async queues patch? Are you waiting for Martin to respond? The async handling code is a bit of a hacked up mess the moment... i haven't applied the fixes to WriteFile that i've applied to ReadFile, and overlapped WaitCommEvent needs to return immediately if events are already available. I don't want to fix those problems twice, so i'm waiting for the big async patch... Mike Original message from: Alexandre Julliard <julliard(a)winehq.com> > >Mike McCormack <mike_mccormack(a)start.com.au> writes: > >> This is a fix for the problem below. Since all COM port fds are >> non-blocking, if we get an error (EAGAIN) return from the initial >> read, we should just ignore it and let the wineserver poll on it. > >Shouldn't you check for EAGAIN then? It doesn't seem safe to ignore >all errors. > >-- >Alexandre Julliard >julliard(a)winehq.com ------------------------------------------ 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: overlapped ReadFile should ignore EAGAIN
by Alexandre Julliard Dec. 20, 2001

Dec. 20, 2001

Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a fix for the problem below. Since all COM port fds are > non-blocking, if we get an error (EAGAIN) return from the initial > read, we should just ignore it and let the wineserver poll on it. Shouldn't you check for EAGAIN then? It doesn't seem safe to ignore all errors. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 20, 2001

Dec. 20, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > There will be very little reason for companies to enter the market > > at that time and why try to make it difficult for the few > that might. > > On the contrary, there will be a lot more reasons. The main market is > not in developing Wine; frankly there isn't that much money to be made > on that. The main market is in using Wine to make money on > applications, and the more complete Wine gets the easier this will be. If the applications is are already proprietary I they can affort to pay to get the whole way to 100% functionallity. If they are open source they have an incentitive to work making Wine complete. I don't really see the problem. > But if Wine never gets complete because some parts are held > proprietary by other companies, it won't be possible to enter that > market. So you mean that all the people that are current voluntering to work of Wine won't work on Wine if it is almost complete just because somebody else have done the parts they need to run their applications and that they will happily pay for the right to use it. In that case it would be disasterous to make Wine run all Microsoft implemented non-core Wine DLL:s because then everybody would just be happy to use the Microsoft DLL:s and nothing beyond non-core would ever be implemented. You can't seriously believe this?

10 19

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 20, 2001

Dec. 20, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > For example: > > void CryptFoo() > > { > > CRYPT32_CryptFoo(); > > } > > > > and release the code above under the LGPL. > > That's the square root example. If you do that, you have to make sure > that the use of CRYPT32_CryptFoo is optional and that the function > still behaves properly if your CRYPT32 function is not available. Forget for a moment I was trying to circumvent the LGPL. Lets say I just found a crypto library called CRYPTO32 under a proprietory license that I wished to use. It so happends that they had almost 100% the same functions as the Crypto API. So almost all functions would look like void CryptFoo() { #if HAVE_LIBCRYPTO32 CRYPT32_CryptFoo(); #else /* Old Wine code */ #endif } with a few minor exception. So you mean that I can't legally do that despite the fact that the LGPL is meant to allow linking to proprietary licenses. I think you have misunderstood something seriously. Please, this is the absolute worst argument from you as of yet. You can't seriously believe this. Also note that the code that I wrote above was supplied under the LGPL, so I don't see how you can claim that I violated the LGPL. The company that wrote the proprietory library neither knew about the me nor about Wine so how can they have violated the LGPL. > > They had a goal and I'm sure a lot of competent people did the best > > they could be accieve it. > > > > However, you can do the impossible no matter how hard you try. > > Strangely there are thousands of people, including lawyers, who seem > to think that the LGPL does what it claims to do. If the problems are > so obvious, how come no one else sees them? Could it be that maybe, > just maybe, it is because all these people are right and you are > wrong? Could it be that they rely on that that the dotrine of derived work will save them from people trying to use the lopeholes in the licenses?

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> Now, here's another something to mull over. We've pretty > much established > that you could statically link something proprietary with > something LGPL. > One question I have is how much of the library are you > allowed to use. > Alexandre mentioned that while the CryptoAPI example would be > a pretty > clean-cut allowed case, a proprietary CreateWindow would not > be allowed. > His argument was that because it would necessarily use > internal functions > and data structures that it would be a derived work and thus > subject to > the license. > > I think what Patrick has been trying to get at is that that > is not very > clean-cut and that in fact there is little to no precedent on > what exactly > a derived work is. If Alexandre is indeed correct then we > are pretty well > protected. If it is at the opposite extreme and anyone could > statically > link in proprietary versions of functions then we have very little > protection and it really makes it not worth it to go LGPL. At > least that > is what I think Patrick has been trying to say. Yes, approximately. > Let me put it to you the way I see it. Whether a function or data > structure is exported or not does not matter. It would be trivial to > declare an internal structure or function as exported and thus the > proprietary function is simply making use of the library and > therefore not > a derived work. Indeed... > That is my argument that avoids all of > Patrick's doctrine > of derived work crap and gets right down to the fact that > it's trivially > easy to make your work fall under the work that uses the > library category, > so long as it is a seperate object file. That is, to put it > in Slashdot > terms, a "Big Gaping Hole(tm)" ..but you are wrong that just because it falls under use, it is clear from the doctrine of derived work. That is the main problem, I have with it. That it might potentially turn somekind of uses into derivation and thus potential infringement of copyright. > Look at section 5 in the LGPL. If you use (from the header > files) only > numerical parameters, data structure layouts and accessors, and small > macro and inline functions then regardless of whether it would be > considered a derived work it remains a work that uses the library. > > So that's great, after I had pretty much convinced myself > that the LGPL > was still good despite some minor problems, I now find myself > realizing > that the LGPL has major holes written into it! Welcome to the club. :-) > And so I emphasize my original statement now. The only thing > the LGPL > really prevents is the direct use of the source code. Anyone > wanting to > release a proprietary implementation of any function can do so fairly > easily simply by 1) writing that particular function from > scratch, and 2) > keeping it in a seperate object file. Agreed. > > > Try reading section 2C of the LGPL and tell me how it's good for > > commercial > > > companies. > > > To respond to Roger: I fail to see how 2c makes any > difference. It only > applies to derived works and only means that you have to release the > code. Yes, it only applies to derived works, but since it is pretty unclear what a derived work is makes it quite unclear for commercial commpanies what that are legal forced to release or not that can't possibly be good when they are deciding whether to use Wine.

2 1

[SHrinker] gdb still doing funny things
by Robert Baruch Dec. 19, 2001

Dec. 19, 2001

I got around the problem of gdb unprotecting the write protected page by not setting the breakpoint until after the write fault occurs. When I stepped through the Shrinker exception handler, I got to the point where it calls ReadProcessMemory with a handle of -1 to get the 8 bytes around the EXC_CallHandler's call. ReadProcessMemory fails with an ACCESS_DENIED, and trips a landmine. 0806d9e8:Call kernel32.ReadProcessMemory(ffffffff,4006cd38,404f489c,00000008,404f48a4) ret=0075f1c3 0806d9e8: read_process_memory( handle=-1, addr=0x4006cd38 ) 0806d9e8: read_process_memory() = ACCESS_DENIED { data={} } 0806d9e8:Ret kernel32.ReadProcessMemory() retval=00000000 ret=0075f1c3 However, when I run wine alone, without gdb, that particular landmine is not tripped: 0806d9e8:Call kernel32.ReadProcessMemory(ffffffff,4006cd38,404f489c,00000008,404f48a4) ret=0075f1c3 0806d9e8: read_process_memory( handle=-1, addr=0x4006cd38 ) 0806d9e8: *attached* 0806d9e8: *signal* signal=19 0806d9e8: read_process_memory() = 0 { data={ff,75,08,ff,d1,64,8b,25} } 0806d9e8:Ret kernel32.ReadProcessMemory() retval=00000001 ret=0075f1c3 BTW, the data returned by ReadProcessMemory is correct, and also will not trip the "Have I been called from Microsoft's NTDLL.DLL method" landmine. I'll have to think about this for a while, how to use gdb without getting ACCESS_DENIED for ReadProcessMemory. That usually means going off and doing something else until an idea hits me. --Rob

2 2

[Shrinker] Modified EXC_CallHandler
by Robert Baruch Dec. 19, 2001

Dec. 19, 2001

Well, the assembly-coded EXC_CallHandler works (to my surprise), with a little modification from what I described because after all, no plan survives contact with the enemy. However, we're still getting hit by one of the landmines in Shrinker. The awful thing is that I can't debug this easily with gdb. The first exception that's supposed to take place is a write fault to the code area. But if I set a breakpoint in the process's code area, gdb is going to remove the write protection from the code area because, I guess, it needs to put a breakpoint in there (I thought it would use breakpoint registers instead of int $3?) Anyway, I don't want to release the EXC_CallHandler code until I find out which landmine we're hitting, since I can't be certain the rest of EXC_CallHandler works -- the stuff past calling the exception handler. But if you're interested in a morbid "I-love-assembler" way, here it is: static DWORD EXC_CallHandler( EXCEPTION_RECORD *record, EXCEPTION_FRAME *frame, CONTEXT *context, EXCEPTION_FRAME **dispatcher, PEXCEPTION_HANDLER handler, PEXCEPTION_HANDLER nested_handler) { DWORD tmp = 0; __asm__ __volatile__( "push %1\n\t" // ebp-1c = nested_handler "push %2\n\t" // ebp-18 = handler "push %3\n\t" // ebp-14 = dispatcher "push %4\n\t" // ebp-10 = context "push %5\n\t" // ebp-c = frame "push %6\n\t" // ebp-8 = record "push %%ebp\n\t" // ebp-4 "push %%ecx\n\t" // ebp-0 "movl %%esp,%%ebp\n\t" "movl 0x18(%%ebp),%%ecx\n\t" "pushl 0x1c(%%ebp)\n\t" "pushl %%fs:0\n\t" "movl %%esp,%%fs:0\n\t" "pushl 0x14(%%ebp)\n\t" "pushl 0x10(%%ebp)\n\t" "pushl 0x0c(%%ebp)\n\t" "pushl 0x08(%%ebp)\n\t" "call *%%ecx\n\t" "movl %%fs:0,%%esp\n\t" "popl %%fs:0\n\t" "movl %%ebp,%%esp\n\t" "popl %%ecx\n\t" "popl %%ebp\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "movl %%eax,%0\n\t" : "=&g" (tmp) : "g" (nested_handler), "g" (handler), "g" (dispatcher), "g" (context), "g" (frame), "g" (record) : "memory" ); return tmp; } --Rob

2 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> David Elliott <dfe(a)tgwbd.org> writes: > > > Now, here's another something to mull over. We've pretty much > > established that you could statically link something > proprietary with > > something LGPL. One question I have is how much of the library are > > you allowed to use. Alexandre mentioned that while the CryptoAPI > > example would be a pretty clean-cut allowed case, a proprietary > > CreateWindow would not be allowed. His argument was that because it > > would necessarily use internal functions and data structures that it > > would be a derived work and thus subject to the license. > > Actually the fact that they are internal or not doesn't make a > difference, I wasn't clear on that point. Agreed. It doesn't matter. > If your code is linked to > the library it is considered a derivative work, and by default the > whole has to be released under the LGPL. Now there are cases where you > don't need to do that: one is if your app is considered a work that > uses the library (section 6), the other is if you are placing your > code side-by-side with the library (section 7). > > So if you don't want your code to fall under the LGPL, you have two > choices: one is to put it in some part of your app that only links to > the library, but in that case you cannot have other parts of the > library depend on your code (this is the square root example). This > would work for the crypto API, probably not for CreateWindow since the > rest of user32 needs CreateWindow. Well, only if it made CreateWindow work different that it was supposed to. Note that supposed to it pretty vague, however, if you leave it out you can't even apply bug fixes since it would change the behavior. > The other solution is to put your code side-by-side in the library; > but this is only possible if your code is not covered by the license, > which means it isn't a derivative work of the library, which in turns > means it cannot use any functions or data (exported or not) of the > library. This would work for the crypto API as long as you don't use > anything from the rest of libadvapi32. So what you basicly saying is that a Crypto API that is a part of ADVAPI32 can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can. Isn't that quite an absurd state to make? Or rather the perfect illustration of the absurdities of LGPL. Of course, I assume that you by use a function mean call a function not cut and paste from a function.

3 2

RE: Installshield 6 (inter-proc) patches. LGPL hole.
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

[David Elliott explaination snipped] > Thanks for explaining what Patrik has been going on about. Yes, it was quite a good explaination. However... > In summary: > > Consider a proprietary application which ships as a > proprietary library > which is statically linked with LGPL libraries at install > time in a way > that lets users supply new versions of the LGPL libraries. > This lets them > fix bugs in the LGPL'd code and thus in the proprietary app. > The harm you see is that a vendor could, once he found a > Winelib function > with a bug, simply do his own clean-room implementation of > that function, > and use it instead of the Winelib version of it, and keep the > improvement > to himself -- which would also deprive the user of the ability to fix > bugs in the proprietary reimplementation of that particular > WineLib function. ... while this is an entirely possible scenario there is little profit in doing what you suggest so while it is one of the holes in LGPL it is not really a problem in pratice I think. No, the problem as far as Wine is concerned, is that somebody might do proprietary extension of some important part of Winelib that enough people want so much that most people uses the proprietary extension and under such circumstances there won't be any incentive for people to work on Wine. However, I neither believe this to be true, nor do I believe that the LGPL will help to stop it other than very marginally.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> >> MS Word (to use an example) might have to dynamically link in > >> a special MS Word component to process specifics in my > >> document, it doesn't mean my document is "linked" with the > >> MS Word component does it? > > > > Ah, you are beginning to see the problem. :-) > > What problem? A GPL program is the same as any other - GPL > protects the > code, not the use of said code. Indeed. It is a not a use license. However because of the doctrine of derived work that GPL depends upon, some use (read: linking) are considered derivation and thus a possible violation of the GPL. > There's nothing to stop a > GPLed program > such as, say an amiga emulator (UAE) running the emulated non-free > software. As geoffs example rightly points out. You think (read: hope) that it is not so because it would be quite absurd wouldn't it? However if the doctrine of derived work is strong enough to prevent want the GPL hopes it will prevent namely linking, I see no reason to assume that emulation would be considered differently. After all from a technical point of view essentially that same things that happends. > And in any case, we are talking about the LGPL - a totally different > matter. Not entirely whatever power the LGPL have also derives from the doctrine of derived works eventhough is doesn't try to use it to the extent that the GPL does. > Which is my response to Rogers comment above - sure the GPL > prohibits linking with a nonfree component. Yes, but what is linking? Don't you understand it is the vagueness of linking that is the problem. This is further made worse by that fact that the doctrine of derived might possible, and are very like to do, at least to some extent, place some kind of limit on what linking legal extends to. > That 'closes' the > source and > provides far too many ways to cheat the license. > > The LGPL allows dynamic linking with a nonfree component. > Remebering that > the LGPL is meant to apply to LIBRARIES (hence allowing a > libssh library > to use nonfree crypto routines for example) not for an application. You can cheat with both the GPL and the LGPL at I have tried to illustrate in earlier mails, but the LGPL at least as applied to Wine is a gaping hole, that hardly provides any protection at all.

3 5

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > The problem is the doctrine of derived works. Nothing else. > > And to you truly believe that our choice for Wine's license > will have any > influence over the doctrine of derived works? Of course not. But it _will_ effect our abillity to attract companies. Eventually I think the courts, possibly with the help of the politicians will realize that only a very weak doctrine of derived work could every service society without introduces needless uncertainties and/or absurdities. For example I think that some cases where the doctrine of derived work has been used like IIRC in some case considering unauthorised Star Trek books. Using the Star Trek characters in a book without Paramounts(?) permission, would be much better served using trademark law instead. This might or might not require changing trademark law but that is a different issue. Don't expect it to happend soon though. > If not, there > really is no > point in discussing this any further. If yes, than even more > so should we > chose the LGPL, as it will help settle the debate the right way. See reply in previous mail.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > I'm against the fact that the GPL or to a smaller extent LGPL > > tries use the doctrine of derived work as a weapon to achieve > > their goals. It is a very dangerous weapon, since if the courts > > or the policitians decide that a strong doctrine of derived work > > is good it might be disasterous for society as a whole. > > This is a very good point which in fact _promotes_ the LGPL. Not really. See below. > Let me > explain. > > There are two possibilities for copyright law: > > 1. The copyright law becomes stronger. > 2. The copyright law becomes weaker. It is much more complicated than that, but fair enough, lets assume this for the sake of argument. > I will assume, for the purpose of this discussion, that: > > A. Wine contributors wish for 2. I, for one, am very worried about the > direction of law these days (see: software patents, DCMA, > SSSCA, etc.) and > I fully agree with Gerard that it's an unfortunate situation > B. There doesn't seem to be any negative feedback loop that > will prevent 2 > from happening. That is, it is very probable that 2 _will_ > happen sooner > rather than later. I agree. > Now, let's just go through the possibilities: > > Let's look at copyright law. If our dreams come true and 2. > will become > reality, then Wine will be in no worse situation than it is > now in. The > LGPL will effectively become BSD, i./ii. become irrelevant, > and we're all > happy. This scenario is possible, but (unfortunately) not probable. Yes, but in the mean time it is likely that we scare away potential good companies and regardless of the LGPL be effected negativly by bad companies using the lopeholes in the LGPL. > On the other hand, if society moves towards 1., then the LGPL is the > perfect tool because it turns the stronger copyright law > against itself. > In this case, it is the only moral/ethical thing to do: to > turn an evil > instrument against itself, thus provides the > _negative_feedback_loop_ that > is missing at the moment. > > Moreover, if you are worried about the fact that open source > software is > so influential that it can influence the debate over the doctrine of > derived work, then even more so should we opt for the LGPL > because in that > case we would contribute to a negative feedback that will deter > politicians from making the copyright law arbitrarily stronger. So you want Wine to be the catastrofic failure, that was used to change copyright law. You can't seriously want this.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > > Note that I said "_small_ improvements" because of the > > > modular nature of Wine. If the improvements are big, the DLL > > > separation would allow them to keep those changes proprietary. > > > > I don't think small improvements is a problem anyway and > > beginning an implementation of say DCOM is probaly not a > > small improvement and DirectX certainly isn't. > > But if it's not, it's within a small constant factor to > replace the rest > with prorietary code and not release anything. See, if the > DLL is mostly > implemented, the changes are not that big, so they should be > contributed > back. If the DLL is mostly stubs, just rewrite the entire > thing, you're > not wasting that much effort in the first place, and you can choose > whatever licence you want. DirectX and DCOM fall in this cathegory. I have use the Crypto API as an example several times that to illustrate that the DLL:s isn't a relevant protection boundary for the LGPL, even Alexandre seems to accept this. In any case if the DLL is mostly implemented there is very little reason for a company to try to enter the market, it is simply to dangerous, so I don't see the problem. > > > I fail to see _any_ moral/ethical/philosophical problem with > > > this. Do you? > > > > Perhaps you have been more enlightend now. > > Focusing on obscure issues only is anything but enlightening. :) Well, the concrete issues like do we scare potential companies that wants to help way quite hard to argue about in a objective way and I do not really like subjective arguments. I leave them to for example Gavriels that IMHO has done a good good job at that. I have been trying to approach the problem from the other side, that the LGPL doesn't provide much protection at all.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > You forget that some "independent"(*) parts like the Crypto API are > > parts of other DLL:s (like ADVAPI32.DLL) for no particular reason. > > This is ridiculous: it is one of the few exceptions, it is > simply silly to > bring the Crypto API into this discussion. If this the Crypto > API is the > only problem, we can fix it in multiple ways. It is not the only problem it is just a symptom of the gaping hole in LGPL. > > > At this point, I would like to know if people agree up to > > > this point. > > > > I don't. > > That's informative. WHAT don't you agree with? In fact, if we > can agree on > WHAT we disagree, I think it would be a great step forward. "I don't" primarily refered to the previous argument concerning "independent"(*) parts. > > > 0. Isn't Wine's best interest to evolve and develop as fast > > > as it can? > > > > Yes. > > This is a fundamental point. A project like Wine is just like > a living, > breathing creature. And being need to be selfish to survive. Not too > selfish, but it is essential that they have a certain level of > selfishness. Your analogy is flawed, Wine is not living in the meaning that it, if it is to unselfish can die. The mechinisms are entirely different compared to normal life. > In Wine's case, that has to be: 'the licence > should be such > that it would maximize Wine's development'. Yes, but I don't believe that LGPL does, that I have being trying to explain in I forgot how many mails. > > > 1. If so, isn't the LGPL _spirit_ in Wine's best interest? > > > > No, not nessararily. See different mail. > > 1 follows from 0. Period. You can not agree with 0 and > disagree with 1, no > matter what you write in other emails! :) Again, THE SPIRIT > of LGPL, not > the letter. Again, the spirit is: 'if you improve Wine in minor ways, > please contribute back your improvements'. Yes, and the key is minor ways and I believe that is a absolute non-issue as I have explained before. There is no profit in holding minor improvements. > > > 2. If so, why shouldn't we formalize it in the license? > > > > But it isn't nessarily so. > > And why is that? Quite the contrary, because: > > -- For people that contribute back, would chnage nothing > -- For people that don't contribute their changes, it's no > good to us, so > we don't care (which follows by point 0). > > Tertium non datur. That is, there's no other case. QED. OK, since you bring mathematics in to it, I will try to explain in mathematical terms: "The set of people is not invariant over a license change." In fact the set of people are likely to be considerly less. While I have no strict mathematical proof of that, I especially point to Gavriels' reply concerning Corel and Transgaming.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> On 2001.12.18 05:09 Patrik Stridvall wrote: > [snip] > > Dimitrie O. Paun wrote: > > > Stop for a movement and tell me: are you against the letter > > > or the spirit > > > of the LGPL. > > > > Asking that question is like asking whether I support the spirit of > > Communism: > > "From each according to his abilities - to each according > to his needs." > > > > Well, it sound nice doesn't it? However doing a little > deeper analysis > > I realize that the price for being able to do this is not > worth paying. > > > > Note however that I'm not equating GPL or LGPL with Communism. > > It was just an example from real life, that you get more that > > you wish for. See below. > > > [snip] > > That's a piss poor example. The statement that something > would be from > each according to his abilities and to each according to his > needs sounds > to me at first glance like it would suck. And you don't have > to dig too > deeply to figure out why that would suck. But maybe that's > because I am > an American capitalist though and through and that blatantly > conflicts > with my core values that everyone should do for themselves. Perhaps. However, I think that if you move to Europe, especially northern Europe you will find that people have different opinions. While most people there certainly do not believe in Communism and to various degrees understand why is doesn't work, people are more inclined to be believe in this principle. Actually I think the reason for this is more Protestant Christianity than Communism, but why is not really that important. > And to get > off topic, why is that? Because that's what everybody will > do anyway, > might as well work with that rather than pretend that it is otherwise. So there is no such thing as morality? > This has lead me to another thought. We cannot pretend that > people are > going to release code back to Wine under the X11 license. > However we can > realize the obviousness of the truth that given the chance > people will > take whatever they can and give back nothing in return. Some > folks will > give back because it may make more sense to do so than to > not. But some > folks will be more than happy to take the whole codebase for > their own > good and provide nothing in return. > > We need to stop living in the dream world that everyone who > uses Wine will > contribute back. I have no illusions that everybody will. However there is no need to scare away potentially good companies by using a hard to understand license. > Yes, it is true that Corel, Codeweavers, > TransGaming, > etc. have given a lot to Wine. None of them was or is > required to give > anything. And yet they did. That is kind of shocking for an American Capitalist, isn't it? :-) > If the goal is to let people know that if they want to use > Wine then they > need to contribute back, then the only choice is to put that into the > license. By "use" I am obviously not referring to simply porting an > application using Winelib. I am referring to incorporating > source code > from wine into their own products. > > This is exactly what the LGPL was meant to address. And if they borrow some obscure functions, they might even supply some bugfixes in hope that at a later stage there will be more bugfixes waiting for them when they borrow again (resync) a year later. And if they don't, who has been hurt? If Wine was LGPL:ed they certainly wouldn't have borrowed at all, so no chance at all of getting any bugfixes back at all. > I recall Uwe's usual .sig which is: > Free Software: if you contribute nothing, expect nothing. Indeed and what is your hypotetical sig? "LGPL:ed Software: if you contributed something, use the law as a tool to force others to contribute as well." > Maybe we should have one for wine: > Wine: If you contribute nothing, well, there isn't shit we > can do about it > since we are X11 licensed. I don't think that one came out the way you hoped. Try again.

1 0

Installshield 6 (inter-proc) patches
by J.Brown (Ender/Amigo) Dec. 19, 2001

Dec. 19, 2001

Any idea when Oves interprocess patches will be put into the main Wine CVS tree? The code currently in WineX isn't really that ugly at all, and it is a very important part of Wine to have working IS6 support. Regards, | Any significantly advanced technology is indistinguishable from | a perl script. Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org]

5 9

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> On Mon, 17 Dec 2001, Patrik Stridvall wrote: > > > > This has been my argument against Patrick exactly. Some > > > protection is better than none at all. > > > > As a general rule, yes. > > > > However this time the protection comes with a price. > > And what might that price be? You fear that we are going to > alienate the > commercial ventures developed around Wine? Yes. > > The problem is not whether LGPL is well written or not the > > problem it is the doctrine of derived work. That is very > > unclear because of lack of good case law. > > Oh, come on, for crying out loud! The LGPL is the best thing > we have -- we > can't wait for a good case law to adopt a license. Yes, there may be > problems, but that's life. We take our best shot -- this is what we're > doing with Wine in the first place! The main problem is that using the LGPL introduces uncertainty to what is allowed and that advantages is not good enough IMHO to outweight the disadvantages. > Patrik, your entire arguments are based on such obscure > assumptions that's > scary! I must tell you, both the GPL and LGPL have received careful > scrutiny from FSF's legal council (and a bunch of other law > professors, > I'm sure). The problem is the doctrine of derived works. Nothing else. Even if their understand of other parts of law are perfect it matters not. IIRC their arguments always seen to assume that the doctrine of derived works is unproblematic if applied to source code. > It's the best we can hope for now. You come along > with a bunch > of 'it is possible' type of scenarios (doh, everything is > possible!), and > say that 'well, everything's in vain, we're doomed, there's > no point in > doing anything, actually...'. In all honesty, it just looks > stinks. Badly. To connect again to the example of the spirit of Communism: I am sure it was very popular to dismiss to fear of the opponents by saying what you have been saying. Trivialising the problems and clinging to clean, pure and uncomplicated spirit of it.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> Patrik, > > The more I read your posts, the less I understand what you > are trying to > say. You argued over many hundreds of lines over weird > technical details > and various dubious assumptions about what courts will do in > the future. The main point is that what is legal allow is very unclear. I'm not primarily trying to explain what is legal allowed or not, just pointing out some difficulities in understand what the law really means. > Stop for a movement and tell me: are you against the letter > or the spirit > of the LGPL. Asking that question is like asking whether I support the spirit of Communism: "From each according to his abilities - to each according to his needs." Well, it sound nice doesn't it? However doing a little deeper analysis I realize that the price for being able to do this is not worth paying. Note however that I'm not equating GPL or LGPL with Communism. It was just an example from real life, that you get more that you wish for. See below. > The spirit is simple: > > Here is this thing, we give it to you for free, use it for your own > benefit however you see fit. But it's a labor of love, and > many people put > thousands and thousand of hours in it, together with their hearts and > souls. As such, they hold it dear, and they want it to survive, and > thrive. All we ask is: if you've made _small_ improvements to > it, to make > it useful to your purpose, please contribute those back such > that our baby > can grow and develop together with your business. I'm against the fact that the GPL or to a smaller extent LGPL tries use the doctrine of derived work as a weapon to achieve their goals. It is a very dangerous weapon, since if the courts or the policitians decide that a strong doctrine of derived work is good it might be disasterous for society as a whole. Various commerical intrest might (read: will) for example try to use this to stop 3rd party additions to their works and I don't want that to happend. In short: Be careful what you wish for: "The road to hell is paved with good intentions" > Note that I said "_small_ improvements" because of the > modular nature of > Wine. If the improvements are big, the DLL separation would > allow them to > keep those changes proprietary. I don't think small improvements is a problem anyway and beginning an implementation of say DCOM is probaly not a small improvement and DirectX certainly isn't. > I fail to see _any_ moral/ethical/philosophical problem with > this. Do you? Perhaps you have been more enlightend now.

5 5

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 19, 2001

Dec. 19, 2001

> Technicalities aside, the LGPL spirit seems to be accepted by most > people. We've heard no end of discussion of what represents > the code, and > so on, but in reality (please Patrik :)), Wine is a > _well_defined_ piece > of software. In fact, it's defined by Microsoft, and well > accepted by the > world at large. > > Now, that being said, there seems to be two camps: > -- the BSD camp, which maintains that BSD is good enough, and that > people will in fact do what the LGPL wants. > > -- the LGPL camp, which says 'well, if that's the case, why > not have it > formalized in the license'? No, I think you misunderstand. I'm not in the BSD camp as you define it. I do not nessarily believe that everybody will follow what the LGPL wants or at least that they will do things that they are certain would have been allowed if it was LGPL. And that is an important part of my objection: It makes it less clear what is allowed. > Before I go any further, I would like to stress a very important > point: Wine is in fact a collection of independent projects. > These are the > DLLs, and they nicely (and unequivocally) partition Wine into lovely > little, independent components. And this means that the LGPL is > independently contained to each and every DLL. It is the _perfect_ > position to be LGPLed. You forget that some "independent"(*) parts like the Crypto API are parts of other DLL:s (like ADVAPI32.DLL) for no particular reason. Actually large parts of the Windows API are "independent"(*). They are just helper function wrappers around other functions. (*) By "independent" mean that they just use other parts of the Windows API like normal applications do and claiming derived work for this would be absurd, just like claiming it for normal applications would be absurd. > At this point, I would like to know if people agree up to > this point. I don't. > The > discussion has been going all over the place, so I would like > to keep this > email short and to the point: > 0. Isn't Wine's best interest to evolve and develop as fast > as it can? Yes. > 1. If so, isn't the LGPL _spirit_ in Wine's best interest? No, not nessararily. See different mail. > 2. If so, why shouldn't we formalize it in the license? But it isn't nessarily so. > When answering these questions, let's try to leave the > commercial aspect > out of it for a second. That is a separate discussion. You > see, the reason > we care about the commercial aspect is that we hope (from > Wine's selfish > point of view -- as it should be!), that the commercial world will > actually _help_ in the development of Wine (that is, having a > commercial > universe around Wine would be in Wine's best interest). Now, > I claim that > the LGPL is _way_better_ for the commercial interests in the > long term, > but I will leave that to a future email (if people care to > discuss it). Claiming that it is better for Wine as a whole is one thing, but claiming that limiting commercial intrests choices is good even for them, requires a explaination.

2 1

implementation of ImageList_*Drag*
by Michael Stefaniuc Dec. 19, 2001

Dec. 19, 2001

Hello, the attached patch (it's my first wine gui patch, that's why wine-devel is CC'ed) implements the dragging part of the ImageList functions. It works quite well with FreeSolitaire besides the dragged image isn't drawn semitransparent. But how do I draw a semitransparent image? IMO this isn't possible with the BitBlt functions. The ImageList_*Drag* functions shouldn't produce flickering as per the MSDN documentation, but ImageList_SetDragCursorImage (at least in Win9x) produces a short flickering when called. I implemented this function to match the behavior of the native comctl32.dll, but it would be very easy to stop the flickering. Should I change it or keep the Win9x behaviour? bye michael Changelog: Michael Stefaniuc <mstefani(a)redhat.com> fixed/implemented the ImageList_*Drag* functions -- 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

1 0

does mingw include share.h
by Bill Medland Dec. 18, 2001

Dec. 18, 2001

I'm just off home now so I haven't time to learn sourceforge and download 100M. I need a share.h to go into the msvcrt (for two lousy symbols). I see that much of the msvcrt is based on mingw. Does it include share.h? TIA Bill

1 0

Re: Big Bummer for running Shrinkered files!
by Robert Baruch Dec. 18, 2001

Dec. 18, 2001

Uwe: > showsehframes.exe from the examples there foinds an endless loop even with > native msvcrt: That was a good idea, to try out that program. I'll have to review how that whole program works. Maybe it has something to do with the fact that scopetable is only valid inside MSVC code -- anything in a frame past the handler and prev ptr is compiler-dependent. Maybe it will work once I finish the EXC_CallHandler code. --Rob

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 18, 2001

Dec. 18, 2001

> Patrik Stridvall wrote: > > > > > Patrik, > > > > > > The more I read your posts, the less I understand what you > > > are trying to say. You argued over many hundreds of lines > > > over weird technical details and various dubious assumptions > > > about what courts will do in the future. > > > > The main point is that what is legal allow is very unclear. > > Hogwash. I feel the LGPL is extremely clear. It allows > you to dynamically link to LGPL code without worries. Full stop. The clearness of the LGPL in itself is a non issue. The issue in the foundation that LGPL rests on namly the doctrine of derived work. > Patrik, it might be good for you to create a web page outlining > the problems you see in the LPGL; that would give you a > chance to explain > them more clearly than is possible in this forum. Do try to > be succinct. > I'd like to understand your point of view. Hmm. I think I already spend to much time trying to explain my point of view. I would rather answer questions concerning details insteed. Perhaps I will someday, but don't hold your breath.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 18, 2001

Dec. 18, 2001

> > But most apps wine will run *cannot* use a GPLed component. GPL > > expressly forbids being linked to a nonGPLed component. > *GPL does not > > only cover the source, but rather the USE of the components > as well. > > Read the > > license. It's quite an eye opener. > > I'd argue (though IANAL) that a nonGPLed win32 executable > running under > wine is not being "linked" to any GPL component - wine itself may be > linking to its own GPL components at run-time depending on > what's going on > with the win32 executable. But in terms of true linkage, I'd > have viewed > the win32 executable as more like a document that causes the host > application (wine) to load appropriate sub-components with > which to process > the document. MS Word (to use an example) might have to > dynamically link in > a special MS Word component to process specifics in my > document, it doesn't > mean my document is "linked" with the MS Word component does it? Ah, you are beginning to see the problem. :-) This is the spot on one of the main problem with the GPL. Proponents of the GPL are trying to use the doctrine of derived work as a means to achieve their goal without realizing (or rather ignoring) that if the doctrine of derived work supported want they wanted it would also, as a logical consequence, support to the absurdity you meantioned above. This is why I firmly oppose the doctrine of derived work and instead hope that the courts will embrace the much more senisible doctrine of combined work that I have been talking about earlier. Of course a strict doctrine of combined work would make the GPL and for that matter the LGPL largely meaningless, since you could distribute the LPGL work, the proprietory patch and a combining script seperately and let the user do the combining as thus no combined work is distributed and thus no violation of copyright law. Note that a doctrine of combined work doesn't effect normal commercial software at all since the end user is legally required to pay for the software if he uses it, regardless of whether the user used some patch offered under whatever license. It ONLY effects viral licenses. > Of course, we could all ask RMS his opinion but we all know > he'll interpret > it (once again) to mean whatever is required to spread his > GPL tenderhooks > as far as possible. Living in Wellington, NZ I'm having to > fight back hard > the temptation to make a "Sauron" joke here ... :-) I don't believe RMS is evil, quite the opposite, just that: "The road to hell is paved with good intentions"

1 0

Re: Big Bummer for running Shrinkered files!
by ek sqrl Dec. 18, 2001

Dec. 18, 2001

On Mon, 17 Dec 2001 14:49:35 +1000 Mike McCormack <mike_mccormack(a)start.com.au> wrote: > Did you try running wine with -winver win98? Yes, Shrinker tries to load a VXD which is not allowed under Wine. At first I was going to implement a special Shrinker VXD replacement for Wine, but then I found that it wouldn't try to load the VXD under --winver nt40. Thus, I figured I would try to resolve the problems with running under nt40, since that would (at least theoretically) improve the existing functionality of Wine, rather than add new functionality. > > Did you try finding an Un-Shrinker? A quick search using google turned > up a few candidates. Haven't tried any out though. Yes, I've looked at them. They all seem to be h4x0r toolz with no source code. Some new news on the Shrinker front. I've managed to determine, for the most part, what Shrinker's exception filter function does. It's a minefield! Recall that earlier I said it was looking for a magic signature in ntdll.dll. I found all of the landmines. The first landmine makes sure the exception handler was called with the code "call ecx". If not, the process dies. Next, we read 8 bytes from the process around that location. If the read fails, the process dies. If the code starting with the call is not FF D1 64 8B 25 or FF D1 64 8B 0D, the process dies. It then tries to allocate some memory, and copies some of the process code into that memory. If the allocation fails, the process dies. With that in mind, it seems that the only thing it's really looking for is that signature. So one idea that I had is a "Shrinker fixer". When Wine loads an executable, it would look for this specific exception handling code, and then NOP out the checks. Is that a reasonable approach? --Rob

4 9

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 18, 2001

Dec. 18, 2001

> Did anybody mention that if wine moved to an LGPL license, we would be > able to borrow code from a wider variety of other projects? > > That would include KDE, libXML, Bochs, OpenOffice, GTK+, Atheos, jCIFS > and any other LGPL (or compatable) projects. Sure, but I would much rather use them by linking them to Wine than borrowing code and having to maintain it. Whether Wine is LGPL or BSD matters not in such cases.

1 0

Re: Installshield 6 (inter-proc) patches
by Roger Fujii Dec. 18, 2001

Dec. 18, 2001

Alexandre Julliard <julliard(a)winehq.com> wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > As for the license of Wine, I was among the ones opposing the LGPL last > > time it was discussed, and I have not changed my mind. I feel that Wine is > > most widely useful if it keeps the X11 license, and usefulness is more > > important in my mind than making it 50% harder for companies to "steal" > > the code. If X11 is so bad for large projects such as Wine, why is the > > largest project of all, XFree86 (and associated projects like DRI), still > > using it, even though its maintainer would have the power to switch to > > e.g. the LGPL or even GPL with a snap of the fingers ("sublicensing" it)? > > A thing to keep in mind is that X11 got almost killed by licensing > issues and the proliferation of closed source vendor versions. You understanding of X11 is pretty flawed. X11 had closed parts of its implementation practically from the very beginning. Look at the original X11 contributers. It was DEC, SUN, IBM... The main reason for the dry spell was that it became a mature product. Why tinker with stuff that basically works? Vendors, quite unlike the GNU people, really resist changing things without a good reason. I think the current interest in the X project was due to the advent of so many graphics cards plus 3d/video. Look at gnuemacs - it's GPLed, and had a really long dry spell. Was the lack of interest the result of the licensing? > If the XFree86 team hadn't picked it up, there probably wouldn't be a free > version of X11 available today. What are you talking about? What do you think is sitting on www.x.org? > This is something that could happen to Wine; Wine should be so lucky as to be accepted like X11..... > and if it does happen, will we find enough people to do what > XFree86 has been doing for X11? Maybe, and maybe not. When I hear > people like Patrik saying that it's OK for parts of Wine to become > proprietary because we can't do everything anyway, I'm worried. If wine was even CLOSE to being complete, I would agree with you. But given its current state, I think that a *gpl license would just discourage companies from even looking at wine (I can't see why any company would like *GPL over X11 so long as they are not the givER - this is not to say they won't accept *gpl, just as to what the preference would be). And given that IMHO, a lot of wine work to be done (looking at Direct* and other M$ stuff) falls under the unpleasant column (ie, most people won't do this for fun), discouraging commercial work doesn't seem to be the way to go. -r

5 6

Re: Installshield 6 (inter-proc) patches
by Mike McCormack Dec. 18, 2001

Dec. 18, 2001

Did anybody mention that if wine moved to an LGPL license, we would be able to borrow code from a wider variety of other projects? That would include KDE, libXML, Bochs, OpenOffice, GTK+, Atheos, jCIFS and any other LGPL (or compatable) projects. Mike http://freshmeat.net/browse/16/?filter=&orderby=popularity_percent+DES C > 0. Isn't Wine's best interest to evolve and develop as fast as it can? ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 18, 2001

Dec. 18, 2001

> > Then if the LGPL holes are dangerous, the X11 license should be even > > more dangerous; after all it's a much larger hole than the LGPL will > > ever have. I still don't understand where you are trying to go with > > your argument. > > > This has been my argument against Patrick exactly. Some > protection is > better than none at all. As a general rule, yes. However this time the protection comes with a price. > > You really make it sound like the LGPL is some kind of unexplored > > wilderness that we shouldn't venture into. The fact is that a large > > majority of free software projects use either the GPL or > the LGPL, and > > in practice it works just fine for them, just as I'm confident it > > would work just fine for us. > > > Agreed. The LGPL is a very well-written fairly clear > license. There are > some borderline cases as mentioned, but this does not mean > that we should > thus throw the possibilty of LGPL completely out the window. The problem is not whether LGPL is well written or not the problem it is the doctrine of derived work. That is very unclear because of lack of good case law.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 18, 2001

Dec. 18, 2001

> David Elliott <dfe(a)tgwbd.org> writes: > > > The crypto part of ADVAPI32 was the example I used. Let's > say I were > > to write a CryptoAPI implementation as a set of seperate > source files. > > With the LGPL I could compile all of that stuff and refer to it as a > > library. What is a library? I would say one or more object files > > linked together form a library. I could then take my CryptoAPI > > library, link it with the rest of Wine's ADVAPI32 and distribute a > > libadvapi32.so that could be dropped into a wine install. > > If it is a completely separate library that doesn't contain portions > that are derivative work of ADVAPI32, then yes you can do that. But > you cannot for instance decide to reimplement CreateWindow and not > release it simply by putting it into a separate file, which was what > Patrik suggested; because your new CreateWindow will necessarily use > internal functions and variables of USER32, and thus would be > considered a derivative work. It takes more that use to be considered a derived work, but the doctrine of derived work is central to the discussion. One thing that is very important to note is copyright only protects expression not fact or ideas. In this case we are talking about use which I guess is better to talk about in terms of functionality. Functionality on the other lies closer to fact or ideas than to expression so I would consider it doubtful for the courts to extend the doctrine of derived work to protect this.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 17, 2001

Dec. 17, 2001

> Alexandre Julliard wrote: > > > > Gavriel State <gav(a)transgaming.com> writes: > > > > > There are several factors to that equation, and I'm > afraid we don't have > > > a firm ETA yet. > > > > Well, this worries me. It sounds like you are planning to > do the same > > thing you did with your DirectX stuff: by making the code > available on > > your site, and promising to release it at some hypothetical future > > date, you remove all incentive for other people to spend time > > improving the main Wine, thus ensuring that it always lacks some > > features. I don't like this at all. > > > > If you can't/don't want to release your code, I'd strongly suggest > > that you reconsider your strategy of making it publicly > available. If > > it was only available to paying customers, there would at least be a > > reason for other people to work on a free implementation. But if > > everybody who needs some feature in Wine can simply download WineX > > instead, no one will spend time re-implementing that > feature. This is > > beginning to seriously hurt the project, and we need to > find a way to > > address this issue. > > The DCOM issues had been ignored by other Wine developers for YEARS > before we came along. Yes, but that is because it hasn't been needed for anything but obscure application until now. > It's not at all clear that our work there has > discouraged anyone else from working in that area. Granted. > To say that > our work is preventing anyone from doing a free version of DCOM is > completely incorrect. To the contrary: we have already contributed > substantial amounts of this code to the public tree - thousands of > lines, in fact. That can only help anyone with a sudden and > unexpected > interest in recreating our work. That is absolutly true and would make any decision not to release it under a free license even more strange. Note however that I'm not accusing you of not releasing it. Not yet, but I reserve the right to do so in the future. Anyway, see below. > Now, it is our firm desire to see *all* of that code end up > in the main > version of Wine. The fact is, unfortunately, that we simply cannot > afford to give everything away as soon as we write it. We only got a > minimal implementation of the DCOM code working six weeks ago. We are > not a rich company, with millions in VC funding to burn; this > means that > our DCOM work has to remain under the AFPL until we can find a sponsor > willing to defray some of the tens of thousands of dollars it cost us > to develop it. I think that you look a things the wrong way. Think of the expense as an extra cost you pay for being early to the market. Sure it won't make your accountant much happier but thats life. :-) What I mean by that is that the DCOM code aiming to get InstallShield to work is not really something that has very much to do with the product you that your customers want to buy. Installation is done only once and can be made in the real Windows if you dual boat and beside it is really something that Wine should have supported already. In short, it was something you had to do because Wine was not mature, because you wanted to be early to market and holding it as proprietary code are unlikely to give you any advantage for very long. If you won't release it somebody else will implement it before long. > Furthermore, we are committed to writing quality, robust > code. We don't > think it's in anyone's best interest for the current version > of the code, > which is effectively limited to the requirements of > InstallShield, to be > used as the basis of future DCOM related work. We in the midsts of > working on a much more flexible architecture which will permit more > than just typelib based proxying. > > I don't really think this affects individual users at all. They can > simply download and use the code from our website, or apply the > necessary patch to WineHQ wine. They can even redistribute it all > non-commercially should they wish. > > Without a doubt, we are committed to the Wine project and have already > contributed a great deal of code to support it. However, to > maintain the > quality and integrity of the project, we stand by our decision of only > contributing code when it makes sense to do so (in order to > allow us to > continue developing quality code) and when it reaches a > certain minimal > degree of quality. Yes, I fully understand that, I'm grateful for all you have done and I'm not making any accusations right now. However I reserve the right to do so in the future. > Publicly questioning our ethics is certainly not the right solution > nor is it in the spirit of the project, especially given how much we > have supported it to-date. We believe that we ARE doing the Wine > user and developer community a service and propelling it further. I don't think Alexandre is questioning your ethics. I think he is question what relation the Wine project should have with you based on praticial issues and not on ethical issues at all. In short: Should the Wine project wait until you release or should it not? > The > only people that our lack of haste in contributing code back really > affects are organizations that want to make immediate commercial use > of the code. These organizations include the one you work > for, and its > clients. If you want to see the DCOM code Wine-licensed soon, you > need to talk to your boss and your clients, not me. :-) I fully understand that you wish to take every opportunity to get some extra income but I think your analysis is partly wrong. Sure it is possible you might get some sort of one time payment from somebody if you are a little clever, but realize the following. A significant part of your potential customers consists of, I guess, people who would very much like to not to dual boot any longer and their first priority is that their normal productivity applications installs and works. Games are their second priority and so as long InstallShield doesn't work in normal Wine you risk losing them since they will continue to dual boot and presumably continue to play their games in Windows. > At this point, I think it would be best if we were to take this > discussion off-line so that we can determine a solution that works > for everyone. For any discussion concerning milking some money out of CodeWeavers or their clients, absolutely. Not my problem. :-) However one important problem that really can't be discussed off-line, is what your relation you wish to have to the Wine project. In fact, it can't be discussed at all, only your actions can determine it. I will be blunt: Do you see yourselves as a complement to Wine or a competitor to Wine? Because not releasing important core code like code needed to install important applications especially non-games might be interpreted as really wish to compete with Wine instead of being a completement. Note again (the third(?) time) that I'm not accusing you of anything, at least not yet, but I wish to point out that it might hurt your public image if people see as a competitor instead of a complement to Wine. Being vague and saying: "There are several factors to that equation, and I'm afraid we don't have a firm ETA yet." will not help your image.

10 16

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 17, 2001

Dec. 17, 2001

> > But you cannot change the license once it is mostly > complete; by then > > it will be too late. > > If it was mostly complete, what would it be too late for? Yes, I wonder that as well. To late for a 100% open source world perhaps, but then only the most naive (like Richard Stallman) actually think it is realistic. Open source is good for some things, but it is not the solutions to all problems. > Patrik Stridvall <ps(a)leissner.se> wrote: > > > Why would you want to change the license when it is mostly complete? > > > > There will be very little reason for companies to enter the market > > at that time and why try to make it difficult for the few > that might. > > I was using the following lines of thinking: If it were > mostly complete, > any changes would most likely be the result of bug fixes or > minor improvements. Exactly and therefore there would be very hard to find a niche for a company to profit in. > In the end, if you look at the larger projects (mozilla, > openoffice, perl), you will > see that any of them uses a straight *gpl scheme. My You mean _neither_ of them, I guess. > suggestion is that if you are > going to change it, change it to something like a currently > existing project that > has commericial involvement (mozilla/openoffice). And the advantage of this would be the following?

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 17, 2001

Dec. 17, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So you mean that all the people that are current voluntering > > to work of Wine won't work on Wine if it is almost complete > > just because somebody else have done the parts they need > > to run their applications and that they will happily pay for > > the right to use it. > > No, I'm not saying they won't work on it when it's almost complete. > I'm saying that there may not be enough incentive to complete it if > all the parts are available under more or less proprietary > licenses. Maybe I'm wrong, but your reasoning that it's OK for people > who want games to have to pay for it certainly doesn't reassure me. What I meant is that for people that play games might it might make more sense to pay a monthly fee since most of them, I guess, lack the knowledge to contribute to Wine anyway. Companies wishing to use Winelib to port their productivity application are not in the same situation, they have the resources pay somebody to improve what they need or perhaps even do it themselves. Sure they can also choose to pay companies with business models like Transgaming but then they become dependent on them to fix bugs in the extra parts they supply. Actually, this is analogous to normal argument for using open source instead of proprietary software, nothing that is unique to Wine. In short: The incentive is the same as working on any open source software. Sometimes is makes sense, sometimes is doesn't. > > In that case it would be disasterous to make Wine run > > all Microsoft implemented non-core Wine DLL:s because > > then everybody would just be happy to use the Microsoft > > DLL:s and nothing beyond non-core would ever be > > implemented. > > It would not be a disaster, but it is certainly a potential problem > too. It is a smaller problem first because making the dlls run is > about as much work as reimplementing them, and because they are > completely proprietary, not half-way open source. But yes, I do think > a number of features could have improved faster if people didn't use > native dlls to work around the problems. There is a distinct possibillity that people used the time they didn't need to reimplement the working Microsoft implemented functions to implement functions that didn't work so it is quite hard to provide hard proof on this. Furthermore the fact that a lot of the Microsoft implement functions works might instead have encourage people to work on because SOMETHING work instead of giving up then NOTHING worked. In any case I think neither of us will be able prove the correctness of our respective theory.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 17, 2001

Dec. 17, 2001

> > > and if it does happen, will we find enough people to do what > > > XFree86 has been doing for X11? Maybe, and maybe not. When I hear > > > people like Patrik saying that it's OK for parts of Wine to become > > > proprietary because we can't do everything anyway, I'm worried. > > > > If wine was even CLOSE to being complete, I would agree with you. > > But you cannot change the license once it is mostly complete; by then > it will be too late. Why would you want to change the license when it is mostly complete? There will be very little reason for companies to enter the market at that time and why try to make it difficult for the few that might.

2 1

win32eviceIoControl problem
by Ancient Computers Dec. 17, 2001

Dec. 17, 2001

When trying to run a game called Visual Pinball, I get this as console output. The DecodeHash problem can be fixed by using a windows version of advapi. What about the win32eviceIoControl problem, what is it about ? [root(a)localhost Visual Pinball]# [root(a)localhost Visual Pinball]# wine Vpinball.exe x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403b58f8,00010022,2):stub fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403b5d64)->(00000000,00001008) fixme:commdlg:GetFileName95 Flags 0x00000002 not yet implemented fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device NWLINK fixme:advapi:CryptAcquireContextA (0x405b5c30, (null), (null), 1, f0000008): stub! fixme:advapi:CryptCreateHash (0x405b5c34, 0x8001, 0x0, 00000000, 0x405b5c58): stub! fixme:advapi:CryptHashData (0x10010, 0x49ab80, 14, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x405b5c5c, 4, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x405b583c, 4, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x41615710, 4, 00000000): stub! _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 17, 2001

Dec. 17, 2001

> While I am thinking about this, there are some interesting > things in the > LGPL. One of these is that you can modify the LGPL library > to work with > your code. The catch is that you have to release source to the > modifications and that the modifications must not require that your > proprietary component be included. The text of the license > mentions that > if you modify a function that computes square roots to hook into your > proprietary components that the function must still compute > square roots. > But in Wine's case, many functions don't do what they are > supposed to do, > or they do what they are supposed to do but that's not what > actually needs > to be done. That is a very intresting point. Thank you for bring it to my attention. I didn't realize that. Hmm. I will have to think about it what this means, if it indeed means something. > This stuck out like a sore thumb to me, but > maybe it's not > such a big deal. Can you perhaps say exactly what bothered you?

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 17, 2001

Dec. 17, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > > No, of course the LGPL doesn't provide absolute > protection; nothing > > > does, and I don't think absolute protection is desirable > either. There > > > are some things that the LGPL clearly allows, some that it clearly > > > forbids, and a number of border cases, that frankly are only > > > interesting to people who want to try to get around the license > > > restrictions. And what would be the point of doing that? > > > > Making their business model work. > > Trying to ensure investment return. > > That would be the case if the code they are using magically turned > LGPL once they had invested millions. But that's not possible, since > only new code becomes LGPL. Indeed and that makes any protection LGPL gives even weaker. My earlier analysis was based a 100% LGPL:ed Wine... > Now, if someone is basing his business > model on turning LGPL code proprietary by exploiting possible > loopholes in the license, I wouldn't suggest investing in his > company... I don't think our goal in choosing a license is to make > sure every flawed business model can succeed. There are lots of > reasonable business models that can be built on a LGPL (or GPL) code > base. Lets arguments sake assume somebody is called Bar and have a business model that might possibly be illegal under your interpretation of the LPGL. What's preventing him from creating a library called bar under his proprietory license as well as supplying a patch under the LGPL that results in code looking like: void WINAPI Foo(void) { #if HAVE_LIBBAR BAR_Foo(); #else /* Old Wine code */ #endif } Wouldn't this always be legal under the LGPL? In that case the only thing you did by threatening to sue him was to increase his costs. The point is, you didn't get his code, that it seems, that you hoped you would get. > > The current license is something that is easy to understand and > > are unlikely to scare companies like Transgaming away, but can > > you really say the say same about LGPL? > > OK, now we are getting somewhere. So your argument is basically that > the LGPL might scare some companies away. Yes. > Yes, I agree that's a > possibility. Good. > Most likely these companies will have been scared away > from Linux already, since many other things they need are also LGPL > (most notably the C library). That is a claim that makes no sense at all. Why should anybody want to make a business model out of modify or making additions to the almost 100% complete C library? One of the main reason Wine has the possiblity at all to attract companies like Transgaming is that it is not complete far from it. > But of course this possibility cannot be > excluded. Indeed. > I think that the risk of this happening is not larger than the risk of > having companies hold hostage pieces of Wine, and the damage in the > second case is much larger; so I think the LGPL would minimize the > potential damage to the project, even if damage cannot be excluded in > any situation. Your analogy with hostage holding is a bad analogy, sure I understand that you are refering to Transgaming promises to release eventually. If you don't believe them announce that publicly and developers that might be hanging back in fear of doing "double" work might step forward. They might not, of course, but then perhaps nobody was intresting in doing work in that area, Transgaming or no Transgaming. > Of course only the future can tell us who is right. Agreed.

1 0

Filename case handling
by Duane Clark Dec. 17, 2001

Dec. 17, 2001

I have a question about the handling of filename case when trying to find an existing file. When files are on a win filesystem, the case is ignored, by the setting of flags by DRIVE_GetFlags(). As expected. When on a ext filesystem, that call sets the DRIVE_CASE_SENSITIVE flag, which is ok. But then the flag is used in the call to DOSFS_FindUnixName() (from DOSFS_GetFullName()), and I guess the fundamental question I have is under what circumstances wine would want to do a case sensitive search. One of my apps (Xilinx ngdbuild) always supplies upper case names when searching for a file, but the files always have lower case names (they were created by another Xilinx app). When searching for this file in DOSFS_FindUnixName() on an ext filesystem, the first test always fails, because we do a case sensitive test: if (!ignore_case) { if (!strncmp( long_name, name, len )) break; } However, and here is the other part I am questioning, if the file is an 8.3 filename, an alternate dos filename is created by DOSFS_ToDosFCBFormat(), and then a second test is performed here: if (!strcmp( dos_name, short_name )) break; This call passes and the file is found. However, if the file is not an 8.3 filename, the call to DOSFS_ToDosFCBFormat() fails, and no case insensitive test is made. So it seems to me that either a case sensitive search should be made in both cases, or in neither case. And of course I think that it should be both cases (since this fixes my app) :-) Duane

3 4

Wine and Drivers
by Viacheslav Zilberfayn Dec. 17, 2001

Dec. 17, 2001

Hello, I'm wondering if anyone ever attempted to use wine to run Windows driver, specifically videocard drivers. Or at least to load them. I'm thinking of using Wine to load windows drivers into Linux, along with whole DirectX. I understand that drivers are special s/w, but I guess they use smaller part of windows api. Any information/opinions would be appreciated. Slava ===== --- NOTE: EMAIL HAS CHANGED !!! --------------------- Slava Zilberfayn | Home +1(416)7838430 EMAIL: slavka012(a)yahoo.ca ADDRESS: appt 1219, 377 Ridelle ave, M6B1K2, Toronto, ON, CANADA ______________________________________________________ Send your holiday cheer with http://greetings.yahoo.ca

2 1

Microsoft Antitrust Remedy proposal, take 3
by Dan Kegel Dec. 17, 2001

Dec. 17, 2001

I've learned a fair bit since putting together my essay on the States' proposed remedies. In particular, Microsoft's response to the States was enlightening; it pointed out the parts of the Court of Appeals ruling that need to be heeded when fashioning a remedy. I now feel that the States' proposal has little chance of being accepted by the judge. The Proposed Final Judgment negotiated by Microsoft and the DOJ is probably the right starting point for any new proposals. Accordingly, I've started over, and this time I'm sticking very close to the negotiated settlement, and paying close attention to the law. As before, you can read my proposals at http://www.kegel.com/remedy.html I'm looking forward to your feedback. I've set up a mailing list at http://groups.yahoo.com/group/ms-remedy/ (aka ms-remedy-subscribe(a)yahoogroups.com ) for those who want to discuss this further. Together we can find a way to make the settlement more just and fair, or I'll eat my hat. Dan Kegel http://www.kegel.com

1 0

Re: Big Bummer for running Shrinkered files!
by Mike McCormack Dec. 17, 2001

Dec. 17, 2001

Hi Robert, Did you try running wine with -winver win98? Did you try finding an Un-Shrinker? A quick search using google turned up a few candidates. Haven't tried any out though. eg. http://www.programmerstools.org/unpackers.htm Mike > Given that the application appears to look into ntdll.dll's > code to compare it against essentially a magic number, is there > any hope of getting Shrinkered exe's to run under Wine? ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0