[EMAIL PROTECTED] wrote:
The latest patch from Rolf Kalbermatter on shellpath.c was breaking the installation
of wine.inf.
wine rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 d:\\wine.inf
was returning errors about being unable to create some dirs. In facts these errors
was
Duane == Duane Clark [EMAIL PROTECTED] writes:
Duane Roger wrote:
I agree that PDT should say Pacific Daylight Time but whoever wrote
this section refered to both ..DT and ..ST as Standard Time for
some good reason.I assumed so I followed convention. It came up in
an app
[EMAIL PROTECTED] wrote:
The latest patch from Rolf Kalbermatter on shellpath.c was breaking the
installation of wine.inf.
wine rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 d:\\wine.inf
was returning errors about being unable to create some dirs. In facts these errors
Hopefully, this time I have generated more specific and relevant
information. I have done regressions to identify the patches that may
be causing the symptoms. I have duplicated these results by using
./tools/wineinstall, make make depends and wineprefixcreate.
Although I was not able to
Hi,
I'm new
to WINELIB. As a test drive I tried to port the Hello World application, just
to see that the environment is functioning.
I called:
winemaker --console --lower-uppercase
.
In the source directory. Then I
called:
make
A helloworld.exe.so file was successfully created as
Isn't 300 a bit low? Almost all lasers do 600 dpi.
Huw D M Davies wrote:
Huw Davies [EMAIL PROTECTED]
Scale the patterns so that they're rendered at 300dpi
Create the image dictionary once, rather than every time the PaintProc
is called - should speed printing up
During program debugging I have some trouble with winedbg use.
Simple test program with error on write access to constant:
#include string.h
int main(int argc, char **argv)
{
char * str = test;
_strupr(str);
return (0);
}
I try debug it:
$ winedbg 3.exe
Can't attach
On Tue, Nov 02, 2004 at 05:53:11PM +0200, Dagan Shai wrote:
Hi,
I'm new to WINELIB. As a test drive I tried to port the Hello World
application, just to see that the environment is functioning.
I called:
winemaker --console --lower-uppercase .
In the source directory. Then I called:
make
A
Vitaly Lipatov [EMAIL PROTECTED] wrote:
Changelog:
EnumDateFormatsA:
- Add ru_RU locale (0x419)
That's a completely broken implementation, please do not extend it.
It should retrieve the data from the kernel32 locale database (have
a look at dlls/kernel/nls).
- Use DATE_SHORTDATE when
Jakob Eriksson [EMAIL PROTECTED] wrote:
Seems the test fails in non-interactive mode without this patch.
No, the problem seems to be related to a window's visibility. Windows
does not play EMF records if the DC was created for a not visible window.
A lot of other tests fail due to exactly that
You've exposed some softness in my thinking in this patch. Like I
mentioned in the comments for it, _SHExpandEnvironmentVariables exists
because the environment isn't actually set up during wine install time. I
didn't think to look up the values in the registry.
I also didn't register some of
On Tue, Nov 02, 2004 at 04:45:33PM +0100, Jakob Eriksson wrote:
Isn't 300 a bit low? Almost all lasers do 600 dpi.
That's exactly the point. Windows scales a pattern brush so that each
pixel is around 1/300 inch, otherwise if it left the patterns at the
device resolution they'd be hard to
It only generated the helloworld.exe.so file, and no others. This is the
only file defined in the makefile generated by winemaker. It is listed
as part of the EXES macro and not the DLLS, which is why I thought it to
be an executable.
Could there be some reason that no executable is generated?
Could there be some reason that no executable is generated?
The helloworld.exe.so file is the executable. You run it like you
would run any other win32 exe file:
wine helloworld.exe.so
On Tue, 2 Nov 2004 18:27:51 +0200, Dagan Shai [EMAIL PROTECTED] wrote:
It only generated the
Likewise, what's the current status of Installshield support,
and how much work would it be to fully support
Installshield-based installers? I don't see any
open Installshield bug reports, maybe I should file
one against the apps I have that don't install at
the moment. (Or would that be
Dmitry wrote:
The question is what makes the tests create invisible windows? Does
winetest run as a service on a not visible desktop? Anything else?
I believe this is the reason. The shellpath tests fail on WinXP, I
believe because HKCU doesn't exist because the service doesn't interact
with
The common denominator for this situation is that these patches modified
some of the same files. Patch 13475 implemented itss.dll and modified
wine/dlls/Makefile.in, wine/configure.ac and wine/configure. A partial
implementation of advpack.RegInstall, Patch 13938 also modified
On Tue, Nov 02, 2004 at 06:27:51PM +0200, Dagan Shai wrote:
It only generated the helloworld.exe.so file, and no others. This is the
only file defined in the makefile generated by winemaker. It is listed
as part of the EXES macro and not the DLLS, which is why I thought it to
be an executable.
Log message:
Fix x11 event timing so that we correctly correlate
x11 timing and Wine timing and dynamically adjust it
as we go.
Index: event.c
===
RCS file: /home/wine/wine/dlls/x11drv/event.c,v
retrieving revision 1.37
diff -u
On Tue, Nov 02, 2004 at 06:40:57PM +0200, Dagan Shai wrote:
Thanks.
Here they are.
Winemaker is buggy, the generated Makefile has a small problem.
Here's the fix:
--- Makefile.orig 2004-11-02 09:52:59.0 -0500
+++ Makefile2004-11-02 11:52:57.451738280 -0500
@@ -58,7 +58,7
02 2004 19:10 Dmitry Timoshkov (a):
Vitaly Lipatov [EMAIL PROTECTED] wrote:
Changelog:
EnumDateFormatsA:
- Add ru_RU locale (0x419)
That's a completely broken implementation, please do not extend it.
It should retrieve the data from the kernel32 locale database (have
a look at
Hmm. My own test program has a clear demonstration that this
isn't quite right; a 'sleep2 -1 10we' shows that having an
event trigger a wait gets the waiting thread some priority back.
This suggests that adding
if (ret == WAIT_TIMEOUT)
prior to the NtYieldExecution() gives the best
Dmitry Timoshkov [EMAIL PROTECTED] writes:
The question is what makes the tests create invisible
windows? Does winetest run as a service on a not visible
desktop? Anything else?
Winrash, which invokes winetest in most of the cases, is a
service process running on an invisible desktop.
I see some bug in stubs handling.
Versions:
i386-mingw32msvc-gcc-3.3.3
wine from last CVS
Any suggestions?
more likely something in dealing with the way mingw stores stabs in PE
modules. Can you send me your 3.exe file ?
TIA
Juan Lang [EMAIL PROTECTED] writes:
You've exposed some softness in my thinking in this patch. Like I
mentioned in the comments for it, _SHExpandEnvironmentVariables exists
because the environment isn't actually set up during wine install time. I
didn't think to look up the values in the
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
The proper fix is to ensure that the environment is set up properly;
shell32 shouldn't have to duplicate the environment registry support.
Yes, but it's a chicken-and-egg problem. The registry for the environment
has been set up right, but the
Juan Lang [EMAIL PROTECTED] writes:
Are you suggesting setupapi special case registry value setting so that if
it recognizes the key as affecting the environment, it should set the
variable on the spot? Or do you have another suggestion?
No, setupapi should respect the environment variables
Here's the first step of moving the update region management to the
server. The refresh on window moves is not optimized yet, so it will
probably flicker quite a bit, but things should still be painted
properly in the end. If you feel like giving this a try, I'm
interested in hearing about any
ShCreateDirectory should fail with that error if the directory
really already existed.
I agree that SHCreateDirectory should fail, but I'm not convinced
it is crucial in the specific SHGetFolderPathW function. But I may
be wrong.
I was wondering about that too. In my case what happened
Is there any particular reason this patch hasn't been committed?
Something wrong or just overlooked?
Hello,
We just started using WineLib, and have very basic question:
which -g??? option do you use to do source level debugging
with winedbg?
I searched the documentation and mailing list for any step-by-step
about this, but found nothing. So either the answer is so obvious
that I just
Is there are anyone working on it? It seems like there are some strange problem
with mouse input, and I can't find it!
I trying to get Descent 3 running. So far so good. It installs, and runs. But
mouse does not work. It's not like it doesn't work at all. It does, but it moves
erratically and
Ferenc Wagner [EMAIL PROTECTED] wrote:
Winrash, which invokes winetest in most of the cases, is a
service process running on an invisible desktop. Winetest
itself can happily run on the real visible desktop, it's
just people seldom run it that way (ie. directly).
Then we need either
Geoff K. Hart a écrit :
Hello,
We just started using WineLib, and have very basic question:
which -g??? option do you use to do source level debugging
with winedbg?
I searched the documentation and mailing list for any step-by-step
about this, but found nothing. So either the answer is so
Geoff K. Hart wrote:
Hello,
We just started using WineLib, and have very basic question:
which -g??? option do you use to do source level debugging
with winedbg?
There is no point in struggling with winedbg, with a winelib. wine and
winelib apps can be fully debugged with gdb. I use a full
35 matches
Mail list logo
