- Wine-Devel - list.winehq.org

Need to know some macro values
by Andriy Palamarchuk Aug. 27, 2002

Aug. 27, 2002

I'm going to add some define's to our headers, but can't find their values online. Can somebody who has Microsoft headers compile and run the test application and send me the output? Thanks, Andriy __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

2 2

Re: wine/ dlls/kernel/wowthunk.c dlls/ntdll/file.c ...
by Marcus Meissner Aug. 27, 2002

Aug. 27, 2002

On Mon, Aug 26, 2002 at 08:14:00PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 1030410840440784468854876 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 02/08/26 20:14:00 > > Modified files: > dlls/kernel : wowthunk.c > dlls/ntdll : file.c > dlls/winedos : int21.c > files : directory.c dos_fs.c drive.c file.c profile.c > smb.c smb.h > include : drive.h file.h > loader : task.c > memory : registry.c > misc : registry.c > msdos : dosconf.c int11.c int21.c ioports.c > scheduler : process.c > > Log message: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Convert most of the file APIs to Unicode. Is it just me or did this patch and several more not go over wine-patches? Ciao, Marcus

2 1

I'm baaak
by Dustin Navea Aug. 27, 2002

Aug. 27, 2002

im back! __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

1 0

Question about unix path request in 2 of the wine dlls
by Steven Edwards Aug. 26, 2002

Aug. 26, 2002

in urlmon umon.c calls cabextract for by requesting the unix path via wine_get_unix_file_name and in shell32 shelllink.c get_unix_file_name is used in a few locations. Does anyone have a suggestion on a clean simple way to handle both of these on non-nix platforms? Can this be moved to libwine? Thanks Steven __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com

2 2

--dll buggy behaviour ?
by Raul Dias Aug. 26, 2002

Aug. 26, 2002

Hi, I think that I spot a bug in the way --dll command line behaves. When trying to install internet explorer 5.01 sp2 in a empty tree/fake windows (protected with WINEPREFIX), the IE 5 installer launchs: trace:process:CreateProcessA app (null) cmdline "acmsetup /T nashbase.stf /S C:\\windows\\msdownld.tmp\\AS00AA6F.tmp\\ /QT /g \"C:\\WINDOWS\\IE Setup Log.Txt\"" trace:process:find_exe_file looking for "acmsetup" trace:process:open_exe_file Trying native exe "C:\\windows\\msdownld.tmp\\AS00AA6F.tmp\\acmsetup.exe" trace:process:CreateProcessA starting "C:\\windows\\msdownld.tmp\\AS00AA6F.tmp\\acmsetup.exe" as Windows binary trace:process:PROCESS_InitWine starting process name="C:\\windows\\msdownld.tmp\\AS00AA6F.tmp\\acmsetup.exe" file=4 argv[0]="acmsetup" trace:process:PROCESS_InitWine starting Win32 binary "C:\\windows\\msdownld.tmp\\AS00AA6F.tmp\\acmsetup.exe" trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\kernel32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\msdownld.tmp\AS00AA6F.tmp\advapi32.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\user32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\rpcrt4.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\ole32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\mpr.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\lz32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\version.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\msdownld.tmp\AS00AA6F.tmp\mssetup.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\shlwapi.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\msdownld.tmp\AS00AA6F.tmp\comctl32.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\SHELL32.dll' : builtin err:thunk:_loadthunk (commctrl.dll, Cctl1632_ThunkData16, comctl32.dll): Unable to load 'commctrl.dll', error 2 Note that tm comctl32.dll is native. However I have launched the instller with: wine --dll comctl32,commctrl=b ie5setup.exe In my config file however, I have the load order as "native, builtin" for both dlls. Is it possible that the --dll command line argument is not valid for subprocess/forks from the lauched process? Or is it a feature ? []'s Raul Dias

5 12

Problems compiling wine with Intel Compiler
by mkyprianou＠ICTV.com Aug. 26, 2002

Aug. 26, 2002

I'm getting compiler errors when I try to compile wine with the Intel C++ 6.0 Compiler. This works fine with the g++ compiler. $ icc -c tstwine.cpp -I/usr/include/wine tstwine.cpp /usr/include/wine/basetsd.h(27): error: invalid combination of type specifiers typedef char __int8; ^ /usr/include/wine/basetsd.h(30): error: invalid combination of type specifiers typedef short __int16; ^ /usr/include/wine/basetsd.h(33): error: invalid combination of type specifiers typedef int __int32; ^ /usr/include/wine/basetsd.h(36): error: invalid combination of type specifiers typedef long long __int64; ^ /usr/include/wine/basetsd.h(36): error: invalid combination of type specifiers typedef long long __int64; ^ /usr/include/wine/winnt.h(59): catastrophic error: #error directive: You need gcc >= 2.7 to build Wine on a 386 # error You need gcc >= 2.7 to build Wine on a 386 ^ compilation aborted for tstwine.cpp (code 4) It looks like the wine headers need a level of the gcc version for the compiler, but since I'm not using gcc, there is no gcc version level set. Has anyone built wine with the Intel Compiler? If so, what was done to get this to work? Is any work being done to allow the usage of the Intel compiler with wine? thanx

