February 2004 - Wine-devel - list.winehq.org

What's with command.com / cmd.exe
by Boaz Harrosh 19 Feb '04

19 Feb '04

Some programs, mostly installations also others, look for command.com or cmd.exe to spun commands and batch files. This fails in current wine installation. I know they are not suppose to do that they should use an API, but they do. (What is the API for that and is it supported by wine?) I have soft linked wineconsol.exe.so to \windows\command\command.com in win98 mode. (%systemdir%\cmd.exe in WinNT/XP) And it works OK. (did not yet try WinNT mode). 1) Is this the way to do it? Or are there hidden problems that can arise. (I guess what the application is doing is eventually CreatProcess on command.com/cmd.exe) If so how are we with command-line/Internal-commands compatibility with command.com or cmd.exe? 2) If 1. than should that be done in the regular Install/winecfg session? Or each user to himself. Where are these files in the different windows versions? (By the way same problem in cxoffice) Free Life Boaz

1 0

legal problem for using DLL's
by Erik Dekeyser 19 Feb '04

19 Feb '04

Dear WINE Developers, Briefly with Bricscad IntelliCAD we have an almost-clone of AutoCAD and we are very successfull in selling it to large corporations under a Coporate License Agreement. Several of our Corporate clients want to start with implementing LINUX in their organization. For their engineering departments they need an AutoCAD alternative that is 100% compatible with it and that can be learned by an AutoCAD user in less then 3 hours. BricsCad has invested a lot in making our version of IntelliCAD a stable, relaible and performant CAD software, that is so close to AutoCAD. We have it now ready in a beta version on LINUX. The products name will be BricsCad for Linux and will use WINE. BricsCad for Linux vs AutoCAD is comparable to what Open Office is vs MS Office. We will support three versions: Red Hat, Suse and Java Desktop. Press release is ready. OUR PROBLEM: We are wondering if we can distribute the Microsoft DLL's with the application without infringing the copyright of Microsoft. The alternative is rewrite some of them, but that would require a couple of months of development and postponing the release of the software. I guess we are not the only ones with this problem? Looking forward to your point of view Erik De Keyser CEO BricsCad www.bricscad.com

6 5

Can't compile crosstest
by Jakob Eriksson 19 Feb '04

19 Feb '04

I have noticed I can't compile the crosstests, how can I make it compile? ------------------------- cc1: warning: -fPIC ignored for target (all code is position independent) ../../../tools/make_ctests capture.c dsound.c propset.c >testlist.c || rm -f testlist.c i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o testlist.cross.o testlist.c cc1: warning: -fPIC ignored for target (all code is position independent) i586-mingw32msvc-gcc capture.cross.o dsound.cross.o propset.cross.o testlist.cross.o -o dsound_crosstest.exe -ldsound -luser32 -lkernel32 -ldxguid -luuid -lm propset.cross.o(.text+0xc40): In function `propset_private_tests': /home/jakov/src/wine/dlls/dsound/tests/propset.c:100: undefined reference to `CLSID_DirectSound8' propset.cross.o(.text+0xda0):/home/jakov/src/wine/dlls/dsound/tests/propset.c:120: undefined reference to `CLSID_DirectSoundCapture8' propset.cross.o(.text+0xe50):/home/jakov/src/wine/dlls/dsound/tests/propset.c:130: undefined reference to `CLSID_DirectSoundFullDuplex' propset.cross.o(.text+0xf00):/home/jakov/src/wine/dlls/dsound/tests/propset.c:140: undefined reference to `CLSID_DirectSoundPrivate' propset.cross.o(.text+0xfba):/home/jakov/src/wine/dlls/dsound/tests/propset.c:151: undefined reference to `DSPROPSETID_DirectSoundDevice' propset.cross.o(.text+0x1076):/home/jakov/src/wine/dlls/dsound/tests/propset.c:159: undefined reference to `DSPROPSETID_DirectSoundDevice' propset.cross.o(.text+0x1132):/home/jakov/src/wine/dlls/dsound/tests/propset.c:167: undefined reference to `DSPROPSETID_DirectSoundDevice' propset.cross.o(.text+0x123b):/home/jakov/src/wine/dlls/dsound/tests/propset.c:183: undefined reference to `DSPROPSETID_DirectSoundDevice' make[3]: *** [dsound_crosstest.exe] Error 1 make[3]: Leaving directory `/home/jakov/src/wine/dlls/dsound/tests' make[2]: *** [tests/__crosstest__] Error 2 make[2]: Leaving directory `/home/jakov/src/wine/dlls/dsound' make[1]: *** [dsound/__crosstest__] Error 2 make[1]: Leaving directory `/home/jakov/src/wine/dlls' make: *** [dlls/__crosstest__] Error 2 jakov(a)dmlive:~/src/wine$

