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 acceptable way so, as I said, perhaps we will solve them all eventually. :-)
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 reasons so making the RC files 100% Microsoft compatable wouldn't be a good idea either.
Not sure how to solve this in a good way other than actually using WRC on Windows of course.
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 reasons so making the RC files 100% Microsoft compatable wouldn't be a good idea either.
Not sure how to solve this in a good way other than actually using WRC on Windows of course.
Or maybe use Borland's resource compiler... it supports embedded binary resources (I think wrc's syntax was made Borland-compatible).
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 undrestand :)) the diffs. However, that's not the case for images, even when stored in a text format.
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?
"Dimitrie O. Paun" dpaun@rogers.com 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 time a binary file changes.
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 images in wine, the diff has problably been larger than a complete gif/bmp/jpg in most cases.
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Joerg Mayer jmayer@loplof.de 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 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.
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. It has nothing to do with CVS, but rather with people using the diffs. That's a good point, but it's been clouded a by (subconsciously) blaming CVS. Anyhow, how many people are still using those diffs?
And say, even if we had binary .gifs in the tree, the diffs are not useless by any stretch of imagination, as the images are non-functional. That is, even if the diff does not catch the image change, there's no big harm done. And how often do they change nowadays?
In other words, it's a good point in theory, but I doubt it's a big problem in practice...
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 don't get annoyed by it...
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 of storing stuff as plain text is to be able to look at (and undrestand :)) the diffs. However, that's not the case for images, even when stored in a text format.
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?
On a project I worked on why used binary for Word documents, VHDL sym files and Linux kernels. No problems at all.
-
Alexandre Julliard -
Dimitrie O. Paun -
Jakob Eriksson -
Joerg Mayer -
Ove Kaaven -
Patrik Stridvall