my trouble
hello all: I download one Game http://www.qf.com.cn/software/qfweiqi.exe run in WINE but It show me like this. [EMAIL PROTECTED]:~/.wine/drive_c/qf wine GoStoneClient.exe fixme:ole:CoRegisterMessageFilter stub wine: Unhandled exception (thread 002c), starting debugger... WineDbg starting on pid 0x2b In 32 bit mode. 0x404719c4 DebugBreak+0x4 in kernel32: popl %ebp Wine-dbg I have allready install win98 dll store in wine.my system is SuSe8.2 pyd.
x11drv regression?
Hi, I've just synced with CVS and the following code and I can no longer get an x11 window ID using (Window)GetPropA(HWND,__wine_x11_client_window ); I've had a look at X11DRV and there have been a few changes reciently, should I be using something else? ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: x11drv regression?
Oliver Stieber wrote: I've just synced with CVS and the following code and I can no longer get an x11 window ID using There is no longer any X11 window ID associated with child windows. Wine has been re-architected so that only top level windows have an associated X11 window. Mike
Re: x11drv regression?
--- Mike McCormack [EMAIL PROTECTED] wrote: Oliver Stieber wrote: I've just synced with CVS and the following code and I can no longer get an x11 window ID using There is no longer any X11 window ID associated with child windows. Wine has been re-architected so that only top level windows have an associated X11 window. Mike I need to create a opengl context against the window, is that still possible? I expect known I can drill down through all the X11 windows until I find the correct one, but that's a bit outside the box. ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: [AppDB] bug on links
Hey, On Mon, 31 Jan 2005 23:01:22 +0100, Raphael [EMAIL PROTECTED] wrote: try http://appdb.winehq.org/appview.php?appId=443versionId=627 select the www.darkageofcamelot.com link bug :) Far from a bug, that's how hyperlinks work. The people entering URL should use http://www.domain.com instead of www.domain.com. We can enforce that tough with some regex. I'll add that. But it won't fix this, that needs to be fixed by the app maintainer. Paul
Re: x11drv regression?
On Tue, Feb 01, 2005 at 10:05:52AM +, Oliver Stieber wrote: I need to create a opengl context against the window, is that still possible? I think you need to check the patch Alexandre comitted yesterday (http://www.winehq.org/hypermail/wine-cvs/2005/01/0724.html). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: x11drv regression?
I need to create a opengl context against the window, is that still possible? I think you need to check the patch Alexandre comitted yesterday (http://www.winehq.org/hypermail/wine-cvs/2005/01/0724.html). Yeah, If Alexandre committed a patch that converted the entire code base from C to pure assembler, his changelog would read: Code optimizations (Although if he could find a way to say it in one word, he would) grin Cheers, Jeremy
Software Freedom Law Center
Hi Folks, There is an exciting announcement out today: http://www.desktoplinux.com/news/NS7711938137.html Essentially, OSDL has funded a community oriented pro-bono legal service for Free and Open Source Software Projects. The Center is led by Eben Moglen, the chief counsel for the FSF. I've been speaking privately with Eben Moglen about this new effort, and he tells me that they would like to have the Wine Project as one if their very first clients. Candidly, this seems fantastic to me; one of the difficult things that I face when promoting Wine is peoples Fear, Uncertainty, and Doubt about the legality of Wine. Having an opportunity to clarify these legal issues is probably the most important thing that could happen for Wine, in my opinion (well, okay, maybe it's less important than support for Pirates! grin). However, before I go off to request the services of the SFLC, I thought I would post this announcement here and open it for any discussion. I'd particularly like to hear if folks can think of any reasons why this might be a bad thing. Finally, the key objectives from my standpoint are as follows: 1. Get an opinion written on Wine and copyright issues (imho, we have no IP issues here) 2. Get some legal research done on Patent issues I don't know how this will turn out, so I think we should wait for the research. 3. Investigate the legal doctrine surrounding what use a monopoly can make of its patents; I know that US antitrust law provides some restraints, but it would be great to have a legal opinion on the matter. Thoughts? Comments? Cheers, Jeremy
Re: x11drv regression?
On Tue, 01 Feb 2005 10:05:52 +, Oliver Stieber wrote: I need to create a opengl context against the window, is that still possible? Look at the bottom of the patch, the atom name changed but for toplevels it's still there.
Re: MAPI32.dll.so - how to use in linux programs?
On Tue, Feb 01, 2005 at 04:45:41AM -0800, Jon Griffiths wrote: Hi Luke, i noticed that Wine has a mapi32.dll.so. The current MAPI code is very, very far from complete. I have been implementing it in a bottom up manner (i.e. starting with the lower level/utility functions and working up toward constructing the higher order functions/objects). For example, there is no table support at present (I have an IMAPITable implemenation of sorts, but its not ready to be committed yet, pending cleanup, tests and thread safety checks). Providing the message stores etc must then be built on top of these objects. I believe Crossover Office runs MS Outlook so you may have more success using the native dlls at this moment in time. ah ha, you're going to like this: i'm implementing exchange 5.5 server so the native dlls don't help :) [hm, if crossover office runs ms outlook, that would mean that codeweavers enhanced the mapi code, hm...] what i am looking to do is to actually _implement_ a MAPI database, such that tables can be read etc. i haven't a clue what i'm doing, so am just copying the data from off-the-wire. but it will look very strangely familiar to anyone who has been working for some time with MAPI. i spent two hours yesterday mapping the data structures in mapidefs.h into emsabp.idl. they're identical (idl file sent to wine-devel list yesterday). For the functions that are complete there is documentation in the source: make htmlpages from the base Wine dir will format these into readable html starting at documentation/html/index.html. thank you. If your tests will rely on an exchange server being present it is unlikely that you will be able to put them in the main wine tree, so a stand alone program is likely the best solution. ha ha - i am _replacing_ exchange 5.5 server :) As for sample programs, a quick google for mapi sample program and you will get a bunch of links, including some freely downloadable MS samples. ... i am kinda looking for something with a Makefile, compiles and links against Wine directly - under linux not windows. i am inclined to rip bits of code out of Wine (parts of header files so far) until i can get to grips with it. the thing is that by the time i am done, there will be some code that should just... integrate in a _very_ obvious manner into Wine's MAPI32.dll implementation, providing an interface to Nspi (emsabp.idl) and EcMapi (emsmdb.idl). ... it's just that at the moment i haven't really got a handle on this stuff: all i can say is i appear to be implementing MAPI tables and MAPI properties etc. but don't know what those really are. l.
Re: x11drv regression?
On Tue, Feb 01, 2005 at 07:27:32AM -0600, Jeremy White wrote: If Alexandre committed a patch that converted the entire code base from C to pure assembler, his changelog would read: Code optimizations :) Truth be told however, Alexandre is annoyingly to the point. :) So no, I don't think he's overly terse. -- Dimi.
Re: MAPI32.dll.so - how to use in linux programs?
Luke Kenneth Casson Leighton wrote: [hm, if crossover office runs ms outlook, that would mean that codeweavers enhanced the mapi code, hm...] That's incorrect. We allow Office 2000/XP to install and it installs it's own version of MAPI. Mike
Re: x11drv regression?
Oliver Stieber [EMAIL PROTECTED] writes: Hi, I've just synced with CVS and the following code and I can no longer get an x11 window ID using (Window)GetPropA(HWND,__wine_x11_client_window ); I've had a look at X11DRV and there have been a few changes reciently, should I be using something else? The client window is gone, but __wine_x11_whole_window still works (though only for top-level windows). -- Alexandre Julliard [EMAIL PROTECTED]
Re: MAPI32.dll.so - how to use in linux programs?
On Tue, Feb 01, 2005 at 11:20:12PM +0900, Mike McCormack wrote: Luke Kenneth Casson Leighton wrote: [hm, if crossover office runs ms outlook, that would mean that codeweavers enhanced the mapi code, hm...] That's incorrect. We allow Office 2000/XP to install and it installs it's own version of MAPI. ah, thanks for the correction.
Re: NPTL and Wine threads
Luke Kenneth Casson Leighton wrote: there is some code in FreeDCE which expects to be able to jump out of a cancellation handler Then FreeDCE should be fixed to be POSIX-compliant, I think. Or is there something subtle going on here? the behaviour of LinuxThreads is different from NPTL. therefore, given that this cancellation thing matters for dce applications (the runtime relies on it being possible) i thought you might wish to be aware of this subtle difference in case Wine MSRPC or other applications also rely on it. that's all - nothing more. Right. Nothing subtle, then. I guess FreeDCE needs some work to run on NPTL or other POSIX-compliant threads packages, as it's using Linuxthreads behavior that is an extension of POSIX threads. (Surely FreeDCE doesn't *need* to longjmp out of a cancellation handler; it can't be that hard to fix.) Thanks for the heads up. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: MAPI32.dll.so - how to use in linux programs?
Hi Luke, i noticed that Wine has a mapi32.dll.so. The current MAPI code is very, very far from complete. I have been implementing it in a bottom up manner (i.e. starting with the lower level/utility functions and working up toward constructing the higher order functions/objects). For example, there is no table support at present (I have an IMAPITable implemenation of sorts, but its not ready to be committed yet, pending cleanup, tests and thread safety checks). Providing the message stores etc must then be built on top of these objects. I believe Crossover Office runs MS Outlook so you may have more success using the native dlls at this moment in time. For the functions that are complete there is documentation in the source: make htmlpages from the base Wine dir will format these into readable html starting at documentation/html/index.html. the test program relies on a test loader program, so i can't find a int main (char *argv[], int argc) anywhere nor is it obvious what's going on. Assuming you are referring to dlls/mapi32/tests/, the test framework is integrated to allow the tests to share common code and for multiple tests to be run from one place. The start_test() macro defined a test name which is then linked into the main mapi32_test.exe.so and available by running the test with that name as a parameter (see include/wine/test.h for the common code that supports this). Note that these tests don't yet test anything to do with mail per se, they are more concerned with ensuring the various low level functions in the dll are correct. If your tests will rely on an exchange server being present it is unlikely that you will be able to put them in the main wine tree, so a stand alone program is likely the best solution. As for sample programs, a quick google for mapi sample program and you will get a bunch of links, including some freely downloadable MS samples. I personally am doing my current testing directly against the native (XP) dll itself, it being too early at this point to attempt to get any 'real' programs running with the code. I have a fair amount of not yet submitted stuff for this dll; if you think it will help I could clean it up and pass it on for your perusal. Also if you create/discover anything that you think may be helpful to implementing parts of this dll (and you are free to distribute it), please feel free to send it to me. Cheers, Jon = Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance... - Live [EMAIL PROTECTED] __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
Re: MAPI32.dll.so - how to use in linux programs?
Luke Kenneth Casson Leighton wrote: ... i am kinda looking for something with a Makefile, compiles and links against Wine directly - under linux not windows. i am inclined to rip bits of code out of Wine (parts of header files so far) until i can get to grips with it. It looks like what you are looking for is a vanilla Winelib application. It compiles on Linux with a Makefile it can freely be linked to any Linux resource/Library and in turn also use Wine or native windows DLLs. Only thing is that it is executed under the Wine loader and must keep some linking and structure rules special for wine. Once it works it is easy to take code from a Winelib App and make it a Winelib DLL. So Just look at the Winelib programmer's guide (On Winehq) documentation on how to make a Winelib application. Hope that helps Free Life Boaz
Re: x11drv regression?
--- Alexandre Julliard [EMAIL PROTECTED] wrote: Oliver Stieber [EMAIL PROTECTED] writes: Hi, I've just synced with CVS and the following code and I can no longer get an x11 window ID using (Window)GetPropA(HWND,__wine_x11_client_window ); I've had a look at X11DRV and there have been a few changes reciently, should I be using something else? The client window is gone, but __wine_x11_whole_window still works (though only for top-level windows). -- Alexandre Julliard [EMAIL PROTECTED] I've got that working now thanks. ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: NPTL and Wine threads
On Tue, Feb 01, 2005 at 06:56:57AM -0800, Dan Kegel wrote: Luke Kenneth Casson Leighton wrote: there is some code in FreeDCE which expects to be able to jump out of a cancellation handler Then FreeDCE should be fixed to be POSIX-compliant, I think. Or is there something subtle going on here? the behaviour of LinuxThreads is different from NPTL. therefore, given that this cancellation thing matters for dce applications (the runtime relies on it being possible) i thought you might wish to be aware of this subtle difference in case Wine MSRPC or other applications also rely on it. that's all - nothing more. Right. Nothing subtle, then. I guess FreeDCE needs some work to run on NPTL or other POSIX-compliant threads packages, *sigh*. yes. depends on your version of POSIX (final or draft 4). loic is working on keeping dcethreads current, at least. there are approx 350 occurrences of pthread_somethingorother in FreeDCE, so it's not a trivial task, more's the pity. as it's using Linuxthreads behavior that is an extension of POSIX threads. (Surely FreeDCE doesn't *need* to longjmp out of a cancellation handler; it's the dcethreads (posix draft 4) emulation library that handles that, from what i can gather. it can't be that hard to fix.) Thanks for the heads up. ack.
Re: NPTL and Wine threads
Luke Kenneth Casson Leighton wrote: On Mon, Jan 31, 2005 at 08:28:53PM -0800, Dan Kegel wrote: Luke wrote: it's come to my attention that NPTL cannot cope with jumping out of a cancellation handler. Tough noogies, as it were. See it'll bother me later but for now it doesn't :) there is some code in FreeDCE which expects to be able to jump out of a cancellation handler Then FreeDCE should be fixed to be POSIX-compliant, I think. Or is there something subtle going on here? the behaviour of LinuxThreads is different from NPTL. therefore, given that this cancellation thing matters for dce applications (the runtime relies on it being possible) i thought you might wish to be aware of this subtle difference in case Wine MSRPC or other applications also rely on it. If I understand it correctly, cancellation handlers are used for cleaning up when a thread is terminated. Windows doesn't have an eqivalent feature so if you forcefully terminate a thread then you leak resources and could have terminated with a lock held. However, in kernel designers seem to have thought about this problem and have added features to the one of the locking primitives (the NT mutant, or Win32 mutex, also used by Win32 critical sections) so that if the owning thread was terminated then calls to wait on the lock will return with a error code signaling that the owning thread was terminated so that they can clean up. For more details see here: http://blogs.msdn.com/larryosterman/archive/2004/09/24/233969.aspx It doesn't look like cancellation handlers are called by the pthread emulation code, but I can't see why it would be necessary at the moment. Rob P.S. Because of the reasons above, using the Win32 TerminateThread function is a sign of bad programming, except when used by a debugger. Similarly, SuspendThread has the problem above that it could suspend a thread whilst inside the heap critical section and similarly, should not be used, except in a debugger.
Re: RESEND: Enable GCOV Code Coverage
Aaron Arvey wrote: This is the third or fourth resend... anything I'm unaware of? We're using gcov and lcov to measure how well the Wine test suite covers the wine source tree. Here's our first cut at making it easy to run wine compiled for coverage testing, and view the results using the simple text interface of gcov. A seperate patch for lcov will be released soon. I think the issue with this patch is that it isn't it doesn't appear to be useful for a significant number of people and could be maintained as an external patch by the people who do think it's useful. Maybe you could try to persuade us as to why everyone should be using gcov? Rob
DLL Load Question: Please Help!
Hi, I have windows binary-only, third-party .DLL library without any source files. I would like to use it in my unix-based project, which is compiled with usual GNU C compiler. Wine documentation says Wine is able to load external .DLLs, but does not explain how to implement such ability in userland program using Wine API. I've discovered LoadLibrary() and GetProcAddr() functions compiled into built-in DLL (kernel32.dll.so), so in order to load my DLL I use the function LoadLibrary(somelib.dll), linking my project with -lwine and -lkernel32. The problem is that when my application calls LoadLibrary(), it causes Bus Error. Back tracing using gdb shows that the crash appears under such sequence: in main() in LoadLibraryA() at module.c:745 in LoadLibraryExA() at module.c:706 in FILE_name_AtoW() at file.c:198 in ?? () from kernel32.dll.so The function call at file.c:198 is RtlInitAnsiString() and (as I understand) is unreferenced in kernel32 and uses ntdll.dll.so. What things should I do before calling LoadLibrary()? By the way: If I call RtlInitAnsiString() directly from main(), linking my project with ntdll.dll.so, it is called correctly, works and returns some result. I tried to define -lntdll within LDFLAGS, in this case compile finishes cleanly, but the Bus Error still appears. Also I tried to find any examples showing how to load external .DLL. I've found no examples. Note: there is no ability to obtain library sources. Bye.
Re: Update: olepicture.c compile failure : `UserData' / `DGifOpen'
Rizwan Kassim wrote: It seems that configure approves of vesrion 3.0.0 of libungif.so / gif_lib.h, but compile fails using 3.0.0. DGifOpen gif_lib.h 4.0.0 compiles correctly (even without updating libungif.so, but afaik thats pretty poor practice) The gif_lib.h that configure approves of is labeled version 3.0 by Eric S Raymond. (from gif_lib.h - 4.0.0 : GifFileType *DGifOpen(void *userPtr, InputFunc readFunc);/* new one Interestingly, it seems that configure DOES show the failure during the test compile: ... configure:15599: checking for -lungif soname configure:15629: gcc -o conftest -g -O2 conftest.c -lungif 5 /tmp/ccdg49tg.o: In function `main': /home/rizwank/wine/conftest.c:155: undefined reference to `DGifOpen' collect2: ld returned 1 exit status configure:15635: $? = 1 configure: failed program was: snip confdefs.h and a few more lines configure:15738: result: libgif.so Look in configure.ac for references to DGifOpen. You'll find WINE_GET_SONAME(ungif,DGifOpen) WINE_GET_SONAME(gif,DGifOpen) So Wine is looking in two places for DGifOpen, which explains perhaps why you're seeing the failure in the output of configure; one of the places it's looking doesn't have it. (Just a guess.) As to who would know what's going on, try searching wine-patches for those lines, and you'll see two fairly recent patches, http://www.winehq.com/hypermail/wine-patches/2004/08/0045.html http://www.winehq.com/hypermail/wine-patches/2004/09/0252.html by Huy and Marcus. Since they've been playing with the code, maybe they can comment on the real problem you're having. So, whats the next step? Should it be a critical error for configure? Should configure report the incorrect gif_lib.h (and old libungif)? I'm new enough to OSS projects that I'm not sure if I should : a) attempt to patch configure to report the error and stop the configure process Yes, once you understand that section completely. We do want it to fail in configure rather than while compiling wine. b) patch olepicture.c to stop using DGifOpen I doubt it, but I haven't looked at those libraries c) submit gif_lib.h to the tree in dlls/oleaut32 No, that would break encapsulation of the library. This has been (partially) reported as Bug 1730 and 2437. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: MAPI32.dll.so - how to use in linux programs?
Boaz Harrosh wrote: Luke Kenneth Casson Leighton wrote: ... i am kinda looking for something with a Makefile, compiles and links against Wine directly - under linux not windows. i am inclined to rip bits of code out of Wine (parts of header files so far) until i can get to grips with it. So Just look at the Winelib programmer's guide (On Winehq) documentation on how to make a Winelib application. for inspiration, you could look at the makefiles of the various winelib programs in the /programs directory in the wine source code.
Re: DLL Load Question: Please Help!
On February 1, 2005 08:46 am, Sergey Efimoff wrote: Hi, I have windows binary-only, third-party .DLL library without any source files. I would like to use it in my unix-based project, which is compiled with usual GNU C compiler. Wine documentation says Wine is able to load external .DLLs, but does not explain how to implement such ability in userland (Unless things have changed without me noticing) You are going to have to investigate WineLib. You can't simply link Wine into an existing unix executable, Because of some low level stuff Wine has to be the main process. Bye. -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
Richedit using program
In case anyone is interested, there is an open source (GPL) notepad replacement which does syntax highlighting. You can grab it at http://notepad-plus.sourceforge.net/uk/site.htm. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
wine
I use x86 solaris. I got these messages compiling wine-20050111. configure: WARNING: sys/reg.h: present but cannot be compiled configure: WARNING: sys/lwp.h: present but cannot be compiled configure: WARNING: pthread.h: present but cannot be compiled configure: WARNING: arpa/nameser.h: present but cannot be compiled configure: WARNING: GL/glx.h: present but cannot be compiled checking for assembler keyword for word values... configure: error: could not discover how to specify word values with assembler.
Lostwages: introduction-2.diff
Hello, In my first patch I had a incorrect link.. Tom Changelog: Fix a link introduction-2.diff Description: Binary data
Re: Lostwages: introduction-2.diff
Tom wrote: Hello, In my first patch I had a incorrect link.. Tom Changelog: Fix a link Grr... Wrong list :-) Tom
Re: DLL Load Question: Please Help!
On Feb 1, 2005, at 9:04 PM, Bill Medland wrote: I have windows binary-only, third-party .DLL library without any source files. I would like to use it in my unix-based project, which is compiled with usual GNU C compiler. Wine documentation says Wine is able to load external .DLLs, but does not explain how to implement such ability in userland (Unless things have changed without me noticing) You are going to have to investigate WineLib. You can't simply link Wine into an existing unix executable, Because of some low level stuff Wine has to be the main process. Unfortunately, I cannot use Wine as a main process (did you mean the stuff which is now made by preloader?). My project is a complex multi-threaded application, and the DLL mentioned above is to be only the small part of it. If I had to use this DLL in a simple application, I would certainly used Wine as the main process. So, is it unreal to use windows DLL as a child instance? By any means? Bye.
Re: DLL Load Question: Please Help!
On February 1, 2005 11:53 am, Sergey Efimoff wrote: On Feb 1, 2005, at 9:04 PM, Bill Medland wrote: I have windows binary-only, third-party .DLL library without any source files. I would like to use it in my unix-based project, which is compiled with usual GNU C compiler. Wine documentation says Wine is able to load external .DLLs, but does not explain how to implement such ability in userland (Unless things have changed without me noticing) You are going to have to investigate WineLib. You can't simply link Wine into an existing unix executable, Because of some low level stuff Wine has to be the main process. Unfortunately, I cannot use Wine as a main process (did you mean the stuff which is now made by preloader?). My project is a complex multi-threaded application, and the DLL mentioned above is to be only the small part of it. If I had to use this DLL in a simple application, I would certainly used Wine as the main process. So, is it unreal to use windows DLL as a child instance? By any means? Bye. I believe so. One option you might want to consider is placing the Windows DLL in a server process of some sort and using tcp/ip or some other IPC to talk between the two processes. Then one process can be unix and one wine. -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
Re: Software Freedom Law Center
On Tue, 01 Feb 2005 07:38:42 -0600, Jeremy White [EMAIL PROTECTED] wrote: I've been speaking privately with Eben Moglen about this new effort, and he tells me that they would like to have the Wine Project as one if their very first clients. I think this is an excellent idea. Your three ideas were great. I can also think of a few other things: 1) EULA enforcement. Are there areas where EULA's don't apply, is that information useful to us in any way, or is it information we want to publish? 2) Along the same lines, I'm sure most MS EULA's have boilerplate that says, If any part of this EULA is unenforceable, it does not affect the other parts. Are there any parts of MS EULA's that aren't enforceable because they are a monopoly? What about redistribution rights? Can the core fonts be packaged? 3) An inward look at Wine - are there copyright/trademark issues we need to be aware of other countries? 4) I'm going to be writing a chapter called Enterprise Deployment for this little book in a few weeks. Something I need to cover is licensing . Would they be willing to review it? It's going to be about 3 - 5 pages long. 5) *putting on PR hat* Is there something we could have them look at or something they could do that would that would be newsworthy? If both OSDL and Wine could come out with a press release it might create a nice buzz. Something like, OSDL Successfully Lobbies Macrovision to Produce Safedisc Driver for Wine. -Brian
Re: MSI: partially implement of AppSearch action
Hi Juan,
YAY! someone else doing action work.. However there are a few problems
i want to point out so you can review your code and check.
I have attached a patch i quickly made to avoid some problems i was
having. But what you will want to look over and figure out is
a) if the action returns anything other than ERROR_SUCCESS the install
will halt at that action returning that error. So you need to make sure
that you only return errors that should fully halt the install.
b) Watch out for null fields. load_dynamic_stringW will return a NULL
pointer for those but MSI_RecordGetInteger returns a special value.
oh and i fixed that looks like a copy and paste error.
-aric
Juan Lang wrote:
ChangeLog: partially implement AppSearch action
--Juan
Index: appsearch.c
===
RCS file: /cvstrees/crossover/office/wine/dlls/msi/appsearch.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 appsearch.c
--- appsearch.c 1 Feb 2005 14:29:10 - 1.1.1.1
+++ appsearch.c 2 Feb 2005 02:44:15 -
@@ -127,7 +127,7 @@
maxVersion = load_dynamic_stringW(row,4);
if (maxVersion)
{
-ACTION_VerStrToInteger(minVersion, sig-MaxVersionMS,
+ACTION_VerStrToInteger(maxVersion, sig-MaxVersionMS,
sig-MaxVersionLS);
HeapFree(GetProcessHeap(), 0, maxVersion);
}
@@ -610,6 +610,9 @@
}
else
rc = ERROR_OUTOFMEMORY;
+
+if (rc != ERROR_OUTOFMEMORY )
+rc = ERROR_SUCCESS;
return rc;
}
@@ -689,7 +692,10 @@
ERR(Error is %x\n,rc);
goto end;
}
-depth = MSI_RecordGetInteger(row,4);
+if (MSI_RecordIsNull(row,4))
+depth = 0;
+else
+depth = MSI_RecordGetInteger(row,4);
ACTION_ExpandAnyPath(package, buffer, expanded,
sizeof(expanded) / sizeof(expanded[0]));
if (sig-File)
Re: MSI: partially implement of AppSearch action
Hey Aric! --- Aric Stewart [EMAIL PROTECTED] wrote: a) if the action returns anything other than ERROR_SUCCESS the install will halt at that action returning that error. So you need to make sure that you only return errors that should fully halt the install. Ah, okay, you're right, most of these shouldn't halt the install. I'll take a closer look and fix these. b) Watch out for null fields. load_dynamic_stringW will return a NULL pointer for those but MSI_RecordGetInteger returns a special value. I missed that one, thanks for catching it. oh and i fixed that looks like a copy and paste error. Indeed. Thanks for reviewing. Go ahead and submit to wine-patches, I think your changes look good. I'll take a closer look at the return codes and make sure they're used appropriately. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Wine legalities
Jeremy, I agree - this is an exciting development. Microsoft's ability to spread FUD and their legal budget are enormous. We need this kind of expert help. Here's an area where I'd like an expert opinion. In the Winelib part of the Wine book, I'd like to include an example of converting a Microsoft VC++ 6.0 MFC application. This is Winelib's primary target, in my opinion. My question is: how far can I go? There are proprietary Microsoft header files that need to be included - does the Microsoft EULA allow disclosure of what these header files are? Or is it only legally safe to say something generic like figure out for yourself which header files you need to #include...? In general, I think Microsoft has to tread lightly on the issue of running Microsoft apps in Linux. Certainly, they're within their rights to hang up if a Linux/Winword user calls the help desk. But going after a company who legally pays for Winword licenses and runs Winword in Linux/Wine is another matter, bringing up the antitrust bogeyman again. Getting an expert legal opinion on this would be very useful. IMHO, even if Microsoft was legally on solid footing, it would be a huge PR disaster for them. Eventually, these issues will come to a head. Ira
Re: Wine legalities
Also on this topic came the subject of diff files. IIRC someone wanted to include them to help users make use of Microsoft headers that needed a bit of tweaking. Are diff files that are patches to Microsoft code legal to be distributed? They have bits of Microsoft code in them, but are they a derivative work? Thanks, Scott Ritchie On Tue, 2005-02-01 at 19:16 -0800, Ira Krakow wrote: Jeremy, I agree - this is an exciting development. Microsoft's ability to spread FUD and their legal budget are enormous. We need this kind of expert help. Here's an area where I'd like an expert opinion. In the Winelib part of the Wine book, I'd like to include an example of converting a Microsoft VC++ 6.0 MFC application. This is Winelib's primary target, in my opinion. My question is: how far can I go? There are proprietary Microsoft header files that need to be included - does the Microsoft EULA allow disclosure of what these header files are? Or is it only legally safe to say something generic like figure out for yourself which header files you need to #include...? In general, I think Microsoft has to tread lightly on the issue of running Microsoft apps in Linux. Certainly, they're within their rights to hang up if a Linux/Winword user calls the help desk. But going after a company who legally pays for Winword licenses and runs Winword in Linux/Wine is another matter, bringing up the antitrust bogeyman again. Getting an expert legal opinion on this would be very useful. IMHO, even if Microsoft was legally on solid footing, it would be a huge PR disaster for them. Eventually, these issues will come to a head. Ira
Re: Wine legalities
Ira Krakow wrote: Certainly, they're within their rights to hang up if a Linux/Winword user calls the help desk. But going after a company who legally pays for Winword licenses and runs Winword in Linux/Wine is another matter, bringing up the antitrust bogeyman again. I'm sure Microsoft would be more than happy to charge you $400/hr (or whatever their support rate is) to solve your problems running Microsoft Office on Windows 2000, Wine/Linux, or even MS-DOS 3.1 if you want. Just have your credit card details ready :) Mike
Re: Wine legalities
Mike wrote: I'm sure Microsoft would be more than happy to charge you $400/hr (or whatever their support rate is) to solve your problems running Microsoft Office on Windows 2000, Wine/Linux, or even MS-DOS 3.1 if you want. Just have your credit card details ready :) Heh. Yeah. In fact, I wouldn't be surprised if they're secretly a little supportive of Crossover (maybe less so for winehq): they _still_ get their Office revenue, but none of the support costs. If Linux ever got big enough on the desktop that they could make similar margins as they make on MacOS with Office, you can bet they'd make such a beast. But the support costs (for the desktop) are too high, and the revenue too low. The fact that you guys (codeweavers) can do it just shows a) you're not spending a small nation's GDP on marketing, and b) you're a whole lot smarter :) --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Wine legalities
Hi Jer, The ReactOS Project consulted a IP lawyer and came up with a draft policy statement. Maybe the two projects could work together on this. http://reactos.com:8080/archives/public/ros-general/2005-January/001402.html Thanks Steven __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
Re: [LOSTWAGES] screenshots
On Tue, 01 Feb 2005 22:13:02 +0100, Jonathan Ernst
[EMAIL PROTECTED] wrote:
Changelog:
- remove non-existant screenshots
- remove link to 404 Not Found page
Files changed:
- templates/en/screenshots.template
-tr valign=top align=center
- td width=33%
-{$im_6}br /
-span class=small{$ds_6}/span
- /td
- td width=34%
-{$im_7}br /
-span class=small{$ds_7}/span
- /td
- td width=33%
-{$im_8}br /
-span class=small{$ds_8}/span
- /td
-/tr
:-)
Thats not the way it works :)
There are 16 screen shots in toatle.. 9 are on the first page
correct? now go to more screen shots there are 6 on this page
humm 15 shots .. shot 10 is missing if you notice.
$im_ starts with 0 so there are 9 slots in toatle. You want to
remove three and that would leave 6 slots.
The first page would have 6 screen shots, second page would also have 6
shots but it would skip shot 7 so where on screen shot 13 now. Third page
would have 2 shots as it would skip a shot as well. Now you have 4 non-
existant screenshots...
What need to is make it work with 16 shots and not skip a shot...
To remove the 404 is correct ofcourse.
Tom
advapi32:registry.c tests failing
I noticed that advapi32:registry was failing on my windows xp machine 28 times, but succeeding in my wine regression test runs. I investigated what lines were causing failures and changed some the values so that the errors wouldn't exist on the windows test run. This now causes wine test runs to fail. I looked through test.winehq.org and found the following: Here it works (last time it worked) http://test.winehq.org/data/200411101000/ Here it fails 28 times (first time it looks like it failed) http://test.winehq.org/data/200411201000/ Here it also fails 28 times (most recent) http://test.winehq.org/data/200502011000/ I wanted to know if there was something I'm misunderstanding or missing. If not I'm going to change the registry.c tests to work on Windows XP and thus fail on Wine. Thanks for the information. Aaron
Re: Software Freedom Law Center
Brian Vincent wrote: On Tue, 01 Feb 2005 07:38:42 -0600, Jeremy White [EMAIL PROTECTED] wrote: I've been speaking privately with Eben Moglen about this new effort, and he tells me that they would like to have the Wine Project as one if their very first clients. I think this is an excellent idea. A little of my experience with lawyers. I fully trust Jeremy to know this, and know how to handle this. Still, it's something to keep in mind. Lawyers are hired to cover their asses. When you go out to consult with one, they are usually trained to do just one thing - alert you to the dangers of the actions you are about to take. Actually, at least in Israel, malpractice laws more or less require them to do so. It is therefor usually not beneficial to ask them questions that revolve around is there a risk in doing. Almost always the answer will be yes, there is. You usually want to know not whether there are risks, but what these risks are. A lawyer can sometimes help you with that, but more often then not can't. Your three ideas were great. I can also think of a few other things: 1) EULA enforcement. Are there areas where EULA's don't apply, is that information useful to us in any way, or is it information we want to publish? I can answer that one for you. Sometimes they are, sometimes they are not. I'm pretty sure I've read about precedences pointing both ways. For example - an EULA where the user has a chance to read it before making the actual transaction is more likely to bind. In my eyes, an EULA that comes way after you have already started using the product, such as with the Microsoft Updates site, cannot be binding (but that's just me). The question is therefor not whether EULAs apply, or whether any specific EULA applies. It's whether you are likely to get sued. 2) Along the same lines, I'm sure most MS EULA's have boilerplate that says, If any part of this EULA is unenforceable, it does not affect the other parts. Are there any parts of MS EULA's that aren't enforceable because they are a monopoly? What about redistribution rights? Can the core fonts be packaged? I can give you my answer to the last one. No, they cannot. You need to remember that Microsoft is likely not even the copyright owner. Also, fonts are typically protected by something called a design patent. We can gather some money (I think it's somewhere in the $50K area) and buy copyright and patent license for distributing them. It's been done with some Hebrew fonts and OpenOffice - you are allowed to give those proprietary fonts with OpenOffice, but only if it's a release sanctioned by Sun. I think the more important aspect here is a moral one - these is copyrighted work. We need to respect this copyright. -Brian Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