2 1

need some info about Wine
by pooja barmola 19 Feb '04

19 Feb '04

Hello sir , myself is working on linux platform. I want to execute the applications that run on windows , to be executed on linux platform. [1] did the application like IVR (commercial software for linux) will work on this Wine for linux. [2] similarly Automatic call distributor could be executed on linux. [3] could you please tell me the full dependencies for Wine and the installation guide for Wine & the configuration info to execute the application. Kindly reply me soon , otherwise I will have to develop on my own efforts. Thanking you Pooja

1 0

About automatic configuration
by Robert van Herk 18 Feb '04

18 Feb '04

Hi... As I'm working (a bit) on winecfg, I noticed the following line on the todo list Wine installation process should install and configure wine But of course, winecfg also needs some automatic probing of at least disks, since there is a "Autodetect me" button in Winecfg for that. Also, Chris Morgan made a cool feature that autodetects your sound system. I was thinking to write a DLL that would export some functions to autodetect stuff... That DLL could then be called from both the installation (or directly after the installation) to auto-setup both sound and harddisks, and could later on be used from winecfg if something ever changes. Plz give me your opinion on my idea. Is this about what was meant by the remark in the todo-list? Would there be any standards to follow for this kind of functionality? Or should I just hack around a bit? Or is something completely different intended / needed? Grtz, Robert

1 0

scanf problem
by Ivan Leo Murray-Smith 18 Feb '04

18 Feb '04

Apparently there is a problem with wine's scanf. this code #include <stdio.h> int main() { int a; printf ("Type a number\n"); scanf ("%d", &a); printf ("You've entered %d\n", a); return 0; } works as expected on linux, but on wine returns [ivan(a)localhost ivan]$ wine test.exe Type a number 5 You've entered 1076166144 [ivan(a)localhost ivan]$ Dimi thinks it's a bug and asked me to fwd this to wine-devel, a very similar program that has the same problem works on windows, I can't test this one because I do't currently have access to a windows box, but unless I've some badly bugged header or something like that, this is a bug. a msvcrt.dll trace follows [ivan(a)localhost ivan]$ wine test.exe --debugmsg +msvcrt trace:msvcrt:DllMain (0x407d0000, DLL_PROCESS_ATTACH, 0x1) pid(8), tid(9), tls(0) trace:msvcrt:msvcrt_init_mt_locks initializing mtlocks trace:msvcrt:msvcrt_init_io :handles (0x14)(0x24)(0x2c) trace:msvcrt:msvcrt_init_console :Opening console handles warn:msvcrt:msvcrt_init_console :Console handle Initialisation FAILED! trace:msvcrt:msvcrt_init_args got 'test.exe', wide = L"test.exe" argc=1 trace:msvcrt:MSVCRT_setlocale (0 C) trace:msvcrt:_lock (19) trace:msvcrt:_lock (17) trace:msvcrt:_lock : creating lock #19 trace:msvcrt:_unlock (17) trace:msvcrt:_unlock (19) trace:msvcrt:DllMain finished process init trace:msvcrt:MSVCRT___set_app_type (1) Console application trace:msvcrt:__getmainargs (0x403000,0x403004,0x407bff10,-1,0x407bff14). trace:msvcrt:_lock (9) trace:msvcrt:_lock (17) trace:msvcrt:_lock : creating lock #9 trace:msvcrt:_unlock (17) trace:msvcrt:_unlock (9) trace:msvcrt:MSVCRT_atexit (0x4013b0) trace:msvcrt:_onexit (0x4013b0) trace:msvcrt:_lock (13) trace:msvcrt:_lock (17) trace:msvcrt:_lock : creating lock #13 trace:msvcrt:_unlock (17) trace:msvcrt:_onexit expanding table trace:msvcrt:_unlock (13) Type a number warn:msvcrt:MSVCRT_fscanf 0x408068e0 ("%d"): semi-stub trace:msvcrt:_read :fd (0) handle (0x14) buf (0x40363f18) len (512) 5 trace:msvcrt:_read :EOF trace:msvcrt:_read "5\n" trace:msvcrt:MSVCRT_fscanf returning 1 You've entered 1076166144 trace:msvcrt:MSVCRT__cexit (void) trace:msvcrt:DllMain (0x407d0000, DLL_PROCESS_DETACH, 0x1) pid(8), tid(9), tls(0) trace:msvcrt:msvcrt_free_mt_locks : uninitializing all mtlocks trace:msvcrt:_fcloseall :closed (0) handles trace:msvcrt:_close :fd (0) handle (0x14) trace:msvcrt:msvcrt_free_fd :fd (0) freed trace:msvcrt:_close :ok trace:msvcrt:_close :fd (1) handle (0x24) trace:msvcrt:msvcrt_free_fd :fd (1) freed trace:msvcrt:_close :ok trace:msvcrt:_close :fd (2) handle (0x2c) trace:msvcrt:msvcrt_free_fd :fd (2) freed trace:msvcrt:_close :ok trace:msvcrt:msvcrt_free_console :Closing console handles trace:msvcrt:DllMain finished process free [ivan(a)localhost ivan]$ Ivan.

