tir, 16.03.2004 kl. 03.20 skrev Vincent Béron:
> Hi folks,
>
> Since wine.inf is now used as the source for the default values for the
> registry (via rundll32), importing it absolutely needs X (whereas the
> older regedit method didn't when importing a .reg file). This can be a
> problem for peop
Vincent Béron <[EMAIL PROTECTED]> writes:
> Since wine.inf is now used as the source for the default values for the
> registry (via rundll32), importing it absolutely needs X (whereas the
> older regedit method didn't when importing a .reg file). This can be a
> problem for people running wineinst
Hi folks,
Since wine.inf is now used as the source for the default values for the
registry (via rundll32), importing it absolutely needs X (whereas the
older regedit method didn't when importing a .reg file). This can be a
problem for people running wineinstall via ssh from a Windows box.
Is ther
On Tue, Mar 16, 2004 at 12:09:24AM +0200, Shachar Shemesh wrote:
> Can someone remind me again why we can't have GPL DLLs in the tree?
> Doesn't the "call through documented interface blah blah blah not
> derived work" argument cause the license for each two DLLs in Wine to be
> independant?
Ba
"Martin Fuchs" <[EMAIL PROTECTED]> writes:
> Alexandre - is there any thing wrong with this patch?
Yes there has to be something wrong, you create a sei_tmp structure
but you never actually use it. I'm not sure what your intent was.
--
Alexandre Julliard
[EMAIL PROTECTED]
Filip Navara <[EMAIL PROTECTED]> writes:
> I'm sending this patch second time. Is there any reason why it wasn't
> commited previously or it just got lost?
It will get in faster if you send a non wrapped version ;-)
--
Alexandre Julliard
[EMAIL PROTECTED]
Tom <[EMAIL PROTECTED]> writes:
> I see these guys as our friends, comrades and they have to my simple
> knowledge agreed to cross licence *all* there work th the LGPL so
> *we* not them can use there hard work. I have yet to hear of a
> single incidence where *wine* code was cross licensed ba
> duplicated. Sometime our developers dont want to wait on a
> submit->modify->comit/reject->merge->submit loop of Winehq so they put
> code in to ReactOS cvs first. Does it mean sometimes work gets
> duplicated? Sometimes yes. Its going to happen. Rather by mistake, or
> design some effort will be
Peter Hyman <[EMAIL PROTECTED]> writes:
> The following compile time error occurs:
>
> make[2]: Entering directory `/mnt/src/src/wine/dlls/glu32'
> gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__
> -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno
I'm sorry if this turns out to be a troll. That is not my intention.
Can someone remind me again why we can't have GPL DLLs in the tree?
Doesn't the "call through documented interface blah blah blah not
derived work" argument cause the license for each two DLLs in Wine to be
independant?
On 15.03.2004 23:01:56 Martin Fuchs wrote:
> Well to take up for the ReactOS folks Martin and Ge have done one hell
> of a fine job on shell32 !!
> And they have given every thing back.. Not once but twice!
> As AJ was on vacation at the time and Martin & Ge spent alot of time
> i'm sure spliti
Jeremy Newman <[EMAIL PROTECTED]> writes:
> ChangeSet ID: 11483
>
> Log message:
> set the lang
Did you check if it was needed? I thought my patch took
care of this in a language/locale neutral way by opening the
report file in :raw mode. I'd like to not if it's not the case.
--
Feri.
> From: Tom
>
> Well to take up for the ReactOS folks Martin and Ge have
> done one hell of a fine job on shell32 !! And they have given
> every thing back.. Not once but twice! As AJ was on vacation
> at the time and Martin & Ge spent alot of time i'm sure
> spliting the patch up into sma
Dimitrie O Paun wrote:
Folks, my applogies, the message wasn't intended as a flame.
And my applogies for calling your post a flame when it wasn't.
I think were all friends here so... we should have fun and move on.
Sorry Dimi, if i've caused any misunderstandings!
Tom
On Mon, 15 Mar 2004, Tom wrote:
> To sum this up. *WE* every sigle wine user all 100,000 at the
> last estate
> should be glad that were in the company of the people at
> http:www.reactos.com
> as they are *our* friends & comrades and not someone to flame!!!
Folks, my applogies, the me
Paul van Schayck wrote:
Hey,
A start to the AppDB. The whole system is using the strongly depreceated auto
registered globals. (The DB was made before this rule was made/enforced)
This patch will just fix that problem for the browsing trough the DB.
It will also check if we really have a numeric
Dimitrie O Paun wrote:
On Mon, 15 Mar 2004, Steven Edwards wrote:
We have a cards.dll in the ReactOS tree that we wanted to merge with
Winehq but the license of the bitmaps was GPL and not LGPL. Do you want
to take a look at our implementation and see if there is anything you
can use from it?
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> Time and again, it seems that the ReactOS folks produce a lot of
> throw-away code, by keeping it in the ReactOS tree. I've lost count
> on how many times this happened in the past, don't you guys get it
> that we should work together on this stuf
On Mon, 2004-03-15 at 19:39, Eric Pouech wrote:
> if you don't fix the fixme, it will also be unusable. So, it has been
> put there some reasons: don't fix the consequences, fix the cause !!!
Well, there are a whole ton of things that lack proper error checking
etc in Wine - if we used a fixme fo
Fabian Cenedese a écrit :
Hi
This project is a curses based frontend for gdb. Maybe there are some
things useful for winedbg. The source view sure would make debugging
easier.
fyi, most (graphical) gdb front ends work with winedbg (in gdb proxying
mode). See the docu for the details (this include
Mike Hearn a écrit :
This output can interfere with shell/wcmd processes, or at least make them
harder to use. If we put every todo item in a fixme wine would be unusable
anyway :)
if you don't fix the fixme, it will also be unusable. So, it has been
put there some reasons: don't fix the consequen
On Mon, 15 Mar 2004, Steven Edwards wrote:
> We have a cards.dll in the ReactOS tree that we wanted to merge with
> Winehq but the license of the bitmaps was GPL and not LGPL. Do you want
> to take a look at our implementation and see if there is anything you
> can use from it?
Time and again, i
--- Sam <[EMAIL PROTECTED]> wrote:
> This is a clean room implementation of cards.dll.
> While it is not really an official windows system dll,
> it is almost always present, and several applications
> depend on it.
We have a cards.dll in the ReactOS tree that we wanted to merge with
Winehq but th
Hallo,
perhaps out tool section should mention Unshield from SynCE
http://synce.sourceforge.net/synce/
It allows to exctract IS 5|6 cabinet files
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516
I have opened up the source to the WineHQ appdb. Anyone with spare time
and some PHP skills is welcome to help improve it.
The tree has not been touched in over a year. I did some work to clean
it up for this import, and thats about it. I will be available to answer
any questions on it.
Check it
On Mon, Mar 15, 2004 at 06:49:00PM +0300, Phil Krylov wrote:
> Hello Huw,
>
> Monday, March 15, 2004, 2:27:41 PM, you wrote:
>
> HDMD> Hi Phil,
>
> HDMD> Could you send me a +relay,+message,+mdi log of this please?
>
> It's around 1M in size when bzipped; do you want me to send it to your
> ema
Kernel 2.6.4
gcc = 3.2.3
The following compile time error occurs:
make[2]: Entering directory `/mnt/src/src/wine/dlls/glu32'
gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__
-D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing
-gstab
On March 14, 2004 8:03 pm, Robert Shearman wrote:
> + * This code was audited for completeness against the documented features
> + * of Comctl32.dll version 6.0 on Mar. 14, 2004, by Robert Shearman.
Nice! Right now I have toolbar listed at 70% completion.
Should I change that (when I said 70%, I w
This output can interfere with shell/wcmd processes, or at least make them
harder to use. If we put every todo item in a fixme wine would be unusable
anyway :)
Mike Hearn <[EMAIL PROTECTED]>
Replace SetConsoleCtrlHandler fixme with a comment
Index: dlls/kernel/console.c
==
Hi
This project is a curses based frontend for gdb. Maybe there are some
things useful for winedbg. The source view sure would make debugging
easier.
http://cgdb.sourceforge.net/
bye Fabi
Argh, forget my previous message. I must have been utterly distracted.
Rolf Kalbermatter
-Original Message-
From: Rolf Kalbermatter [mailto:[EMAIL PROTECTED]
Sent: Mon, March 15, 2004 1:04 PM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: Re: Munge /r and /n in HTTP_HttpSendRequ
> "Rolf" == Rolf Kalbermatter <[EMAIL PROTECTED]> writes:
Rolf> Argh, forget my previous message. I must have been utterly
Rolf> distracted. Rolf Kalbermatter
And my postings were full of typos... Argh
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlo
> "Rolf" == Rolf Kalbermatter <[EMAIL PROTECTED]> writes:
Rolf> Uwe Bonnes wrote:
>> The test for nLen is a good idea. But with nLen =
>> strlen(lpwhr->lpszPath); lpwhr->lpszPath[nLen] should give the
>> terminating NULL to my understanding...
>>
>> Or am I off by one
> "Rolf" == Rolf Kalbermatter <[EMAIL PROTECTED]> writes:
Rolf> Uwe Bonnes wrote:
>> The test for nLen is a good idea. But with nLen =
>> strlen(lpwhr->lpszPath); lpwhr->lpszPath[nLen] should give the
>> terminating NULL to my understanding...
>>
>> Or am I off by one
Uwe Bonnes wrote:
>The test for nLen is a good idea. But
>with nLen = strlen(lpwhr->lpszPath); lpwhr->lpszPath[nLen] should give the
>terminating NULL to my understanding...
>
>Or am I off by one?
According to my ANSI C book strlen() returns the number of characters in
a string NOT including th
Hi,
the whole yesterday I was hunting a problem when staring a program with
wine. Now I'm at a point I don't know what to do next. May be somebody
can give me an hint?
Here are the last lines of the trace+ddraw output:
trace:ddraw:Main_DirectDrawSurface_Lock
(0x40405b50)->Lock((nil),0x408bf960,
On Sun, Mar 14, 2004 at 02:16:42AM +0300, Phil Krylov wrote:
> Hello Huw,
>
> Tuesday, March 9, 2004, 1:46:20 PM, you wrote:
>
> HDMD> Huw Davies <[EMAIL PROTECTED]>
> HDMD> We need to at least refresh the window menu in ChildActivate,
> HDMD> so for now remove the 'is alr
> "Rolf" == Rolf Kalbermatter <[EMAIL PROTECTED]> writes:
Rolf> Uwe Bonnes <[EMAIL PROTECTED]> wrote:
>> This makes Xilinx webupdate.exe see the Servicepack
>>
>> + else + /* remove \r and \n*/ + { + int nLen =
>> strlen(lpwhr->lpszPath); + while ((lpwhr->lpszPath[nLen-1]
Mike McCormack <[EMAIL PROTECTED]> writes:
> Peter Riocreux wrote:
> > Is there a noddy Wine app that will just print out all the
> > environment it sees to I can be *absolutely* sure that my app is
> > seeing it?
>
> run "wine wcmd", then type "set" at the prompt.
Bingo, thanks. It should in
On Sun, 14 Mar 2004 14:22:32 +0100, Uwe Bonnes wrote:
> Mike,
>
> it looks like the patch dosen't turn on debugging for new processes that
> where started after debugging for the parent process was turned on...
Good point, I hadn't thought of that. Not sure what the best way to fix
that is ... if
Problem:
The wphsesam.dll linked with libssvlux.so
Contents libssvlux.def:
LIBRARY libssvlux.so
EXPORTS
[EMAIL PROTECTED] @1
[EMAIL PROTECTED] @2
[EMAIL PROTECTED] @3
[EMAIL PROTECTED] @4
[EMAIL PROTECTED] @5
[EMAIL PROTECTED] @6
[EMAIL PROTECTED] @7
[EMAIL PROTECTED] @8
41 matches
Mail list logo
