wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> On Tue, 5 Feb 2002, Patrik Stridvall wrote: > > > I have finally tried to compile Wine with MSVC. > > Eventhough I had to do some hack on the whole > > it compiled quite well. > > Great. On a slightly related note, is it possible that we compile Wine > with the MS headers? What would it take to do that? Well. If you do as I did and just add just create a Visual Studio Project (.dsp) for each DLL using the MS headers is the default. I had to add "..\..\include" to the include path to get it to use the Wine header. As to how good it works with MS header: Well, the problem is that if you don't add the path the Wine header files like debugtools.h doesn't exists so it doesn't compile very well and if you do the Wine headers take priority. Of course you could add the MS header for inclusion one more time after the Wine headers, but where they are under Windows are installation dependent and not very portable. :-( Additionally windef.h must be included first. #include "winbase.h" #include "windef.h" doesn't work. You have to do #include "windef.h" #include "winbase.h" This is a minor issue though. I also so got some other strange error with PCONTEXT in winnt.h which in didn't understand. In short it was a terrible mess so I primarily tested it with the Wine headers. I have only tested a few DLL since doing .dsp files for each them was some work. I might do a script to automatically generate .dsp files for MSVC some day. > If we > could, we would > have one more degree of freedom: > > Platform Compilers BinFmt Headers > -------- --------- ------ ------- > Linux gcc ELF Wine > *BSD MSVC PE MS > Solaris Borland ReactOS(?) > Cygwin > > Esentially, most of the above possible cobinations should > work (except, of > course Windows-base compilers and ELF). Well. I think GNU C chokes on the MS headers so that won't work either. > If we get this level of portability, would be nice to set an automatic > compile farm which tries all the possible combinations, and reports > problems early, so they get fixed. Yes, that would probably be a good idea.

3 2

RE: (FWD) Announcing wineconf 2002
by Patrik Stridvall 06 Feb '02

06 Feb '02

> For those coming internationally, just hope that Microsoft > isn't waiting > at the airport with a bunch of DCMA lawyers to arrest you :) > > Mind you, M$ wouldn't do that because they don't like to > admit that Linux, > Wine, or anything else actually exists. I don't think Wine does anything DMCA related right now. However it will be much fun when we will get to the DRM parts of Windows. Dialog from the future: "Oh, no, this is not a circumvention device, we are just trying to implement copy protection to protect the intrests of RIAA and MPAA." "But what about the function FooIsAuthorized?" "What about it? It is just a stub that nobody for some reason have gotten around to implement. :-)" BOOL WINAPI FooIsAuthorized(...) { FIXME("(...): stub\n"); return TRUE; /* Information wants to be free */ }

1 0

RE: Header files not present on Windows
by Patrik Stridvall 05 Feb '02

05 Feb '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Hmm. I'm note sure I like making unistd.h > > an optional header but then few part of > > Wine should include it anyway so perhaps > > it doesn't matter. > > The question is whether you can build without it. If the needed > definitions are provided by other includes then it's fine to make it > optional; but if the code doesn't compile without it then there's no > point in having a check. Yes and in many cases it did work without unistd.h, but maybe that is because it really wasn't needed at all. In some case it might have worked because some of the functions in unistd.h is defined else where in Windows and in some case we might get it to work by including needed files. Of course in such cases we probably should fix Wine and include that other header exclusively instead of unistd.h. Anyway, I just experimented a little trying to get Wine to compile under Windows. I'm not really sure exacly what to do. Eventually I guess that the non-core DLL:s never should call any non Windows functions at all and the core DLL:s are not really useful to compile and run under Windows anyway.

1 0

Re: Header files not present on Windows
by Alexandre Julliard 05 Feb '02

05 Feb '02

