August 2003 - Wine-Devel - list.winehq.org

Re: wcmd patch
by Eric Pouech Aug. 22, 2003

Aug. 22, 2003

Oleg Prokhorov wrote: > Hello wine-patches, > > Changelog: > Fixes two problems: > GPF when no extension was specified. > No handles were inherited in CreateProcess, all child console programs were silent > the second part is wrong. a child process should inherit its parent input/output stream even if we don't inherit all the handles. But the bug still exist as of today. I'll look into it. A+ -- Eric Pouech

1 1

About spam
by Sylvain Petreolle Aug. 22, 2003

Aug. 22, 2003

I have an evidence that some robots can grab our email adress, even with our mangling process on winehq. I used my work adress only onto wine-devel and got spammed last week. ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 alias upsf='false ; while [ $? -ne 0 ] ; do cvs update -APd ; done 2>&1 |tee cvslog' "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 2

Work on building comctl32 with MS_VC and MS_VC headers
by Steven Edwards Aug. 22, 2003

Aug. 22, 2003

I have made a log of my attempts to fix comctl32.dll with the MS_VC headers but I am going to have to call it a day. If anyone has time and a copy of MS_VC can you take a look and tell me whats going on? The log of my progress is here: http://mail.gleneagle.net/sedwards/comctl32_msvc.txt It may just be something as simple as WINE having most of the headers included in the wrong order or included in places where they shouldnt be such as stdarg in winbase.h and a lack of winbase.h. Thanks Steven

2 1

New infected email
by puoti＠inwind.it Aug. 22, 2003

Aug. 22, 2003

This sould go too. http://www.winehq.org/hypermail/wine-patches/2003/08/0224.html

2 1

Re: Viruses in the wine-devel archive ??
by puoti＠inwind.it Aug. 22, 2003

Aug. 22, 2003

Who says he is infected?I've got some messages from emial servers saying that I've sent infected emails, but I know that I aren't infected because I only use webmail and only on linux,my mail server is a mixed linux/solaris, so probably a robot finds emial addresses and sends infected emails from a mail server with a fake origin email address.

1 0

Virus Alert - Please scan your Windows boxes
by Jeremy Newman Aug. 22, 2003

Aug. 22, 2003

We've gotten a few viruses sent out to the mailing lists in the last few weeks. This is a friendly reminder to please scan your Windows boxes (since, I know some of you use them for email, shame on you!). There is a FREE virus scanner out there that removes these any many other worms. get it here: http://www.avast.com/ note: for some reason their download pages 404, they did work last night, so I assume they took them down due to load. They should be back up soon. If someone knows of a mirror please let us know. -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

2 1

Re: Problems building dlls for use with winelib (was: spec file syntax and automated generation)
by Dimitrie O. Paun Aug. 22, 2003

Aug. 22, 2003

