wine-devel

wine-devel@winehq.org

15 participants
84452 discussions

RE: Wine DLLs compiled under Visual C
by Patrik Stridvall 09 Sep '02

09 Sep '02

> I want to get some comments about how others here try to get the DLLs > compiled > under Visual C. I went ahead and tried to do this for > shell32.dll and after > a > little work it went so far fine. However after creating a > config.h file for > Visual C with a few definitions such as for inline, I had to > make some minor > changes to some of the c source files such as adding an > #include "config.h" > and sometimes #include "wine/port.h" to the beginning. Yes. I have submitted most of my changes of that kind to the CVS so the current status of that is quite good. > Is this the recommended way of doing things or is there a reason that > "config.h" > shouldn't be included in some of the dll source files? I ask because I > noticed > that in a few of the shell32 files it is included but in the > several of them > it wasn't and in a few it doesn't (yet) need to be. Use msvcmaker. It generates Visual Studio 6.0 .dsw and .dsp files as well as an include/config.h file. cd wine ./tools/winapi/msvcmaker Then open wine.dsw in Visual Studio. PS. Note that msvcmaker only runs under Unix. I use Samba to export the directory to Windows.

2 1

Re: Trying to debug Paradise Poker client
by Per Nystrom 09 Sep '02

09 Sep '02

Ok, these are the lines that concern me when I'm running it with the builtin advapi32 dll: 080995d0:Call advapi32.CryptAcquireContextA(41ee6570,00000000,00000000,00000001,f0000000) ret=40cc424b 080995d0:Ret advapi32.CryptAcquireContextA() retval=00000000 ret=40cc424b 080995d0:Call advapi32.CryptAcquireContextA(41ee6570,00000000,40d0e840 "Intel Hardware Cryptographic Service Provider",00000016,00000000) ret=40cc429c 080995d0:Ret advapi32.CryptAcquireContextA() retval=00000000 ret=40cc429c What can be done to fix it? Thanks, Per Nystrom

2 1

Wine DLLs compiled under Visual C
by Rolf Kalbermatter 09 Sep '02

09 Sep '02

I want to get some comments about how others here try to get the DLLs compiled under Visual C. I went ahead and tried to do this for shell32.dll and after a little work it went so far fine. However after creating a config.h file for Visual C with a few definitions such as for inline, I had to make some minor changes to some of the c source files such as adding an #include "config.h" and sometimes #include "wine/port.h" to the beginning. Is this the recommended way of doing things or is there a reason that "config.h" shouldn't be included in some of the dll source files? I ask because I noticed that in a few of the shell32 files it is included but in the several of them it wasn't and in a few it doesn't (yet) need to be. Rolf Kalbermatter

1 0

RE: New header winternl.h
by Patrik Stridvall 09 Sep '02

