On October 9, 2003 09:58 pm, Geoff Thorpe wrote:
> look/feel/use, like "wine-cvs". I would have personally thought that
> attachments make more sense, because separating patches from text can be
> ambiguous and it's not as easy to send multiple patches (eg. when
> submitting two alternative patches
Alexandre Julliard wrote:
In some cases parameters to API functions are not declared const even
though they really are const; some of these could be fixed. Notably,
all the 16-bit ones can be freely changed since no external code
depends on them. Some 32-bit ones can probably be changed too, like
a
On October 9, 2003 08:50 pm, Alexandre Julliard wrote:
>We can now use the standard DllMain as entry point.
Cool, what about the one in user32:
[EMAIL PROTECTED] wine.src]$ grep DLLMAIN `find -name "Makefile.in"`
./dlls/user/Makefile.in:DLLMAIN = [EMAIL PROTECTED]
It's the last one, we
Do other programs that will call ALSA APIs such as alsamixer and aplay work
properly?
Sylvain Petreolle wrote:
> After an update to current cvs, dsound test with winealsa is failing.
> cature.c is ok (1 test only) but propset.c and dsound.c fail.
>
> They give the same error at almost every test
Hi guys,
I’m running DameWare Mini Remote Control under Wine
here. This is a pretty cool setup as some of our clients
have no windows servers (only linux), and the idea is that
we can VNC to a Linux firewall or file server and then use DameWare through
Wine to take control of PCs that
Glad to hear someone is taking this up! :-)
As for the approach, I think if you do take the approach of letting
"unmatched" emails through, you should perhaps mangle the subject or
prepend some template text to the body of the email. Otherwise it's less
clear that someone will send a polite not
[EMAIL PROTECTED] writes:
> (See attached file: patch_callbacks_return.txt)
The idea is that the DC interface functions should behave just like
the corresponding APIs, so if the API returns the old value the DC
function should do that too. This way it guarantees that we can
implement the full beh
[EMAIL PROTECTED] writes:
> (See attached file: patch_emf_updatebbox.txt)
Is there a reason you are not using LPtoDP() here?
--
Alexandre Julliard
[EMAIL PROTECTED]
On October 9, 2003 03:02 pm, Dimitrie O. Paun wrote:
> On Thu, 9 Oct 2003, Bill Medland wrote:
> > Having just fallen over this might I suggest that the configure check
> > also checks for lynx; if lynx is not installed then even though
> > docbook2txt is present it fails.
> >
> > Or is there a ver
On Wed, 8 Oct 2003 21:53, Patrik Stridvall wrote:
> The significant effort requirement is for EACH fact seen by ITSELF.
This is certainly not the case in Australia, NZ and the UK.
On Thu, 9 Oct 2003, Bill Medland wrote:
> Having just fallen over this might I suggest that the configure check also
> checks for lynx; if lynx is not installed then even though docbook2txt is
> present it fails.
>
> Or is there a version of docbook2txt that doesn't depend upon lynx?
I have no
On Thu, 9 Oct 2003, Shachar Shemesh wrote:
> I don't think that's a good idea. I think "looks like text" is
> difficult. I don't know how Japanese resources look like, nor how
> Keyboard layouts in Spanish. I'd rather go with the file extension.
file(1) is your friend. Mime types are completely
Daniel Marmier <[EMAIL PROTECTED]> writes:
> There has to be a better solution. Perhaps something like:
>
> #define FAKE_LPSTR(s) ((LPSTR)(ptrdiff_t)(s))
>
> WriteSpool16( physDev->job.hJob, FAKE_LPSTR(buf), strlen(buf) );
>
> Where the intermediate cast to ptrdiff_t serves to shut-up
Dimitrie O. Paun wrote:
On Thu, 9 Oct 2003, Shachar Shemesh wrote:
I think I can do that. What I suggest:
Attachments must be either .diff or .patch. If you want, they can be bz2
or gz compressed. Mime type is disregarded. Also, the mail must be
non-HTML (or, at least, must have a text only
On Thu, 9 Oct 2003, Shachar Shemesh wrote:
> I think I can do that. What I suggest:
> Attachments must be either .diff or .patch. If you want, they can be bz2
> or gz compressed. Mime type is disregarded. Also, the mail must be
> non-HTML (or, at least, must have a text only component). Emails t
On October 8, 2003 12:16 pm, Dimitrie O. Paun wrote:
> On Wed, 8 Oct 2003, Alexandre Julliard wrote:
> > Actually it seems there is now (finally) a docbook2txt tool, we should
> > probably use that instead.
>
> Indeed.
>
> ChangeLog
> Dimitrie O. Paun <[EMAIL PROTECTED]>
> Use docbook2txt t
Geoff Thorpe wrote:
Couldn't the wine-patches list server simply pull the emails apart and
reconstruct them according to some simple rules? I'm no Perl hacker, but
I'm sure this could be stitched together easily by someone who is.
I think I can do that. What I suggest:
Attachments must be eit
On Wed, 2003-10-08 at 21:58, Dimitrie O. Paun wrote:
> BTW, how far away are we from always compiling with -Wwrite-strings?
Well, much warnings are gone, but we're still some patches (and days)
away, because I started with the most obvious ones, and I am now running
into the less obvious.
Most of
I'm getting this message
cvs update -PAd
cvs [update aborted]: connect to rhlx01.fht-esslingen.de(129.143.116.10):2401
failed: Connection refused
will this be fixed?
Hello,
For two days, I have been having crash when I start wine.
Here is an example of the backtrace
Wine-dbg>bt
Backtrace:
=>0 0x40064525 (LdrInitializeThunk+0x205(main_file=0x4, unknown2=0x0,
unknown3=0x0, unknown4=0x0) [loader.c:1805] in
libntdll.dll.so) (ebp=40832f20)
1 0x4025b4bf (start_p
> The best is to use the Rtl*ByteSwap functions from winternl.h.
That is certainly the best solution --- I hadn't noticed that those had been
added... I'll try redoing our swapping code with them and make sure it all
works...
Warren
> But then you are doing extra work for the "normal" case, and you are
> also making the code less readable; not a good trade-off IMO.
Well --- trading a memory allocation for an extra comparision instruction makes
it a bit trickier to decide, but I take your point.
> You
> could always move
On October 9, 2003 08:46 am, Dimitrie O. Paun wrote:
> On October 9, 2003 08:11 am, Sylvain Petreolle wrote:
> > As an alternative, if welcome on the list, we can zip/bzip the
> > patch, this way they wont be mangled by Notes.
>
> No, this is most definitely not welcome on the list...
Couldn't th
After an update to current cvs, dsound test with winealsa is failing.
cature.c is ok (1 test only) but propset.c and dsound.c fail.
They give the same error at almost every test
ALSA lib pcm.c:1908:(snd_pcm_open_noupdate) Unknown PCM
err:wave:wodOpen Error open: Inappropriate ioctl for device
fix
On October 9, 2003 08:11 am, Sylvain Petreolle wrote:
> As an alternative, if welcome on the list, we can zip/bzip the patch,
> this way they wont be mangled by Notes.
No, this is most definitely not welcome on the list...
--
Dimi.
As an alternative, if welcome on the list, we can zip/bzip the patch,
this way they wont be mangled by Notes.
> >
> >
> Can't you just call your diffs "something.txt" and attach them?
>
=
Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net)
ICQ #170597259
Say NO to software pa
26 matches
Mail list logo
