On 12/17/05, Segin <[EMAIL PROTECTED]> wrote:
> Aric Cyr wrote:
> James Liggett cox.net> writes:
>
>
>
> Hi Aric,
> If you see stack corruption like this, you might want to try compiling
> with optimization turned off. put the -O0 (a capital letter O followed
> by a zero) flag in your CFLAGS wh
Aric Cyr wrote:
James Liggett cox.net> writes:
Hi Aric,
If you see stack corruption like this, you might want to try compiling
with optimization turned off. put the -O0 (a capital letter O followed
by a zero) flag in your CFLAGS when you run configure. I had a similar
situation w
James Liggett cox.net> writes:
> Hi Aric,
> If you see stack corruption like this, you might want to try compiling
> with optimization turned off. put the -O0 (a capital letter O followed
> by a zero) flag in your CFLAGS when you run configure. I had a similar
> situation where gcc was using fuzz
Markus Goemmel wrote:
> My partner and I are developing Windows applications
> (http://www.emtec.com). Seeing Wine some months ago fascinated
> me a lot, so since then I'm spending one or two hours a day
> trying to bring our applications to work under Wine, too...
>
> But it's clear that there are
Friday, December 16, 2005, 11:26:28 PM, Scott Ritchie wrote:
> On Fri, 2005-12-16 at 19:48 +0100, Alexandre Julliard wrote:
>> The goal is not to prevent regressions between every minor point
>> release, it's to make releases frequently enough that regressions can
>> be found and fixed quickly, so
Friday, December 16, 2005, 11:20:34 PM, Dan Kegel wrote:
> On 12/16/05, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
>> > $ wine/wine .wine/drive_c/windows/system32/regsvr32.exe
>> > wine: cannot open builtin library for
>> > L"Z:\\home\\dank\\.wine\\drive_c\\windows\\system32\\regsvr32.exe":
>> > /
On Fri, 2005-12-16 at 19:48 +0100, Alexandre Julliard wrote:
> The goal is not to prevent regressions between every minor point
> release, it's to make releases frequently enough that regressions can
> be found and fixed quickly, so that they don't creep into the next
> major release. Now, if you t
On 12/16/05, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
> > $ wine/wine .wine/drive_c/windows/system32/regsvr32.exe
> > wine: cannot open builtin library for
> > L"Z:\\home\\dank\\.wine\\drive_c\\windows\\system32\\regsvr32.exe":
> > /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header
>
>
Friday, December 16, 2005, 10:45:06 PM, Dan Kegel wrote:
> On 12/16/05, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
>> > $ rm -rf .wine
>> > $ wine/wine notepad.exe
>> > /home/dank/.wine updated successfully.
>> > $ find .wine -name regsvr32.exe -ls
>> > 46694870 lrwxrwxrwx 1 dank dank
On 12/16/05, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
> > $ rm -rf .wine
> > $ wine/wine notepad.exe
> > /home/dank/.wine updated successfully.
> > $ find .wine -name regsvr32.exe -ls
> > 46694870 lrwxrwxrwx 1 dank dank 40 Dec 17 03:35
> > .wine/drive_c/windows/system32/r
Friday, December 16, 2005, 9:08:19 PM, Dan Kegel wrote:
> On 12/15/05, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
>> > wine: cannot open builtin library for
>> > L"C:\\windows\\system32\\regsvr32.exe":
>> > /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header
>> >
>> > This is with 0.9.3 b
Ability Office has a Linux version done with winelib, but
I wanted to go whole hog and run the Windows version
using wine 0.9.3. There were a few issues along the way.
I started by downloading their normal Windows setup program:
wget http://www.ability.com/download4/ability4_14/setup.exe
wine
On 12/15/05, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
> > wine: cannot open builtin library for
> > L"C:\\windows\\system32\\regsvr32.exe":
> > /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header
> >
> > This is with 0.9.3 built on fc3.
>
> Looks like a case of overwritten regsvr32.exe
On Fri, 16 Dec 2005 19:06:13 +0100, you wrote:
>Also visually I do not see the failure that you are supposedly fixing.
Nah, I did not look straight. The flaw is visible but does not cause the
test to fail.
Rein.
Tony Lambregts <[EMAIL PROTECTED]> writes:
> Perhaps it's partly a matter of perception then.
>
> If I understand you 0.9 was a major release then, and 0.9.1 and
> company are minor releases, with the next major release being 1.0. So
> I anticipate that we will have a major freeze before 1.0 jus
Am Freitag, 16. Dezember 2005 19:48 schrieb Alexandre Julliard:
> The idea is that people should test the releases. The point of the
> beta phase is to encourage end users to test, and for this to happen
> they need to be able to get binary packages, which is what the
> releases are about. This is
On 12/16/05, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Tony Lambregts <[EMAIL PROTECTED]> writes:
>
> > Well that is a real sore spot with me. You know that I am a strong
> > supporter of wine but it really concerns me that we have gone beta and
> > not addressed preventing regessions from ge
> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes:
Peter> Michael Jung schrieb:
>> On Friday 16 December 2005 15:41, Peter Beutner wrote:
>>> Don't get me wrong I still think it is perfectly valid that wine is
>>> doing that sort of hack to get existing windows applications
Seeing as how I know nothing much about msi I thought I'd just
point out the error and ask someone more knowledgeable to do
something about it.
Basically on msiexec a VBA6.msi:
dialog.c - msi_dialog_oncreate includes
dialog->default_font = msi_dup_property (.., "DefaultUIFont");
Later on that
Tony Lambregts <[EMAIL PROTECTED]> writes:
> Well that is a real sore spot with me. You know that I am a strong
> supporter of wine but it really concerns me that we have gone beta and
> not addressed preventing regessions from getting into our releases in
> any way. We currently have no freeze or
Michael Jung schrieb:
On Friday 16 December 2005 15:41, Peter Beutner wrote:
Don't get me wrong I still think it is perfectly valid that wine is doing
that sort of hack to get existing windows applications working but you
really shouldn't advertise it as a solution to platform independence and
e
Dmitry Timoshkov schrieb:
"Peter Beutner" <[EMAIL PROTECTED]> wrote:
Why? Wine is effectively just a different toolkit, like QT or GTK
(albeit much larger) that give applications a Windows, KDE and Gnome
look respectively. Take Notepad for example - with some slight
modifications you could eve
On Fri, 16 Dec 2005 22:17:29 +0800, you wrote:
>Hello,
>
>here is hopefully a correct version of the patch.
>
>Changelog:
>Rein Klazes <[EMAIL PROTECTED]>
>Add another set of ScrollDC tests.
>Dmitry Timoshkov <[EMAIL PROTECTED]>
>Add a ScrollDC test with NULL clipping rect.
>Sc
Sorry, just got a message of someone (James Hawkins) telling me he's
working on the function and it's best not modified before his patches
get applied :-)
After that, we''ll see whether any of this still finds a need :-)
Jeremy White wrote:
>>Not that I mean to sound like a pessimist, but I'm really just calling
>>it as I see it. No offense to anyone intended. :)
>
>
> This, in a nutshell, is Wine's greatest challenge
> (stepping even outside ISV boundaries for a minute).
>
> I believe, either because I'm insane (t
On 12/16/05, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Jesse Allen <[EMAIL PROTECTED]> writes:
>
> > Changes:
> > Add support for I64 integer sizes in printf. Handle I and I32 sizes
> > using libc's printf.
>
> The tests fail:
>
> printf.c:45: Test succeeded inside todo block: Problem with l
Joris Huizer wrote:
When this patch is accepted I'll submit the rest (that is, the code
using these functions)
I appreciate somebody is spending the time to clean up that function.
Unfortunately, a patch adding functions that aren't yet used is not
likely to be accepted.
Secondly, even if
On Friday 16 December 2005 15:41, Peter Beutner wrote:
> The point is that it won't be integrated in neither kernel or glibc.
Integration in the loader is just one possibility. Wine needs to load code at
fixed positions. Thus, there has to be a possibility to do it. Currently we
do it in a way
This patch adds a simple structure to contain commonly-requested file
properties (named `struct fileops_file_data`, wondering whether that
name should that change?)
Functions added:
-void printFileData():
debugging function, printing contents of a `struct fileops_file_data` thing;
-int shfileo
> The point is that it won't be integrated in neither kernel or glibc. At
> least I can't imagine that this will happen. Why should anybody integrate
> another binary loader/memory layout into the kernel/libc where there is
> already a fully working one?
> Just because some people don't want to
Michael Jung schrieb:
On Friday 16 December 2005 12:54, Peter Beutner wrote:
Let's just look at the problem with the memory layout. Wine relies on the
possibility to load certain codes at fixed addresses as this is how it
works under windows. Linux choose exact the opposite direction, i.e. try
"Peter Beutner" <[EMAIL PROTECTED]> wrote:
Why? Wine is effectively just a different toolkit, like QT or GTK
(albeit much larger) that give applications a Windows, KDE and Gnome
look respectively. Take Notepad for example - with some slight
modifications you could even modify the File Open dia
On Freitag 16 Dezember 2005 10:49, Peter Beutner wrote:
> Robert Shearman schrieb:
> > Peter Beutner wrote:
> >> Maybe it's just me but when reading all this I got the feeling that
> >> writing windows applications(which work with wine) is just *the* way
> >> to go.
> >
> > It is the cheapest way
On Friday 16 December 2005 12:54, Peter Beutner wrote:
> Let's just look at the problem with the memory layout. Wine relies on the
> possibility to load certain codes at fixed addresses as this is how it
> works under windows. Linux choose exact the opposite direction, i.e. try to
> ensure that lib
James Liggett schrieb:
I really fear that this will end up with vendors loudly advertising linux support and
proudly putting linux stickers on their products where everything you find inside are just
the same windows .exe files and a readme stating that these will work fine with wine.
Which at
Michael Jung schrieb:
On Friday 16 December 2005 10:49, Peter Beutner wrote:
Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff
wine has to do to emulate the windows process environment.
I guess in the long term a project like wine, if successfull, doesn't have to
l
Hi,
> I'll vote against a wine-isv list. History has shown we're not
> responsible enough to have many mailing lists. Sure, if it takes
> off.. great. But more than likely we'll be having a discussion on
> wine-devel in 18 months about getting rid of the list because only a
> handful of people
Jesse Allen <[EMAIL PROTECTED]> writes:
> Changes:
> Add support for I64 integer sizes in printf. Handle I and I32 sizes
> using libc's printf.
The tests fail:
printf.c:45: Test succeeded inside todo block: Problem with long long
printf.c:46: Test succeeded inside todo block: return count wrong
> > Second the required 3d functionality is VERY limited. Basicly the
only
> > thing the videocard needs support is texturing which all cards do.
>
> But that's obviously wrong - the video *driver* also needs to support
it.
> And the current 3D video driver situation in Linux is horrible.
>
Vijay Kiran Kamuju <[EMAIL PROTECTED]> writes:
> Can we change our linuxwrappers for a work-around?
No, there's nothing we can do, it's due to the way glibc references
pthread functions internally. It would have to be fixed in glibc, but
that's unlikely to happen, especially since linuxthreads is
Can we change our linuxwrappers for a work-around?
Thanks,
Vijay
On 12/16/05, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Cihan Altinay <[EMAIL PROTECTED]> writes:
>
> > Thanks for the info. I am running a Xen[1] system which currently has to
> > emulate unsupported lib/tls library calls. And
Alexandre Julliard wrote:
> > Do you think the dependency of wine on TLS will stay in future versions?
>
> Yes, it can't be fixed, our linuxthreads wrappers can't work in glibc
> 2.3. They work fine with glibc 2.2 though.
TLS can work with Xen, but you have to patch glibc and use
-mno-tls-direct-s
On Friday 16 December 2005 10:49, Peter Beutner wrote:
> Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff
> wine has to do to emulate the windows process environment.
I guess in the long term a project like wine, if successfull, doesn't have to
live with the restriction
Robert Shearman schrieb:
Peter Beutner wrote:
IMHO all this stuff goes a bit too much into the wrong direction.
I really fear that this will end up with vendors loudly advertising
linux support and proudly putting linux stickers on their products
where everything you find inside are just the
Cihan Altinay <[EMAIL PROTECTED]> writes:
> Thanks for the info. I am running a Xen[1] system which currently has to
> emulate unsupported lib/tls library calls. And that makes the system very
> slow. Therefore, the Xen maintainers strictly recommend moving the /lib/tls
> folder out of the way. Ev
> Not that I mean to sound like a pessimist, but I'm really just calling
> it as I see it. No offense to anyone intended. :)
This, in a nutshell, is Wine's greatest challenge
(stepping even outside ISV boundaries for a minute).
I believe, either because I'm insane (the likely
explanation), or bec
46 matches
Mail list logo