Patrik Stridvall <ps(a)leissner.se> writes: > Hmm. I'm note sure I like making unistd.h > an optional header but then few part of > Wine should include it anyway so perhaps > it doesn't matter. The question is whether you can build without it. If the needed definitions are provided by other includes then it's fine to make it optional; but if the code doesn't compile without it then there's no point in having a check. -- Alexandre Julliard julliard(a)winehq.com

1 0

TSXxxx functions: die!
by Dimitrie O. Paun 05 Feb '02

05 Feb '02

Once again, Since this list is (again!) so quiet, I feel obligated to stir the spirits a little. So here it goes: we should get rid of the TSXxxx functions. Why? -- we don't keep to standard API, which is against the Wine's spirit -- they introduce yet another (useless) layer -- we reaquire the lock like crazy for no good reason -- most modern X systems are already thread safe -- we integrate Wine's locking with glic's, so we should be OK -- they are ugly How? s/TSX/X/g rm -rf tsx + misc Makefile cleanups But I hear people screaming: how about portability? What about platforms where we don't integrate with libc's locking, or when we don't have a thread safe X? Well, we can create a wrapper driver which simply aquires the lock, calls into the regular driver, then releases the lock. In fact, I am not convinced we shouldn't deal this way with the current driver, to simplify the code. It's not like we're missing a lot on performance... -- Dimi.

1 0

WineHQ cvs
by Francois Gouget 05 Feb '02

05 Feb '02

I was looking at the WineHQ CVS last week-end (trying to add a section about how to contribute to Wine and to beef up the about section) and, at least to an untrained eye, it looks like it contains many obsolete files that should be deleted. Here are some examples: * a number of files exist in both .html and .shtml form. Isn't the html form obsolete? about.html & about.shtml contrib.html & contrib.shtml search.html & search.shtml who.html & who.shtml * some files have multiple versions lying around refs.html & refs.shtml & refs2.html index.shtml & indexold.html * there is a number of file that I'm not sure are still in use threads_etc, referenced from design.html which is referenced, but commented out, from indexold.html & test003.html win_utils_test, does not appear to be referenced anywhere shots.html, referenced only from indexold.html Is there a good reason to keep the above files? Did I miss something? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

2 1

Re: Make a progress bar control behave more like a windows equivalent
by Dimitrie O. Paun 05 Feb '02

05 Feb '02

On Tue, 5 Feb 2002, Dmitry Timoshkov wrote: > Hello. > > According to my test application, progress bar control always does > InvalidateRect() if it wants to repaint itself. It is smart enough > whether or not invalidate background. Probably other comctl32 controls > need to be fixed in respect of this. That's a good point. When I wrote the Progress Bar & Up Down Controls way back when, I did the repaint thingy as other controls were doing. So I think this style simply got propagated through the controls without good reason, other than "others do it too". -- Dimi.

1 0

Re: *MEGA* bug
by lawson_whitney＠juno.com 05 Feb '02

05 Feb '02

On Tue, 28 Nov 2000, it was written: > > > On Mon, 27 Nov 2000, Andreas Mohr wrote: > > > Hi all, > > > > does no Windows program at all ever check return values !?!?!? OOPS, sorry. This and the other anachronisms are what come of using pieces of my mail system to do stress tests. Lawson Probable user head space error. - Dennis A. Moore

1 0

How long for CVS?
by Gerhard Gruber 04 Feb '02

04 Feb '02

A few days ago I sent a patch for WritePrivateProfileSection that fixed the wrong behaviour that this function should create multiple keys with the same name which will be needed for wininit.ini. Now I have seen two updates of the CVS tree but this path hasn't been applied. Does this mean I should resend it to the pathces list, or should I wait a bit longer? How long does it usually take for a patch to get submitted?

1 0

Re: Listview Unicodification (part 2)
by Alexandre Julliard 04 Feb '02

04 Feb '02

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Alexandre, let me know if you like the patch better in this format. Yes, it's much better that way, thanks. -- Alexandre Julliard julliard(a)winehq.com

1 0

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