I'm not sure I understand the problem. wrc generates .res
files that should work just fine with MS VC or windres. Why
doesn't this work?
The last time I tried(two months back) it wouldn't work.
I will double check tonight and email you a full report of my
attempts/problems.
Thanks
Steven
Steven Edwards [EMAIL PROTECTED] writes:
I agree but untill it is fixed mingw/MS_VC are SOL.
Anyone want to help the MS_VC and Mingw port out by
fixing wrc to output compatable rc files? Currently
winebuild reads the wrc resources from the spec file
which is not going to be used in the
However Alexandre doesn't like binary files in the CVS for good reasons
While I can see that to a point, it's not 100% clear to me that storing a .gif
(or what have you) in CVS is such a bad idea. I mean, the main advantage
of storing stuff as plain text is to be able to look at (and
However Alexandre doesn't like binary files in the CVS
for good reasons
While I can see that to a point, it's not 100% clear to me
that storing a .gif
(or what have you) in CVS is such a bad idea. I mean, the
main advantage
of storing stuff as plain text is to be able to look at
On Sat, 4 May 2002, Patrik Stridvall wrote:
[...]
CVS can handle binary files no problem. Can someone please refresh my
memory on why storing binary _images_ in CVS is such a bad idea?
I think it is because CVS can't store the diffs between binary files.
It stores the whole file even if
On Sat, May 04, 2002 at 09:57:26AM +0200, Patrik Stridvall wrote:
However Alexandre doesn't like binary files in the CVS
for good reasons
...
CVS can handle binary files no problem. Can someone please refresh my
memory on why storing binary _images_ in CVS is such a bad idea?
I
I would argue that compatibility with MS' rc is more
important...
I would too.
About the resources, Eric Kohl told me one time the
plain txt rc was due to endiness issues on non-x86
platforms. I dont really see how thats a issue if the
platform supports GIF/JPEG but I dont understand how
alot
Dimitrie O. Paun [EMAIL PROTECTED] writes:
CVS can handle binary files no problem. Can someone please refresh my
memory on why storing binary _images_ in CVS is such a bad idea?
The main problem is that you can't generate diffs for them, so
everybody has to download the full tarball every
On Sat, May 04, 2002 at 02:19:59PM -0700, Alexandre Julliard wrote:
The main problem is that you can't generate diffs for them, so
everybody has to download the full tarball every time a binary file
changes.
You are right - but mainly on theory. In the real cases that have
affected changes to
Joerg Mayer [EMAIL PROTECTED] writes:
You are right - but mainly on theory. In the real cases that have
affected changes to images in wine, the diff has problably been larger
than a complete gif/bmp/jpg in most cases.
The size of the file itself is not the issue. The issue is that people
can
On May 4, 2002 06:19 pm, Alexandre Julliard wrote:
The size of the file itself is not the issue. The issue is that people
can no longer download a 500Kb Wine-xxx.diff.gz and need to download
the 7Mb Wine-xxx.tar.gz instead. It basically makes the .diff.gz files
useless for upgrading.
I see.
On May 4, 2002 04:22 am, Francois Gouget wrote:
On Sat, 4 May 2002, Patrik Stridvall wrote:
[...]
CVS can handle binary files no problem. Can someone please refresh my
memory on why storing binary _images_ in CVS is such a bad idea?
I think it is because CVS can't store the diffs
On May 4, 2002 06:19 pm, Alexandre Julliard wrote:
It basically makes the .diff.gz files useless for upgrading.
And if images do change, what's wrong with 'diff -au'?
And we can have a script to actually place the (ugly)
output at the end of the .diff so that people that read
such diffs
Dimitrie O. Paun [EMAIL PROTECTED] writes:
I would argue that compatibility with MS' rc is more important...
I don't see why this is so important. The resource compiler is
included in the tree, and should be pretty trivial to make work on any
platform that you want to build Wine on. And if it
On May 4, 2002 09:39 pm, Alexandre Julliard wrote:
Besides, if someone really wants to use the MS compiler, it would be
pretty trivial to enhance bin2res to generate MS-compatible files from
the Wine sources. There's no need to ship binary files for that.
OK, I'm convinced :) I fact, I don't
On Sat, May 04, 2002 at 02:22:56AM -0400, Dimitrie O. Paun wrote:
However Alexandre doesn't like binary files in the CVS for good reasons
While I can see that to a point, it's not 100% clear to me that storing a .gif
(or what have you) in CVS is such a bad idea. I mean, the main advantage
Besides, if someone really wants to use the MS
compiler, it would be
pretty trivial to enhance bin2res to generate
MS-compatible files from
the Wine sources. There's no need to ship binary
files for that.
OK, I'm convinced :) I fact, I don't care much about
MS rc, is just that
I
I will start a bug in bugzilla to address this
issue.
(wrc does not generate resources that can be used on
Mingw and MS_VC)
http://bugs.winehq.com/show_bug.cgi?id=645
__
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
How are you planning on linking the dlls/resources once wine is up 2
date on MSVC?
No specific plan. I just fix issues that I can find acceptable
solutions to one by one in hope that all will be fixed eventually.
You and Alexandre have fixed some of them that I wasn't sure how
to solve in an
On Fri, 3 May 2002, Patrik Stridvall wrote:
Can MSVC build wrc resources and link them?
The formats are not 100% compatible. Specificly WRC supports embedded
icons and bitmaps. Microsoft RC requires a link to the binary.
However Alexandre doesn't like binary files in the CVS for good
How are you planning on linking the dlls/resources once wine is up 2
date on MSVC?
Can MSVC build wrc resources and link them?
Thanks
Steven
Every revolution was once a thought in one man's mind
- Ralph Waldo Emerson
Dimitrie O. Paun wrote:
On Wed, 6 Feb 2002, Steven Edwards wrote:
Any other interesting compilers? Maybe the Solaris one? What about
headers? We already have 4 * 4 * 3 = 48 combinations.
I tried briefly with the Solaris compiler, but there seemed
to be enough
problems that I gave
From: Patrik Stridvall [EMAIL PROTECTED] wrote:
Dimitrie O. Paun wrote:
On Wed, 6 Feb 2002, Steven Edwards wrote:
Any other interesting compilers? Maybe the Solaris one? What about
headers? We already have 4 * 4 * 3 = 48 combinations.
I tried briefly with the Solaris compiler,
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? If we
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?
On Wed, 6 Feb 2002, Patrik Stridvall wrote:
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.
Sorry Patrik if my questions are
Platform Compilers BinFmt Headers
- -- ---
Linux gccELF Wine
*BSD MSVC PE MS
Solaris BorlandReactOS(?)
Cygwin
There are very little changes needed for the ReactOS port and only one
or 2 ReactOS specific
On Wed, 6 Feb 2002, Patrik Stridvall wrote:
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.
Sorry Patrik if my
On Wed, 6 Feb 2002, Patrik Stridvall wrote:
[...]
I also so got some other strange error with PCONTEXT
in winnt.h which in didn't understand.
You must define _X86_ before including 'winnt.h'. Otherwise it won't
known on which architecture it's being compile and it won't define
CONTEXT.
On Wed, 6 Feb 2002, Patrik Stridvall wrote:
[...]
I also so got some other strange error with PCONTEXT
in winnt.h which in didn't understand.
You must define _X86_ before including 'winnt.h'.
Otherwise it won't
known on which architecture it's being compile and it won't define
Personally I think that the ultimate solution would be to
automatically generate the .dsp files from Makefile.in or otherwise.
May not be easy but you are pretty good with perl so if anyone can
pull it off it's you :-)
I don't think it is that difficult even for somebody less
Hmm. Well, I gave the MS headers one more try and discovered
a few not so nice things.
If you have a Wine specific include like below in a file:
#include heap.h
and this file heap.h in turn has a
#include winbase.h
it will include the Wine version of the file instead of the
MS version.
Alexandre Julliard wrote:
David Laight [EMAIL PROTECTED] writes:
This is the standard behaviour for C includes. It is actually usually
best to use not for all header files - unless you explicitely want
the file included from the current directory.
The problem is our makedep uses
On Wed, 6 Feb 2002, Steven Edwards wrote:
There are very little changes needed for the ReactOS port and only one
or 2 ReactOS specific headers. ReactOS only has private headers for the
kernel. Everything else we use is either in the mingw win32api or wine.
Nice. In that case replace ReactOS
34 matches
Mail list logo