4 3

wine/controls/button.c (get_button_text) : potential memory leak
by Vincent Pelletier 18 Feb '04

18 Feb '04

In get_button_text, the returned handle must be freed by caller (-> memory leak if it forgots about it). That could be solved using something like : /* BEGIN */ /* in button.c */ inline static void get_button_text(HWND hwnd, WCHAR *out, INT max_len) { INT len = MIN(GetWindowTextLengthW( hwnd ), max_len); GetWindowTextW( hwnd, buffer, len + 1 ); } /* everywhere needed */ #define MAX_BUTTON_TEXT_LEN 255 /* just as an example */ caller_func(HWND hwnd) { WCHAR button_text[MAX_BUTTON_TEXT_LEN]; /* can also be dynamicaly allocated of course */ get_button_text(hwnd, button_text, MAX_BUTTON_TEXT_LEN); /* do something with gathered string */ } /* END */ So, why wouldn't I do it myself ? Because I'm getting lost in sources :). I only crawl wine code for only 48 hours now... So about 5 hours of effective crawling. Vincent Pelletier

1 0

Re: Dll separation - Winedos from kernel32
by Eric Pouech 18 Feb '04

18 Feb '04

Steven Edwards a écrit : > Hello, > This was from a totaly foolish attempt at building winedos on Mingw. I > was hoping we could create a ntvdm for ReactOS. I guess we are not > planning on totaly rewritting winedos to deal with Erics new filesystem > stuff right? So we could just move this call here. this is already taken care of in one of the patches I sent A+

1 0

Fixing the SysParametersInfoW->A crosscall
by Justin Chevrier 18 Feb '04

18 Feb '04

Just a note that i'm working on correcting the SysParametersInfoW -> SysParametersInfoA crosscall, so that there's no duplicated effort I thought i'd send a message to wine-devel. I hope to have a patch in the next couple of days. Justin Chevrier _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

WINE plugins
by KappaM KappaM 18 Feb '04

18 Feb '04

Hi, I have an application and a Netscape plugin that run in Windows. That plugin is correctly loaded by either Netscape or my application. Now I need to "port" these modules on Linux. To do so I recompiled my application with the WineLib environment, I modified/added the interface function of my plugin and alse recompiled it with the WineLib environment. Every thing works fine if the plugin is loaded by my application. The problem arises when I try to load the plugin by Linux-Mozilla, as the plugin is not recognized. I think that the problem is due to the fact that the wine environment is not active, is it correct? Is it possible to load the wine environment to work only with the plugin (not with an application)? Do you have any suggestions to make my WinePlugin loadable by Linux Mozilla ? Thanks in advance Katia _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1