Re: Misc FAQ improvements
On Mon, 2003-07-21 at 05:33, Tom wrote: Why not just : Windows programs (Windows 3.x and Win32 executables) on UNIX operating systems. Wine runs on BSD, Solaris, OSX as well. A lot of newbies especially aren't aware that Linux == UNIX, the distinction is subtle, especially if you installed it 5 hours ago. I saw a few people getting confused by that, so I thought I'd clarify it. The vast majority of people who use Wine and don't know what UNIX is, are Linux users (because they are new). So, it made sense to choose that as an example. should you note at one given time ? Hmm? I don't understand, sorry :( @@ -1142,7 +1161,7 @@ answer para Make sure you have all the VB runtime libraries installed. You may - need to use the native DLL vbrun60.dll + need to use the native DLL vbrun60.dll. You can get some from dll-files.com. some or them or just it if you only need the one dll ? Bad placement, I guess it should have been get some DLLs from
More Red Hat b0rkage?
I know Wine has some issues with some kernel security patches and memory regions. Can anybody confirm that this won't cause issues: The Red Hat Linux 9.0.93 kernel includes new Exec-shield functionality Exec-shield is a security-enhancing modification to the Linux kernel that makes large parts of programs including their stack not executable. This can reduce the potential damage of some security holes. Exec-shield is related to the older non-exec stack patch but has the potential to provide much greater protection. Exec-shield's behavior can be controlled via the proc file system. The command used is: echo value /proc/sys/kernel/exec-shield thanks -mike
Re: question about non-standard language IDs
My point is this: 1.these language IDs are in the WINE header files. They are not in the MingW or MS SDK header files. If you are building with WineLib and WineGCC and the Wine header files, then these IDs will be defined and it will work. But if you are building with MingW or MS SDK (e.g. building a dll or exe on windows for testing), it wont work because of compiler errors. Basicly, we add code that says if the resource compiler can find a definition for these non-standard (acording to the wine header files) language IDs, it will use them. If not, it wont pull in those header files. For someone building wine, they would get the resources. For someone building on Win32 with MingW, they wouldnt get the resources unless they added the definitions somewhere (AFAIK windows doesnt know about those language IDs or those languages anyway) IMO, any compiler claiming to compile win32 programs and providing header files and libraries for the win32 API should be defining WIN32, regardless of what executable format it spits out at the end. I have at least one piece of code that uses #ifdef WIN32 //win32 specific code including calls to win32 API #else //other code #endif
Re: Avoid problems with glibc's _res symbol
Isn't _res an internal function? If so, why is Wine using it?
On Mon, 2003-07-21 at 10:06, Mike McCormack wrote:
Newer versions of glibc don't exporting the _res symbol, but instead
replace it with a function call of a different name. This breaks binary
compatibility for code using _res compiled and linked with older
versions of glibc. (iphlpapi uses _res)
Mike
ChangeLog:
* dlopen libc to avoid problems with glibc's _res symbol, which only
defined in older glibc versions
__
Index: configure.ac
===
RCS file: /home/wine/wine/configure.ac,v
retrieving revision 1.166
diff -u -r1.166 configure.ac
--- configure.ac 16 Jul 2003 23:37:22 - 1.166
+++ configure.ac 21 Jul 2003 02:45:13 -
@@ -911,8 +911,8 @@
WINE_GET_SONAME(jack,jack_client_new)
WINE_GET_SONAME(ssl,SSL_library_init)
WINE_GET_SONAME(crypto,BIO_new_socket)
+ WINE_GET_SONAME(c, vsprintf)
fi
-
dnl Check for functions
Index: configure
===
RCS file: /home/wine/wine/configure,v
retrieving revision 1.441
diff -u -r1.441 configure
--- configure 16 Jul 2003 23:37:22 - 1.441
+++ configure 21 Jul 2003 02:45:21 -
@@ -2246,7 +2246,8 @@
echo $as_me:$LINENO: \$? = $ac_status 5
(exit $ac_status); }; }; then
for ac_declaration in \
- '' \
+ ''\
+ '#include stdlib.h' \
'extern C void std::exit (int) throw (); using std::exit;' \
'extern C void std::exit (int); using std::exit;' \
'extern C void exit (int) throw ();' \
@@ -2260,8 +2261,8 @@
cat confdefs.h conftest.$ac_ext
cat conftest.$ac_ext _ACEOF
/* end confdefs.h. */
-$ac_declaration
#include stdlib.h
+$ac_declaration
int
main ()
{
@@ -12977,8 +12978,72 @@
#define SONAME_LIBCRYPTO $ac_cv_lib_soname_crypto
_ACEOF
fi
-fi
+echo $as_me:$LINENO: checking for -lc soname 5
+echo $ECHO_N checking for -lc soname... $ECHO_C 6
+if test ${ac_cv_lib_soname_c+set} = set; then
+ echo $ECHO_N (cached) $ECHO_C 6
+else
+ ac_get_soname_save_LIBS=$LIBS
+LIBS=-lc $LIBS
+ cat conftest.$ac_ext _ACEOF
+#line $LINENO configure
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h conftest.$ac_ext
+cat conftest.$ac_ext _ACEOF
+/* end confdefs.h. */
+
+/* Override any gcc2 internal prototype to avoid an error. */
+#ifdef __cplusplus
+extern C
+#endif
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
+char vsprintf ();
+int
+main ()
+{
+vsprintf ();
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo $as_me:$LINENO: \$ac_link\) 5
+ (eval $ac_link) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }
+ { ac_try='test -s conftest$ac_exeext'
+ { (eval echo $as_me:$LINENO: \$ac_try\) 5
+ (eval $ac_try) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }; }; then
+ ac_cv_lib_soname_c=`$ac_cv_path_LDD conftest$ac_exeext | grep libc\\.so | sed
's/^[]*\([^ ]*\)[ ]*=.*$/\1/'`
+ if test x$ac_cv_lib_soname_c = x
+ then
+ ac_cv_lib_soname_c=libc.so
+ fi
+else
+ echo $as_me: failed program was: 5
+sed 's/^/| /' conftest.$ac_ext 5
+
+ac_cv_lib_soname_c=libc.so
+fi
+rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext
+ LIBS=$ac_get_soname_save_LIBS
+fi
+echo $as_me:$LINENO: result: $ac_cv_lib_soname_c 5
+echo ${ECHO_T}$ac_cv_lib_soname_c 6
+if test x$ac_cv_lib_soname_c != xNONE
+then
+cat confdefs.h _ACEOF
+#define SONAME_LIBC $ac_cv_lib_soname_c
+_ACEOF
+fi
+fi
# The Ultrix 4.2 mips builtin alloca declared by alloca.h only works
Index: include/config.h.in
===
RCS file: /home/wine/wine/include/config.h.in,v
retrieving revision 1.157
diff -u -r1.157 config.h.in
--- include/config.h.in 20 Jun 2003 23:26:56 - 1.157
+++ include/config.h.in 21 Jul 2003 02:45:22 -
@@ -53,6 +53,9 @@
/* Define to 1 if you have the cups/cups.h header file. */
#undef HAVE_CUPS_CUPS_H
+/* Define to the soname of the C library. */
+#undef SONAME_LIBC
+
/* Define to 1 if you have the curses.h header file. */
#undef HAVE_CURSES_H
Index: dlls/iphlpapi/Makefile.in
===
RCS file: /home/wine/wine/dlls/iphlpapi/Makefile.in,v
retrieving revision 1.1
diff -u -r1.1 Makefile.in
--- dlls/iphlpapi/Makefile.in 13 May 2003 03:32:20 - 1.1
+++ dlls/iphlpapi/Makefile.in 21 Jul 2003 02:45:22 -
@@ -7,6 +7,7 @@
LDDLLFLAGS = @LDDLLFLAGS@
SYMBOLFILE = $(MODULE).tmp.o
+EXTRALIBS = @DLLIBS@
C_SRCS = \
ifenum.c \
Index:
Re: Typelib marshalling BSTRs
On Sun, 2003-07-20 at 12:29, Ove Kaaven wrote: IDispatch should not be marshalled by the typelib marshaller, the method arguments it use cannot be represented by a typelib, as you've seen. The MIDL code in oaidl_p.c must be used instead. You need to change the registry to use the right marshaller, I think the necessary winedefault.reg changes were included in my patch, but I'm not sure. I'd just like to double check that it *is* actually possible to marshal IDispatch, right? I've got it using the marshallers in oaidl_p.c, but I get fixmes from the RPC runtime like so: fixme:ole:NdrConvert (pStubMsg == ^0x4d7a27a4, pFormat == ^0x53bc5f84): stub. fixme:ole:PointerUnmarshall unhandled ptr type=12 and so on. Eventually it crashes inside native code (i think) just after returning from the proxy (well, i can see the last call to NdrComplexArrayUnmarshall) and calling VariantInit. Are those fixmes actually critical? The NdrConvert stub at least suggests that it might be, and that it should throw an exception. any insights welcome, thanks -mike
Re: Misc FAQ improvements
should you note at one given time ? Hmm? I don't understand, sorry :( :) My bad ..I read over it fast and was thinking you ment # or workers at any one given time when you ment the toatle. As they had all 5000 at once and wine has had 550 over a ten year span. Tom
Debugging with native DLLs
I'm trying to see which OLE calls a program makes under WINE when using oleaut32 natively. Obviously this native DLL doesn't have any debugging information. wine --debugmsg +ole app.exe doesn't seem to show the calls made to oleaut32. Is there are way I can get this information?
Re: Debugging with native DLLs
E == E Lea [EMAIL PROTECTED] writes: E I'm trying to see which OLE calls a program makes under WINE when E using oleaut32 natively. Obviously this native DLL doesn't have any E debugging information. E wine --debugmsg +ole app.exe doesn't seem to show the calls made to E oleaut32. Is there are way I can get this information? The only debugging avaliable for native DLLs is --debugmsg +snoop. If the call to the native function doesn't go through the normal import mechanisme ( what I expect for the OLE functionality), this probably won't help. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Mach-O Support in WineLib Loader
Out of curiousity, how do you get around the linkage requirements of Mach-O, ie the fact that you can't both dlopen and runtime link to the same module? On Mon, 2003-07-21 at 13:08, Pierre d'Herbemont wrote: Hi! This patch enables Mach-O (Darwin linker file format) support in WineLib. Thanks, Pierre ModifiedFiles: - loader/module.c ChangeLog: - Add Mach-O (Darwin file format) support.
which of these should I work on?
After looking at all the things windows provides, I have identified the folowing possible programs that I could write for the wine project. Some of them are usefull for WINE itself and some of them might be usefull for (for example) ReactOS Things: 1.improve comdlg32.dll, implement stuff added in WINVER=0x500 like PrintDlgEx and generally make comdlg32.dll behave more like the windows counterpart (implement a few other things as well, like some of the currently stubbed out items). 2.work on wine notepad. Wont do this until the changes refered to before are merged. 3.write a clone of fontview.exe (windows font sample viewer). This is probobly not usefull for WINE but might be usefull for ReactOS, plus it would be a good excercise in windows GDI programming. 4.write clones of guidgen.exe and/or uuidgen.exe, 2 different windows SDK tools for generating GUIDs/UUIDs. (if we are providing an IDL compiler and other such OLE-esque things, having a GUID/UUID generator is probobly a good thing to have, mainly it is just a stub around a call to CoCreateGUID 5.write a clone of rebase.exe, a win32 PE image rebasing tool. Probobly not usefull to WINE but might be helpfull for ReactOS development, dont know. 6.writing a clone of the cards.dll used by the windows card games. Only problem here is that I would need to find a sutably licenced set of card images since I dont have the skills to draw them myself :) 7.writing a clone of the card games (solitare,freecell etc) included with windows to use said cards.dll (hey, we have WineMine...) 8.writing a character map applet (basicly a clone of charmap.exe). Dont know if WINE needs this but ReactOS probobly does (how else are you going to insert all those fancy foreign language characters and dingbats? :) 9.writing a calculaor app (i.e. a calc.exe clone), again dont know if WINE needs one but ReactOS might... and 10.writing a clone of the Win32 volume control applet. Dont think WINE needs this (since the linux sound API has one already) but ReactOS might... Which of these should I work on? Which of these are usefull to Wine/ReactOS? Are any of these considered a big beast (as richedit was refered to by Dimitrie O. Paun?)
Re: which of these should I work on?
On Mon, 21 Jul 2003, Jonathan Wilson wrote: 6.writing a clone of the cards.dll used by the windows card games. Only problem here is that I would need to find a sutably licenced set of card images since I dont have the skills to draw them myself :) 7.writing a clone of the card games (solitare,freecell etc) included with windows to use said cards.dll (hey, we have WineMine...) recently on happypenguin.org: http://www.nongnu.org/cardpics/cardpics.en.html cu
Re: which of these should I work on?
On Mon, 21 Jul 2003, Jonathan Wilson wrote: [...] 1.improve comdlg32.dll, implement stuff added in WINVER=0x500 like PrintDlgEx and generally make comdlg32.dll behave more like the windows counterpart (implement a few other things as well, like some of the currently stubbed out items). This can certainly be useful. 2.work on wine notepad. Wont do this until the changes refered to before are merged. Notepad is sometimes invoked by installers to show readmes, release notes, etc. So improving it can be useful. Adding Unicode support (or does it already support it) would certainly be useful. 3.write a clone of fontview.exe (windows font sample viewer). This is probobly not usefull for WINE but might be usefull for ReactOS, plus it would be a good excercise in windows GDI programming. Can we find a free (as in beer)/open-source Windows application that does that already? If the answer is yes (especially to the open-source part), then there's no point to develop a new one. Maybe Freshmeat would help here. 4.write clones of guidgen.exe and/or uuidgen.exe, 2 different windows SDK tools for generating GUIDs/UUIDs. (if we are providing an IDL compiler and other such OLE-esque things, having a GUID/UUID generator is probobly a good thing to have, mainly it is just a stub around a call to CoCreateGUID Seems like it could be useful and easy. So it seems like a good starting point. 5.write a clone of rebase.exe, a win32 PE image rebasing tool. Probobly not usefull to WINE but might be helpfull for ReactOS development, dont know. Don't know. 6.writing a clone of the cards.dll used by the windows card games. Only problem here is that I would need to find a sutably licenced set of card images since I dont have the skills to draw them myself :) 7.writing a clone of the card games (solitare,freecell etc) included with windows to use said cards.dll (hey, we have WineMine...) I'm pretty sure there are lots of free (beer) or open-source card games out there. IMHO, even just the existence of tons of free beer card games greatly diminish the need for reimplementing yet another one. But then I'm not a card game fan. 8.writing a character map applet (basicly a clone of charmap.exe). Dont know if WINE needs this but ReactOS probobly does (how else are you going to insert all those fancy foreign language characters and dingbats? :) 9.writing a calculaor app (i.e. a calc.exe clone), again dont know if WINE needs one but ReactOS might... Again, don't we already have free (beer)/open-source ones? -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Re: Mach-O Support in WineLib Loader
On lundi, juil 21, 2003, at 14:38 Europe/Paris, Mike Hearn wrote: Out of curiousity, how do you get around the linkage requirements of Mach-O, ie the fact that you can't both dlopen and runtime link to the same module? Yeah that's a good point ;) ntdll which is runtime link in the current build process, is not when building for Mac OS X. It is built as a bundle and is dlopened by libwine with the RTLD_GLOBAL flag added. Pierre
Re: which of these should I work on?
--- Jonathan Wilson [EMAIL PROTECTED] wrote: After looking at all the things windows provides, I have identified the folowing possible programs that I could write for the wine project. Some of them are usefull for WINE itself and some of them might be usefull for (for example) ReactOS Things: 1.improve comdlg32.dll, implement stuff added in WINVER=0x500 like PrintDlgEx and generally make comdlg32.dll behave more like the windows counterpart (implement a few other things as well, like some of the currently stubbed out items). You could really help me out by working on comdlg32. I have been working on spliting the Win16/32 code from this dll for a while now so ReactOS can use it. Take a look at it and ole32 to see how we split Win16/32 code. 9.writing a calculaor app (i.e. a calc.exe clone), again dont know if WINE needs one but ReactOS might... ReactOS has a calc.exe clone in the rosapps CVS tree that needs work. Which of these should I work on? Which of these are usefull to Wine/ReactOS? Are any of these considered a big beast (as richedit was refered to by Dimitrie O. Paun?) If you want a quick one to help on you could implement delay loading of user32.dll in regedit. We implemented a GUI front end for WINEs regedit in ReactOS but it is not merged in to winehq because Alexandre doesnt want it to call user32 and the GUI by default. We have regedit scripts that use the comandline in WINE and there is no point in neededing to invoke the GUI. http://www.winehq.org/hypermail/wine-patches/2003/06/0040.html Here is the patch that merges the GUI frontend. Thanks Steven __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: Question about WINE and adding the low-level CD access APIs...
Mike Hearn wrote: I don't know much about SecureRom other than that some Blizzard games use it. (and others) So, there we go. I expect it would not be all that hard to make Wine work with SecuRom at least, you just need to make the mapping between MSCDEX and the Linux low level CD routines. Unfortunately SafeDisc is a lot more popular, it seems. All, I posted the following in response to a similar question about a month ago and have received a few individual emails from people saying it worked for them, too. The short version is that in NT mode, some of these must use a different mechanism that Wine already supports. Cheers, -ajp Re: Warcraft 3 Issues (RedHat 9) Date: Mon Jun 09 2003 - 11:22:52 CDT Ann and Jason Edmeades wrote: Hiya, Firstly I can only talk about wine, not winex as I really dont have a clue about that. fixme:file:SetFileAttributesW (LC:\\WINDOWS\\SYSTEM\\SIntf16.dll):100 attribute(s) not implemented. fixme:file:SetFileAttributesW (LC:\\WINDOWS\\SYSTEM\\SIntf32.dll):100 attribute(s) not implemented. fixme:file:SetFileAttributesW (LC:\\WINDOWS\\SYSTEM\\SIntfNT.dll):100 attribute(s) not implemented. This is copy protection. Wine does not support this form of copy protection yet, so you need to find a nocd patch. Actually, I have observed this working (without using a patch) for quite a long time as long as: 1) The Windows version is set to one of the NT ones 2) The ide-scsi option is NOT included when booting 3) The authentic CD-ROM is in the drive Sometimes it hangs up after printing those three lines above, but killing the wine process and restarting it generally fixes it. Normally, there is a (longish) pause and a lot of CD-ROM activity after those lines are printed before the game screen comes up. If I have ide-scsi turned on, it just keeps accessing the CD-ROM until I kill the process. I just tried the very latest from CVS and it crashed inside winmm.c until I disabled sound, but as it used to work perfectly (with -opengl anyway) I will go and find the update that broke that. Cheers, -ajp
Re: which of these should I work on?
Hi 6.writing a clone of the cards.dll used by the windows card games. (...) Yet another link for free cards :) http://www.jfitz.com/cards/index.html 9.writing a calculaor app (i.e. a calc.exe clone), again dont know if WINE needs one but ReactOS might... calc.exe that comes with M$ windows works well with Wine. Why should it be rewrited ? Stephan
Re: Typelib marshalling BSTRs
man, 21.07.2003 kl. 17.31 skrev Mike Hearn: On Mon, 2003-07-21 at 12:55, Ove Kaaven wrote: fixme:ole:PointerUnmarshall unhandled ptr type=12 This means that null pointers may not be handled properly (but non-null pointers will still work). However, I have yet to see a situation where I needed to handle it, but then again I've only worked on InstallShield. I suppose it's possible that you need to if you're working on something else (but I don't think IDispatch is an interface where you need to worry about it). IDispatch::Invoke has an riid parameter, that the docs say is reserved and must be IID_NULL. In the current custom marshallers, trace statements reveal that the stub receives this as NULL, not IID_NULL. Are they equivalent in this context, or is that being marshalled incorrectly? Not exactly equivalent here. The ptr type is not 0x12 here, I think; supplying NULL here is completely invalid and the MIDL code in oaidl_p.c will raise an exception, completely refusing to marshal the call at all. If supplying NULL is supposed to be valid at the API level, it must be handled by the IDispatch_Invoke_Proxy wrapper in usrmarshal.c, converting the NULL to IID_NULL, before passing it off to the MIDL-generated marshaller. (This Invoke wrapper already treats some other can-be-NULL arguments in this manner, so this would just be yet another case of this.) You probably just need to marshal an extra flag saying whether the pointer is null or not, but since I haven't seen the DCE RPC spec I don't know what the flag should look like. Is that just a case of adding another IStream::Write call, and having the equivalent read in the custom demarshaller? That would probably work, except that MIDL-based marshallers and rpcrt4 don't use IStream... Hmm. It could still be in Wine code, since NdrComplexArrayUnmarshall might be trying to unmarshal an array of variants, which is a custom type. The custom-marshalling code for variants is in dlls/oleaut32/usrmarshal.c, and there is a VariantInit in the VARIANT_UserUnmarshal function in there (though it probably shouldn't have shown up in a relay trace). I found that it's in IDispatch_Invoke_Stub - it calls IDispatch::Invoke on the actual object and crashes, in native shdocvw code. So, I guess the inputs its given there are incorrect somehow. I'll look into it some more. OK.
Re: More Red Hat b0rkage?
Mike Hearn [EMAIL PROTECTED] writes: I know Wine has some issues with some kernel security patches and memory regions. Can anybody confirm that this won't cause issues: It will, but there's a 'chstk' tool (that hopefully RedHat is shipping along with their kernel) that lets you set a flag in the Wine binary to make it go back to normal stack behavior. -- Alexandre Julliard [EMAIL PROTECTED]
Re: which of these should I work on?
On Mon, 21 Jul 2003, BiGgUn wrote: 9.writing a calculaor app (i.e. a calc.exe clone), again dont know if WINE needs one but ReactOS might... calc.exe that comes with M$ windows works well with Wine. Why should it be rewrited ? A lot of other MS DLLs work just fine with Wine, why would we rewrite those? -- Dimi.
Re: update Re: My wine turned to vinegar... vanilla wine isn'tbroken, is it?
On 20 Jul 2003, Mike Hearn wrote: I'm also having unrelated issues since I ran a cvs update *grr*, I can no longer click on anything, nor use the keyboard. The mouse cursor doesn't change when I move the mouse over it, and an x11drv trace shows it processing no events *at all* given input. I hope this isn't actually CVS that's borked for everybody, but I can't really see what might have broken it :( hi, Mike i was lucky enough to get into such situation, once: http://www.winehq.org/hypermail/wine-devel/2003/07/0229.html as no-one have responded to this, i decided to do: su -c make uninstall; make clean; tools/wineinstall this helped :) hence, the question arises: why is it bad to just do make uninstall, cvs update and tools/wineinstall after, sometimes? BTW: sometimes i am forgetting to kill all wine processes, so wine (with any combination of cmd-line) just outputs 0 bytes and quits. maybe that is a indication of a problem. should wineinstaller kill running wines before overwriting old executable file(s) or even before doing some checks?
Re: update Re: My wine turned to vinegar... vanilla wine isn'tbroken, is it?
On Mon, 21 Jul 2003, Saulius Krasuckas wrote: BTW: sometimes i am forgetting to kill all wine processes, so wine (with any combination of cmd-line) just outputs 0 bytes and quits. maybe that is a indication of a problem. should wineinstaller kill running wines before overwriting old executable file(s) or even before doing some checks? i did mean to kill all wine processes during wineinstalling :-/
Re: which of these should I work on?
On Mon, 2003-07-21 at 15:30, Dimitrie O. Paun wrote: On Mon, 21 Jul 2003, BiGgUn wrote: 9.writing a calculaor app (i.e. a calc.exe clone), again dont know if WINE needs one but ReactOS might... calc.exe that comes with M$ windows works well with Wine. Why should it be rewrited ? A lot of other MS DLLs work just fine with Wine, why would we rewrite those? Hmm, well because we need to rewrite DLLs in order to run applications. I've yet to see an app that needs calc.exe .. but I think we've been round this one before dimi ;)
Re: Avoid problems with glibc's _res symbol
Hi Mike, No, unfortunately it's supposed to be a well known global symbol. It's even mentioned in the manual page for resolver(3). Mike RESOLVER(3) Linux Programmer's Manual RESOLVER(3) NAME res_init,res_query,res_search,res_querydomain, res_mkquery, res_send, dn_comp, dn_expand - resolver rou- tines SYNOPSIS #include netinet/in.h #include arpa/nameser.h #include resolv.h extern struct state _res; Mike Hearn wrote: Isn't _res an internal function? If so, why is Wine using it?
Re: PATCH: shlwapi
Marcus Meissner [EMAIL PROTECTED] writes: Changelog: Numbers without prefix are int (32bit signed). If you want long long (64bit signed), append LL. LL is not portable, this needs to be done with casts. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Avoid problems with glibc's _res symbol
Mike McCormack said: Hi Mike, No, unfortunately it's supposed to be a well known global symbol. It's even mentioned in the manual page for resolver(3). So is errno, but that doesn't exist either, but get's #defined to __get_errno_loc() (or something). _res turns to _res_state() I think. PS. This breaks netscape-4.7?? on nptl + glibc as it uses _res Stefan
Re: Avoid problems with glibc's _res symbol
On Mon, 2003-07-21 at 17:06, Stefan Jones wrote: PS. This breaks netscape-4.7?? on nptl + glib as it uses _res I'm going to investigate this further. The _res symbol is still available in the glibc binaries, and they have a policy of only versioning symbols, not breaking them. I feel there is more to this than meets the eye, although it's possible the glibc guys screwed up.
Re: wine/programs/notepad rsrc.rc main.h main.c di ...
--- wine/programs/notepad/rsrc.rc:1.8 Mon Jul 21 20:38:52 2003
+++ wine/programs/notepad/rsrc.rc Mon Jul 21 20:38:52 2003
@@ -24,6 +24,20 @@
#include commctrl.h
#include notepad_res.h
+ID_ACCEL ACCELERATORS
+{
+^A, CMD_SELECT_ALL
+^C, CMD_COPY
+^F, CMD_SEARCH
+^O, CMD_OPEN
+^S, CMD_SAVE
+^V, CMD_PASTE
+^X, CMD_CUT
+^Z, CMD_UNDO
+VK_F3, CMD_SEARCH_NEXT, VIRTKEY
+VK_F5, CMD_TIME_DATE, VIRTKEY
+}
+
#include Da.rc
#include De.rc
#include En.rc
What's the sense in making the accelerators global to all languages?
Each language has it's own accelerator keys (just as it has it's own menus).
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page resume - http://www.shemesh.biz/
Re: [resend] Ensure ole32.dll gets correct version number
Mike Hearn [EMAIL PROTECTED] writes: diff -u -r1.1 version.rc --- dlls/ole32/version.rc 28 Mar 2003 19:33:04 - 1.1 +++ dlls/ole32/version.rc 13 Jul 2003 13:09:17 - @@ -21,4 +21,8 @@ #define WINE_OLESELFREGISTER #define WINE_FILENAME_STR ole32.dll +#define WINE_FILEVERSION_STR 2.0 +#define WINE_FILEVERSION 2,0,0,0 + #include wine/wine_common_ver.rc Version 2.0 is awfully old for ole32.dll. Why do you need that? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Once again: Wine without X?
On Sat, 19 Jul 2003 07:00, Todd Vierling wrote: Yes, that would be very wonderful to see someday. It'd be nice to be able to run Win32 command line apps once in a while without $DISPLAY set (7-zip comes to mind), but without having to hack config back and forth. A work-around is to use Xvfb as the X server.
Re: which of these should I work on?
--- Mike Hearn [EMAIL PROTECTED] wrote: On Mon, 2003-07-21 at 15:30, Dimitrie O. Paun wrote: On Mon, 21 Jul 2003, BiGgUn wrote: 9.writing a calculaor app (i.e. a calc.exe clone), again dont know if WINE needs one but ReactOS might... calc.exe that comes with M$ windows works well with Wine. Why should it be rewrited ? A lot of other MS DLLs work just fine with Wine, why would we rewrite those? Hmm, well because we need to rewrite DLLs in order to run applications. I've yet to see an app that needs calc.exe .. but I think we've been round this one before dimi ;) I have yet to see an app that needs winmine.exe but yet we still have the clone of it. It would be an interesting project for anyone who wants to get familiar with wine programming and patch submitting, and plus that way people that dont have windows and dont want to snake calc.exe from someone else's windows dont have to.. Just my 2¢ = -- Dustin Navea Minor Contributor, winehq.com Buzilla Janitor, bugs.winehq.com Network Admin, irc.blynk.net (down) __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Sync (29): msvcrt cpp
Jon Griffiths [EMAIL PROTECTED] writes: +dlls/msvcrt/cpp.c Use exception as the base for all exception derived classes. Implement type_info methods correctly. Add static RTTI for exported objects. Throw exceptions when run time casts fail. Why did you remove all the structure definitions for the derived classes? I think it's much clearer to have a separate C type for each class instead of having everything be an exception object. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Once again: Wine without X?
On Tue, 22 Jul 2003, Troy Rollo wrote: : Yes, that would be very wonderful to see someday. It'd be nice to be able : to run Win32 command line apps once in a while without $DISPLAY set (7-zip : comes to mind), but without having to hack config back and forth. : : A work-around is to use Xvfb as the X server. That's so bloated, that it's like working around a family feud by bombing the other family out of existence. But since my last name isn't Bush, I don't think that's very useful. 8-P -- -- Todd Vierling [EMAIL PROTECTED]
how do you do console apps?
How would one do an app as a WineLib app (much like how notepad etc are) but that is a console app? Is there an example somewhere in the wine tree of how to do a console app (with main() instead of winmain() and that uses stdio.h to do output to stdout and etc?)
I now know what I am going to work on
After all the feedback, I have decided to work on 4 things: 1.a fontview.exe clone (should give me good experiance in working with the GDI font APIs and also should give the WINE implementations of those APIs a workout. In particular, the functionality used to display a font even though its not registered with the system font lists should be a nice thing to hack on and figure out how its done. Plus, ReactOS can use the results. 2.a guidgen.exe clone (the origonal uses MFC, mine wont obviously) 3.a uuidgen.exe clone (usefull as a way to generate GUIDs/UUIDs from a script or makefile) and 4.a cards.dll clone. Its not only used by the MS card games but others as well. Its been reverse engineered by some people and also at some point MS released an official SDK for it (at http://www.microsoft.com/mind/0396/games.asp ) so if we dont clone it, people cant play non-ms games that use it :)
Re: Progress bar painting fix
OK, here are two screenshots. Both are produced while installing Dreamweaver MX. The number in the progress bar should be updated with every increment. Without the fix, it is only updated at 10%. I'd prefer to go with something that is draws correctly, but causes a little flicker, than go with something that is clearly incorrect, yet causes less flicker. Feel free to search for a better fix. Mike Dimitrie O. Paun wrote: You mean, there is a number written in the progress bar by the app? And if so, that does not get updated, correct? Hmmm... Can you please take a few minutes to explain what the problem is and why this is the only fix possible? inline: dw-1.pnginline: dw-2.png
Re: wine/programs/notepad rsrc.rc main.h main.c di ...
Shachar Shemesh [EMAIL PROTECTED] wrote: What's the sense in making the accelerators global to all languages? Each language has it's own accelerator keys (just as it has it's own menus). I thought that it's better to have them global, until we have them defined for other languages. -- Dmitry.
I am going to implement cards.dll
As I said in my other message Its not only used by the MS card games but others as well. Its been reverse engineered by some people and also at some point MS released an official SDK for it (at http://www.microsoft.com/mind/0396/games.asp ) so if we dont clone it, people cant play non-ms games that use it However, there is a problem. Microsoft released a 16 bit version of cards.dll. Later on, they relased a new 32 bit version, also called cards.dll. Some games support the 16 bit version via thunks, some support the 32 bit version and some games try and detect both. Firstly, is there some way I can implement cards.dll so that it presents the 16 bit interface to those apps that use the 16 bit thunks to talk to it and also so it presents the 32 bit interface to those apps that talk to it as a 32 bit dll? Also, I am trying to catalog all the different versions of cards.dll that are out there. (in an attempt to catalog all the differences) I personally have: 1.cards.dll from Windows XP, size 359,936 version 5.1.2600.0. This one is a 32 bit version. 2.cards.dll from Win2k, size 153,360 version 5.0.2134.1. This one is a 32 bit version. 3.cards32.dll from the microsoft article linked to above, size 152,064, no versioninfo resource. This one is a 32 bit version. 4.cards.dll from win98, size 148,528, no versioninfo. This one is a 16 bit version. Does anyone have any other versions, especially other 16 bit versions? BTW, I am going to use the cards from http://www.jfitz.com/cards/index.html. As for the backs, anyone want to draw some? :)
Re: System tray integration take 5
Mike Hearn [EMAIL PROTECTED] writes: +#define MAX_TRAY_ICONS 256 +int undockedTrayIconsCount = 0; +static HWND undockedTrayIcons[MAX_TRAY_ICONS]; /* stores HWNDs of undocked tray windows when a + NETWM tray window appears, we can dock */ You shouldn't use a global array here. This is not thread safe, plus you'd need to keep track of window destruction to remove them from the array. The right way IMO would be to walk the window tree checking for WS_EX_TRAYWINDOW at the time a tray window appears. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Mach-O Support in WineLib Loader (2) dlopen
Pierre d'Herbemont [EMAIL PROTECTED] writes: This patch provides Mach-O support in WineLib. As Mach-O doesn't have init and fini section, it adds support for it in dlopen. A new file mach-o.c is created. It contains functions which add support for init, and fini section. Isn't there any way to have an init function? How does Mach-O support C++ constructors? -- Alexandre Julliard [EMAIL PROTECTED]
Re: how do you do console apps?
Le lun 21/07/2003 à 22:05, Jonathan Wilson a écrit : How would one do an app as a WineLib app (much like how notepad etc are) but that is a console app? Is there an example somewhere in the wine tree of how to do a console app (with main() instead of winmain() and that uses stdio.h to do output to stdout and etc?) The differences are very few: in Makefile.in, use APPMODE=cui instead of APPMODE=gui, and you should be set. If you want to look at a complete Makefile.in, programs/expand should start you in the right direction. Vincent