09 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > The easy solution is to include the header just as I have > submitted it > > and not use it at all or rather postponing the problem of > using it or not > > to the future. If it exists somebody might get some ideas, > some day... > > But this won't really address the issue; if we don't use the header it > will most likely get broken by something and nobody will notice, and > then when someone uses it in Winelib we have the same problem. True. > I think we should add the header and use it instead of ntddk.h where > possible. This probably requires adding/moving definitions to it that > are currently in ntddk.h, but that's acceptable as long as they are > exported under Windows anyway. And it's better to follow the SDK than > the DDK where we can, since this is what apps we want to build with > Winelib will be using too. Agreed. If you apply the patch, I will see what I can do. I have already looked into it a little. However I think most of what is in ntddk.h must be moved into wintrnl.h. Possible some stuff should go in some other wine/*.h header. Do you want things that is only defined in ntddk.h be protected by #ifdef __WINE__ so no normal Windows application can't use them?

2 1

Press: Running Windows Games with WineX 2.1
by Francois Gouget 08 Sep '02

08 Sep '02

* August 29, 2002 - LinuxOrbit Break out Your Games Library: Running Windows Games with WineX 2.1 http://www.linuxorbit.com/modules.php?op=modload&name=Reviews&file=index&re… -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

3 5

May we use winelib-wcmd as $COMSPEC command processor?
by Uwe Bonnes 08 Sep '02

08 Sep '02

Hallo, some java program in the Xilinx webpack suite is started as a batch file from a perl script. When the batch should be executed, the perl script looks for the $COMSPEC variable and starts the batch like: Call kernel32.CreateProcessA(40c82e0c "c:\\command.com",40c8fee4\ "c:\\command.com /c I:\\xilinx\\bin\\nt\\ChipView.bat -f magcom.vm6"... Pointing $COMSPEC to the winelib wcmd processor doesn't work as expected, as CreateProcess tries to execute wcmd as windows executable, as CeateProcess is called like: Call kernel32.CreateProcessA(40c8248f\ "h:/tmp/wine/compile/wine/programs/wcmd/wcmd",40c8ff1c\ "h:\\tmp\\wine\\compile\\wine\\programs\\wcmd\\wcmd /c\ I:\\xilinx\\bin\\nt\\ChipView.bat -f magcom.vm6",... I there any way to use winelib-wcmd in this situation? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 5

RE: New header winternl.h
by Patrik Stridvall 08 Sep '02

08 Sep '02

> On Sun, 8 Sep 2002, Jürgen Schmied wrote: > > > > > > And do what? > > > As I said above wintrnl.h can't include ntddk.h. > > > > > > Of course we can just include it as it is and don't use it... > > I would do nothing as long as nobody needs it. There are > many *.h files > > in the SDK that we don't have and nobody missed them till today. > > Missing headers are making the lives of Winelib users pretty hard: the > first time they try to compile their application they get tons of > errors. They first wonder what they are doing wrong, then why > Wine does > things differently from Windows, is there a hidden reason, > and then how > the hell they are going to fix the headers and their messy > dependencies > and whether they should not rather completely give up. Fully agreed. Every header that it missing or wrong (even if fixing it is trivial) is a potential: "Sorry boss, I tried to compile our application with WineLib but it didn't work. So we can't port our applications using WineLib.". > Now, I'm not saying we should spend all our time trying to > make sure our > headers are perfect rather than improving binary emulation. As with > everything this is a question of balance. I have being planning a long time to write a Perl script that compares the Microsoft SDK headers with the Wine headers. I just haven't got around to do it... So don't hold your breath. > Now concerning this header, since it's so new (and quite useless) it > certainly isn't going to be a problem soon and as you pointed out we > definitely have other header issues to tackle first. Still if we can > find an easy nice solution, let's go for it (unfortunately that does > not appear to be the case). The easy solution is to include the header just as I have submitted it and not use it at all or rather postponing the problem of using it or not to the future. If it exists somebody might get some ideas, some day... Note that you can use it as long as you don't include ntdef.h or ntddk.h as well so the non-core DLLs should be able to use it without any problem. Nether the less I would strongly advise that the non-core DLLs doesn't use it either unless it REALLY, REALLY, REALLY must...

2 1

RE: New header winternl.h
by Patrik Stridvall 08 Sep '02

08 Sep '02

> On 7 Sep 2002 at 18:42, Patrik Stridvall wrote: > > > As of Microsoft SDKs August 2002 there is a brand new > > header called winternl.h that contains a part of the > > relased information. > For me this header looks like they copyed some informations > from the ntddk in hurry into one file to release it. It's definitely > not covering a complete api. > We should leave this informations in ntddk.h and replace > the winternl.h with a file containing only #include "ntddk.h" > if there is some additional information in wintenl.h it shouldn't > hurt to merge it into the aprobiate headers. The problem is that we don't (and shouldn't) install ntdef.h and ntddk.h but we should do that with wintrnl.h since it is an official header and might be used by a Winelib application. Of course since it first appear a few weeks ago not many application are likely to use it yet... > > Unfortunetly it can't be included at the same time > > as ntdef.h and ntddk.h because it partly defines the > > same information. > The problem is we need a mix between sdk and ddk headers > in our include directory. We could separate it but I don't > know if its > worth the work. I'm not sure either. > > Now, I have the full Microsoft SDK August 2002 contains > > over 1000 .h files!!! But ntdef.h and ntddk.h is not > > among them. They doesn't seem to be offical headers or > > at least not any more. > They are in the ddk. Of course, I should I guessed from the name ntddk.h, that it is from the DDK after all... :-) > > So I'm a little unsure on how the headers should be organised. > > winternl.h contains to little information to fully replace > > ntdef.h/ntddk.h in fact in some cases of the enums in winternl.h > > is incomplete but the full enum exists in ntddk.h!!! > Yes see abouve. This file is a mess! Agreed. :-) > > Futhermore some of the functions and data structures in ntddk.h > > is defined in no header in the offical Microsoft SDKs!!! > DDK ;-) > > > While we probably should include winternl.h because its an offical > > header I'm a little unsure on how or whether we should use it > > ourselves and what we should do with ntdef.h/ntddk.h. > We don't should us it at all. > > > Any suggestions? > Keep cool ;-) And do what? As I said above wintrnl.h can't include ntddk.h. Of course we can just include it as it is and don't use it...

3 2

RE: TBS_DOWNISLEFT
by Patrik Stridvall 08 Sep '02

08 Sep '02

> Can someone with a recent SDK tell me the value of TBS_DOWNISLEFT, > defined in commctrl.h? #if (_WIN32_IE >= 0x0501) #define TBS_DOWNISLEFT 0x0400 // Down=Left and Up=Right (default is Down=Right and Up=Left) #endif

1 0

TBS_DOWNISLEFT
by Dimitrie O. Paun 08 Sep '02

08 Sep '02

Can someone with a recent SDK tell me the value of TBS_DOWNISLEFT, defined in commctrl.h? TIA, Dimi.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel