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
Looking at Bugzilla bug 446 and the msdn, it would appear (and testing
confirms) that:
rc = SetFileAttributes(fff, FILE_ATTRIBUTE_NORMAL |
FILE_ATTRIBUTE_READONLY );
_is_ valid and sets readonly. In the msdn However, all other values
override FILE_ATTRIBUTE_NORMAL.
The wine code (files\file.c)
On Fri, 3 May 2002, Duane Clark wrote:
A little more regression testing...
The 5/1 dsound patch causes this on one of my apps:
...
err:wave:DSDB_MapPrimary (0x4568ca04): Could not map sound device for
direct access (Input/output error)
Before the patch Riven falls back to winmm, making the
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
You really can't use the .spec.c file. The result
won't be a proper PE
dll, and you would need the Wine loader to patch
things up at run-time
to make it look like a real dll. It's much easier to
build a true PE
dll in the first place.
Ok cool, once I send the last of my current patches in
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
and I was wondering if it's still true.
yes, and it will likely remain so
native user32 requires lots of bits from native
kernel (which are no longer available because of
adress space separation)
A+
and I was wondering if it's still true.
yes, and it will likely remain so
native user32 requires lots of bits from native
kernel (which are no longer available because of
adress space separation)
From what I recall, the core problem was that shared DLL
segments no longer worked after
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
21 matches
Mail list logo