2 1

How do I grab the screen contents referred to by an hDC?
by Bill Medland Aug. 26, 2002

Aug. 26, 2002

Can anyone tell me how I can do this; I am trying to debug a problem with user32.dll under the native NT comctl32.? When drawing a ListView --debugmsg +relay shows three consecutive calls; SetRect (&rect...) FillRect (00000b04,&rect,00000082 (/* I reckon that is GetStockObject(BLACK_BRUSH)*/) DrawIcon (00000b04,0x40,0x60,hicon,...) Now as it stands I get random rubbish in the background of the icons (in the region covered by the mask). If I insert a hack into DrawIcon so that it does a FillRect (b04,the rectangle, GetStockObject (WHITE_BRUSH)) then things work out OK. (Also, the code seems to draw the icon to four hDCs and I can do the same hack on the second hDC to get the same effect but not the third and fourth). Firstly I don't understand how it has a chance of working given that it fills the rectangle with a black brush. So what I want is a way of seeing what the contents of the rectangular region is at the exit from the FillRect and the entrance to the DrawIconEx, based on the hDC. (Something like "give me the pixels of the 32x32 rectangle at this location of this hDC") Also it seems to me that these two function calls are consecutive, so if anything is changing I guess it would be as a result of code within comctl32 itself. Is there any other way that control can come back into the Wine code between a relay exit and entrance? Bill

1 0

Re: Add BiDi infrastructure
by Dimitrie O. Paun Aug. 26, 2002

Aug. 26, 2002

On August 15, 2002 12:08 pm, Shachar Shemesh wrote: > configure.ac: > Added a check for the existance of the fribidi include file. No > check for the library, as we do not statically link with it. Like any programmer, I usually hate copying stuff around, but in this case isn't it better to simply have a copy of the fribidi heades around? I mean, we do the runtime load and checks anyway, why do we need to have the header around? If we don't use much out of the header, I would say simply include the prototype of the functions we're calling into the dlls/gdi/fribidi.c file directly, and be done with it. No configure, no macros, no ifdefs, no mess. -- Dimi.

4 12

RE: Problems compiling wine with Intel Compiler
by Patrik Stridvall Aug. 26, 2002

Aug. 26, 2002

> On Mon, Aug 26, 2002 at 05:40:01PM +0200, Patrik Stridvall wrote: > > The Intel compiler like the Microsoft compiler probably > already supports > > __int{8,16,32,64}. > > > > This will have to be changed to > > > > #if !defined(_MSC_VER) && !defined(XXX) > > Or maybe a HAVE_xxx configure check? In general this is the way is should be done. However no rule without an exception. :-) Short explaination: In the header files it can't be done that way because the same header files must support multiple compilers and thus they can't have a shared config.h file.

1 0

RE: Problems compiling wine with Intel Compiler
by Patrik Stridvall Aug. 26, 2002

Aug. 26, 2002

> I'm getting compiler errors when I try to compile wine with the Intel > C++ 6.0 Compiler. This works fine with the g++ compiler. > > $ icc -c tstwine.cpp -I/usr/include/wine > tstwine.cpp > /usr/include/wine/basetsd.h(27): error: invalid combination of type > specifiers > typedef char __int8; > ^ > > /usr/include/wine/basetsd.h(30): error: invalid combination of type > specifiers > typedef short __int16; > ^ > > /usr/include/wine/basetsd.h(33): error: invalid combination of type > specifiers > typedef int __int32; > ^ > > /usr/include/wine/basetsd.h(36): error: invalid combination of type > specifiers > typedef long long __int64; > ^ > > /usr/include/wine/basetsd.h(36): error: invalid combination of type > specifiers > typedef long long __int64; > ^ The Intel compiler like the Microsoft compiler probably already supports __int{8,16,32,64}. The typedef are protected by a #ifndef _MSC_VER This will have to be changed to #if !defined(_MSC_VER) && !defined(XXX) where XXX is some that indicate that the Intel compiler is used. Check the manual. > /usr/include/wine/winnt.h(59): catastrophic error: #error directive: > You need gcc >= 2.7 to build Wine on a 386 > # error You need gcc >= 2.7 to build Wine on a 386 > ^ > > compilation aborted for tstwine.cpp (code 4) > > It looks like the wine headers need a level of the gcc version for the > compiler, but since I'm not using gcc, there is no gcc version level > set. Presumably the Intel compiler like the Microsoft compiler already defined __cdecl and __stdcall. In that case similar to first problem above the line # elif defined(_MSC_VER) will have to be change to # elif defined(_MSC_VER) || defined(XXX) where XXX is the same as above. > Has anyone built wine with the Intel Compiler? If so, what was > done to get this to work? > > Is any work being done to allow the usage of the Intel > compiler with wine? Not that I know of.

2 1