> The first is a display problem of edit boxes; for some reason the text
> (numbers) are displaying left justified, instead of right justified. The
> edit boxes are definitely set for right justified and display fine in
> Windows.
This is a known problem. Our edit control does not currently suppor
Shaun Green wrote:
The first is a display problem of edit boxes; for some reason the text
(numbers) are displaying left justified, instead of right justified. The
edit boxes are definitely set for right justified and display fine in
Windows.
The second bug is that when I multi-select files to per
Mike Hearn wrote:
wine_pthread_* functions are supposed to be defined in the
wine-pthread/wine-kthread binaries. The DSOs then have their symbols
resolved to the executable at runtime. I don't know why this isn't
working for you but it's almost certainly related to using
Solaris/SPARC.
It looks
When using CVS version of Wine I cannot get much debug:
[EMAIL PROTECTED] Spawn]$ WINEDEBUG=+volume winedbg winecfg
fixme:console:SetConsoleCtrlHandler (0x4066a644,1) - no error checking or testing yet
WineDbg starting on pid 0xa
In 32 bit mode.
Unable to open file /process.c
Wine-dbg>br GetDriveT
Title: Message
I would like to
first thank all the Wine developers for your help. Without you, this wonderful
software would not be maintained and allow good cross-platform app
development.
Several months ago I
received some help from the list on an MFC application I'm helping develop. Now
Vincent Béron <[EMAIL PROTECTED]> writes:
> This seems to let users build and uninstall with BSD make.
>
> Changelog:
> Evaluate variable after replacement to build with BSD make.
Unfortunately assignments with := are not portable either, so it's
only moving the problem. We probably need to restr
Mike Hearn <[EMAIL PROTECTED]> writes:
> --- Make.rules.in.~1.172.~2004-03-24 03:34:01.0 +
> +++ Make.rules.in 2004-08-02 22:57:38.868759456 +0100
> @@ -78,6 +78,7 @@
> LIBPORT = -L$(TOPOBJDIR)/libs/port -lwine_port
> LIBUNICODE = -L$(TOPOBJDIR)/libs/unicode -lwine_uni
Current CVS build fails.
make[3]: Entering directory
`/home/ivan/Development/Wine/CVS/wine/wine/dlls/winmm/tests'
gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall
-pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith
-g -O2 -o mixer.o mixe
Hi all,
I really like to know hot to change the "call identifier" in a MSRPC call???
Please help me, I already wasted too long time searching for this info with
no luck???
Thank you in advance!!!
_
Add photos to your messages with MS
On Wed, 2004-08-04 at 03:31, Michael Jung wrote:
> Rob,
>
> I've seen the press release concerning the CrossOver Office iTunes preview and
> I've noticed that it depends on libcrypto. Im just wondering if your effort
> with rsabase is related to this?
The initial effort was to do with a Codewea
I tried adding wine_pthread_get_current_teb to libs/wine/wine.def and
libs/wine/wine.map, but this caused the resulting binaries to
dereference a bad address in NtCurrentTeb.
wine_pthread_* functions are supposed to be defined in the
wine-pthread/wine-kthread binaries. The DSOs then have their s
I would to like compile Winelib under Solaris/SPARC so that I can
develop Windows applications from the relative comfort of UNIX, leaving
only the final building and testing to real Windows running under Bochs.
I have tested a selection of Wine releases and the build typically fails
with either
"Hans Leidekker" <[EMAIL PROTECTED]> wrote:
> What do you propose then? I could do something like this:
>
> if (GetLastError()==(DWORD)NTE_BAD_KEYSET)
>
> But I consider a cast even uglier then introducing an intermediate
> variable. We somehow have to live with the fact that NTE_BAD_KEYSET
>
Hans Leidekker wrote:
where Wine defines STATUS_SUCCESS like so:
#define STATUS_SUCCESS 0x
which means STATUS_SUCCESS is handled by gcc as an unsigned value. This
generates a warning because NTSTATUS is signed. If we look at the
SDK definition we see something differen
On Monday 09 August 2004 12:17, Hans Leidekker wrote:
> variable. We somehow have to live with the fact that NTE_BAD_KEYSET
> is defined as ((HRESULT)0x80090016L), which is signed, and GetLastError()
> returning DWORD, i.e unsigned.
On a related note, I am looking at the last testsuite with signe
On Monday 09 August 2004 11:17, Dmitry Timoshkov wrote:
> > - if (GetLastError()==NTE_BAD_KEYSET)
> > + LONG gle = GetLastError();
> > + if (gle==NTE_BAD_KEYSET)
>
> This is ugly. This kind of "fixes" clutters Wine code and should be
> deprecated.
What do you propose then? I could do something l
"Hans Leidekker" <[EMAIL PROTECTED]> wrote:
> +static const int size_of_wchar = sizeof(WCHAR);
> +
...
> -ok(!memcmp(bufW, stringW, 5 * sizeof(WCHAR)), "bufW/stringW mismatch\n");
> +ok(!memcmp(bufW, stringW, 5 * size_of_wchar), "bufW/stringW mismatch\n");
> - if (GetLastError()==NTE_BAD
17 matches
Mail list logo