On August 22, 2003 07:19 am, Martin Tröster wrote: > 1. Build all object files with winegcc/wineg++ and the following flags: > > -W -g -O0 -I/ -I/usr/include/wine -D_DEBUG -DWIN32 -D_WINDOWS > > -DNOARRAYMACROS -DBUILD_DLL -fPIC It's a nit, but you don't need -I/usr/include/wine and -DWIN32, these are added automatically by winegcc. Also, what's up with -I/ ??? > 2. relocate symbols (took this one from the makefile of advapi32.dll): > > ld -r $(OBJS) -o libdll.tmp.so && strip --strip-unneeded libdll.tmp.so Good. From the ld man page (about -r): "... When linking C++ programs, this option will not resolve references to constructors; to do that, use -Ur." Is your app C++? > 3. build spec file with the previously generated temporary library, the > imported libraries from winelib and with a spec-file containing the > functions to be exported from the dll and compile it (omitted here) > > with the same flags as used above for the original source files: > > winebuild -fPIC -L/usr/local/lib/wine -lntdll -lkernel32 -luser32 > > -lgdi32-lcomdlg32 -lcrtdll -o libdll.spec.c --spec libdll.spec > > libdll.temp.o Looks fine. > Finally, I (at least try to) tie everything together in a single > > library: > > winegcc -shared -Wl,-soname,libdll.so -DSTRICT -D_REENTRANT > > -L/usr/local/lib/wine -lntdll -lkernel32 -luser32 -lgdi32 -lcomdlg32 > > -lstdc++ -lcrtdll -lgcc_s -lm $(OBJS) Hey, winegcc does not support -shared just yet. Just simulate this line using just gcc, as we do in the tree. > You see, I am a little bit desperate about this thing, having come > pretty far, but now seeming to fail on the last meters. So any help (on > this list or if you think it's too specific to my private mail) would be > really, really appreciated. If I find some time, I will volunteer to > write a short step-by-step guide based on my observations, if this is > any help for you to avoid dumb questions like these ;-) Yes, that will be very helpful, if only to show where we need to fix our tools :) > (1) winegcc -W -g -O0 -I/usr/include/wine -fPIC -o testlib.o -c > testlib.c > (2) ld -r testlib.o -o libtest.dll.temp.o > (3) strip --strip-unneeded libtest.dll.temp.o > (4) winebuild -fPIC -o testlib.spec.c --spec testlib.spec > libtest.dll.temp.o winegcc -W -g -O0 -I/usr/include/wine > -o testlib.spec.o -c testlib.spec.c > (5) gcc -shared -Wl,-Bsymbolic,-z,defs > testlib.o testlib.spec.o -o libtest.dll.so (5) is missing the libs, no? The rule from the tree is: $(MODULE).so: $(MAINSPEC).o $(ALL_OBJS) Makefile.in $(LDSHARED) $(LDDLLFLAGS) $(MAINSPEC).o $(ALL_OBJS) -o $@ -L$(DLLDIR) $(LDIMPORTS:%=-l%) $(ALL_LIBS) -lc where ALL_LIBS is: ALL_LIBS = $(LIBWINE) $(EXTRALIBS) $(LIBPORT) $(LDFLAGS) $(LIBS) So I guess at a minimum you need to add: -L/usr/local/lib -lwine -lm -lc But to be on the safe side, add: -lwine -lwine_port -lwine_unicode -lwine_uuid -lm -lc plus all the imports! -- Dimi.

1 0

RE: Int21 : Dont reset systematically CFLAG
by PETREOLLE Sylvain Aug. 22, 2003

Aug. 22, 2003

Doing some research in int21.c shows that many functions that rely on CFLAG dont set it when they are in error state. IMHO many DOS programs are already broken today since these functions appear to be successfull at every moment. For example : INT21_FileDateTime (handler for function 0x57, file attributes) -----Message d'origine----- De : Jukka Heinonen [mailto:jhei(a)iki.fi] Envoyé : lundi 18 août 2003 20:14 À : wine-devel(a)winehq.com Objet : Re: Int21 : Dont reset systematically CFLAG Sylvain Petreolle wrote: > Dont reset systematically CFLAG when calling the int 21 handler. > Some functions dont change it. This patch must not be applied because it is highly likely that it will break almost all DOS programs. Fix itself is correct but before this patch can be applied it must be made sure that all functions that are supposed to reset CFLAG really reset it. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

Re: PATCH - winnt.h move non-standard language IDs to wine/port.h
by Dmitry Timoshkov Aug. 22, 2003

Aug. 22, 2003

"Steven Edwards" <Steven_Ed4153(a)yahoo.com> wrote: > -#define LANG_DIVEHI 0x65 > -#define LANG_GALICIAN 0x56 > -#define LANG_KYRGYZ 0x40 > -#define LANG_MONGOLIAN 0x50 > -#define LANG_SYRIAC 0x5a The above defines present in winnt.h from the Platform SDK. You have to update MinGW headers, not to remove those defines from Wine headers. -- Dmitry.

2 1

export variables in dlls
by flyker Aug. 22, 2003

Aug. 22, 2003

example: ------------------------------------------------- main.cpp #include <stdio.h> #include <windows.h> extern "C" __declspec(dllimport) void xxx(char *str, ...); extern "C" __declspec(dllimport) char *zzz; int WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR szCmdLine, int) { xxx("blahblah\n", 1, 2, 3); printf(zzz); return 0; } --------------------------------------------------- mylib.cpp #include <stdio.h> #include <windows.h> extern "C" __declspec(dllexport) void xxx(char *str, ...); char zzz[80]; void xxx(char *str, ...) { printf(str); lstrcpy(zzz, "12345\n"); printf(zzz); } ---------------------------------------------------- mylib.dll.spec @ varargs xxx(str) @ extern zzz ----------------------------------------------------- mylib.cpp compiled successfully in mylib.dll.so main.cpp compiler error: undefined reference to `zzz' What I do wrong ??? How to export variables ??? And another question: how can i export functions such as ClassName::Function();

7 12