leanne wrote:
>
> We tried to print Chinese on notepad but failed.
> We found that WINE default only writes western characters
> to postscript. Is that true?
>
...
>
> I would like to ask if WINE will support multi-byte character printing?
>
The PostScript driver itself has rudimentary suppo
Dear all,
We tried to print Chinese on notepad but failed.
We found that WINE default only writes western characters
to postscript. Is that true?
Here is the .ps we produced from notepad on WINE.
We were trying to print a text of Chinese.
%%% 7 args
%!PS-Adobe-3.0
%%Creator:
On Wednesday 22 May 2002 00:27, Raul Dias wrote:
> Dustin Navea <[EMAIL PROTECTED]> wrote:
> >Hey, received a note from Riszanyi Zsolt asking to
> >implement use of $KDEHOME in wineshelllink. Well, I
> >took a look at it, and started to do that, but then I
> >realized that if we do that and they
"Mehmet YASAR" <[EMAIL PROTECTED]> wrote:
> On Win2K we have <54:77 ret=0>
> On Wine I have <0 :77 ret=1>
>
> We see that MS returns 0 as failure but modifies buffer[0] !
Could you please write a regression test for LoadString and
GetLocaleInfo to verify exact behaviour, especially for border
Andriy Palamarchuk <[EMAIL PROTECTED]> wrote:
>I think you can call Linux apps from Windows
>applications.
>
>> #This would let a call to a generic (search in
>> wine's
>> #Path) notepad and call a generic (in the user's
>> unix
>> #Path) gvim
>> "notepad.exe" = "gvim"
>>
>> #This would be a mo
Dustin Navea <[EMAIL PROTECTED]> wrote:
>Hey, received a note from Riszanyi Zsolt asking to
>implement use of $KDEHOME in wineshelllink. Well, I
>took a look at it, and started to do that, but then I
>realized that if we do that and they have 2 versions
>of KDE installed (i.e. Mandrake 8.2's way,
Hi-
I have been reading,
http://wine.codeweavers.com/docs/winelib-user/bindlls.shtml
http://www.unixodbc.org/doc/wine.html
in order to understand how to communicate with a windows odbc driver
from linux. I have a working windows setup for connecting to a remote
synergex database with ODBC driv
> > there were two files in this patch. Is there a specific reason, why they
> > were not completely applied? It looks to me that only parts of the first
> > file were applied.
>
> The server bits need more work, it's just a quick hack that I put
> together as proof of concept but it was not meant
On Mon, 2002-05-20 at 22:22, Dustin Navea wrote:
> why not have wine take advantage of syslog-ng
> by the by, if you don't know how syslog-ng is an easy
> way to find out, it prints out all messages it is
> given to tty12, so all the user would have to do is
> hit ctrl+alt+f12 read the message(s
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> Only for my understanding: Can you give (an) example(s) where the present
> behaviour is usefull against the non-granulat approach.
There are cases where applications come with their own replacements
for system dlls, for one reason or another. This happen
> "Alexandre" == Alexandre Julliard <[EMAIL PROTECTED]> writes:
Alexandre> Uwe Bonnes <[EMAIL PROTECTED]> writes:
>> Several possibilities: - several versions of winxx are available. You
>> are trying to run one executable in the context of another system -
>> you have an empt
[EMAIL PROTECTED] writes:
> Isn't there a requirement that the wine libraries be in a directory that is
> mappable to a windows path? I thought I ran into problems when I had forgotten
> to add an entry to my wine config to include my wine libraries... If so, then
> there will always be a windo
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> Several possibilities:
> - several versions of winxx are available. You are trying to run one
> executable in the context of another system
> - you have an empty directory and want to run application
> from the directory of the winxx available on your sy
> Builtin dlls don't have a full path because there is no associated
> file that we could point to (at least as seen from Windows). If this
> breaks your app it can be changed, but I'm not sure it will really fix
> anything. What does the app do with the filename?
To answer your last questio
...
Mehmet> printf("%d:%d ret=%d\n", buffer[0], buffer[1], i); return 0; }
Mehmet> On Win2K we have <54:77 ret=0> On Wine I have <0 :77 ret=1>
Mehmet> We see that MS returns 0 as failure but modifies buffer[0] !
Mehmet> The following patch should fix this.
Nice spot.
However I
> "Alexandre" == Alexandre Julliard <[EMAIL PROTECTED]> writes:
Alexandre> Uwe Bonnes <[EMAIL PROTECTED]> writes:
>> There are two cases: - is populated with some
>> executables. Calling them directly causes immediate crash
Alexandre> Only if windows/system is not configured
On Tue, May 21, 2002 at 12:34:11AM -0700, Francois Gouget wrote:
> On Tue, 21 May 2002, Uwe Bonnes wrote:
> [...]
> > Francois> Because that file is marked read-only, DeleteFile fails to
> > Francois> delete it, then causing the failure of all the other tests. I
> > Francois> checked a
On Tue, May 21, 2002 at 09:57:10PM +0200, Mehmet YASAR wrote:
> Hi,
>
> I've a small patch that allows me to get "Font Explorer Light" go
> further, both app are relying on a Windows bug.
>
> For example take the following code (see the log) :
>
> int main(int argc, char* argv[])
> {
> int i;
>
Joerg Mayer <[EMAIL PROTECTED]> writes:
> there were two files in this patch. Is there a specific reason, why they
> were not completely applied? It looks to me that only parts of the first
> file were applied.
The server bits need more work, it's just a quick hack that I put
together as proof o
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> There are two cases:
> - is populated with some executables. Calling them directly
> causes immediate crash
Only if windows/system is not configured as system directory. I don't
see why you'd want to do that.
> - for testing, I had comctl32.dll in the
Hey, received a note from Riszanyi Zsolt asking to
implement use of $KDEHOME in wineshelllink. Well, I
took a look at it, and started to do that, but then I
realized that if we do that and they have 2 versions
of KDE installed (i.e. Mandrake 8.2's way, KDE2 in
/usr and KDE3 in /opt), the icons wi
Eric Pouech <[EMAIL PROTECTED]> writes:
> Alexandre, will you accept a patch of this kind (it still
> can be enhanced, like storing the message id) ?
Only if there is evidence that Windows does it this way.
--
Alexandre Julliard
[EMAIL PROTECTED]
Alexandre,
there were two files in this patch. Is there a specific reason, why they
were not completely applied? It looks to me that only parts of the first
file were applied.
Thanks
Jörg
--
Joerg Mayer <[EMAIL PROTECTED]>
I found out that "pr
> "Alexandre" == Alexandre Julliard <[EMAIL PROTECTED]> writes:
Alexandre> Uwe Bonnes <[EMAIL PROTECTED]> writes:
>> at present, wine e.g. crashes if it finds user32.dll in the same
>> directory as the executable. To keep wine from using this DLL, the
>> dos-path to that dll h
--- Mehmet YASAR <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've a small patch that allows me to get "Font
> Explorer Light" go
> further, both app are relying on a Windows bug.
Excellent catch!
The app loads now. Both apps use the same library (see
the bugs description for details).
Look forward to
this patch is an attempt to solve the issue of passing
contextual information to winhlp32
it simply passes the data block required by the "WM_WINHELP"
(in quotes, because it's a registered window message) thru
the server, and reallocates it on the win32 size
it's a bit ugly because of the regis
Hi,
I've a small patch that allows me to get "Font Explorer Light" go
further, both app are relying on a Windows bug.
For example take the following code (see the log) :
int main(int argc, char* argv[])
{
int i;
char buffer[20];
buffer[0] = buffer[1] = buffer[2] = 77;
i = GetLocaleInfoA(0x409,
> Wine-dbg>cont
> Cannot pass on last chance exception. You must use
> cont
> Wine-dbg>
>
> What could I do ?
that's a know issue, I'll look at it.
A+
> It would be nice to be able to disable the win16 support but
> If ReactOS ever was to have a dos/win31 vdm I would still need
> This support in the dlls right? Or does wowexec just translate
> The win16 calls to win32?
no, you need more than that a pure API mapping
(some 16 bit API only exist a
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> at present, wine e.g. crashes if it finds user32.dll in the same directory
> as the executable. To keep wine from using this DLL, the dos-path to that
> dll has to be given explicit to the "-dll" argument, like
> wine h:/tmp/programm.exe --dll h:\\tmp\\use
> The user should not be required to have a graphical interface (usually
> X) running to be able to figure out what's going on.
> You can write console Windows applications and these should not require
> X to be running.
easier said than done. As of today wineconsole requires a real user32 up
and
[EMAIL PROTECTED] writes:
> 1. Would anyone object if I tried to fix wine to behave properly with
> GetModuleFileName returning the full path? I haven't dug into it yet, so I
> don't know how much effort will be required... Is there a reasons we have the
> current behaviour?
Builtin dlls do
> Huh, and what about this ??
>
> /***
> * GetModuleFileNameA (KERNEL32.@)
> * GetModuleFileName32 (KERNEL.487)
> *
> * GetModuleFileNameA seems to *always* return the long path;
> * it's
Hi -
I had a wine crash today that occurs before wine is properly
initialized, and therefore was pretty nasty to debug. However I traced
it down to the test program below.
The test program is loaded as a winelib app (i.e. a dll).
The program defines a global variable that is an instance of a cl
On Tue, May 21, 2002 at 10:45:14AM -0400, [EMAIL PROTECTED] wrote:
>
>
>
>
> So it looks to me like GetModuleFileName is always returning *only* the filename
> of the module, not the full path. MSDN says:
Huh, and what about this ??
/*
So it looks to me like GetModuleFileName is always returning *only* the filename
of the module, not the full path. MSDN says:
lpFilename
[out] Pointer to a buffer that receives the path and file name of the
specified module.
And I've come across some windows code that relies on
--- Paul Millar <[EMAIL PROTECTED]> a écrit : >
On Tue, 21 May 2002, [iso-8859-1] Sylvain Petreolle
> wrote:
> > tests/shreg.c:125: Test failed: (21,20)
> > tests/shreg.c:145: Test failed: (21,20)
>
Paul, I don't have a NT-like OS...
I configured wine to use --winver winme.
> c.f. Bugzilla id 6
Of course, I don't claim X11 license over all the patch
However, the Wine only part (the mpgl3.c file) is under an X11 license.
The rest remains LGPL
The ReWind tree will likely not include the LGPL code but propose configure options to
add the mpglib
A+
> > "Eric Pouech" <[EMAIL PROTECTED]> wro
> "Eric Pouech" <[EMAIL PROTECTED]> wrote:
>
> > this patch implements an ACM MP3 decoder (only, no coder)
> > it is based on the mpglib (which is now LGPL, and which is
> > included in the patch)
>
> If you base your code on the LGPL'ed code, you can't claim
> it has an X11 license.
Of course
On Tue, 21 May 2002, Uwe Bonnes wrote:
[...]
> Francois> Because that file is marked read-only, DeleteFile fails to
> Francois> delete it, then causing the failure of all the other tests. I
> Francois> checked and the same happens on non-smb drives (c:\). I also
> Francois> checked
On Tue, 21 May 2002, [iso-8859-1] Sylvain Petreolle wrote:
> tests/shreg.c:125: Test failed: (21,20)
> tests/shreg.c:145: Test failed: (21,20)
c.f. Bugzilla id 681 ...
http://bugs.winehq.com./show_bug.cgi?id=681
Cheers,
Paul Millar
> "Francois" == Francois Gouget <[EMAIL PROTECTED]> writes:
Francois> I tested the 'file' regression test on NT4 and XP and it fails
Francois> on both. Here is where the error occurs:
Francois> tests/file.c:236: Test failed: DeleteFile failed (5).
Francois> tests/file.c:240:
42 matches
Mail list logo
