Hold that thought. I may have introduced a dependency from ntdll to
kernel32.dll as I tried to debug something else. I had forgotten about it and
now I see it may be problematic.
From: Roger Cruz
To: Wine Devel
Sent: Thursday, November 22, 2012 1:50 AM
I finally was able to figure out how to attach the debugger to determine why
services.exe did not start and I can clearly see now that the oem_table is
NULL. It should have been set by LOCALE_Init() when called from kernel32's
init function. However, if you look at the stack trace here, Wine h
What is the proper way to debug wineboot and services.exe in order to find out
what is causing the error outputted by wineserver below?
err:wineboot:start_services_process Couldn't start services.exe: error 1359
wine: failed to update /winearm/winehome with
/winearm/bin/../share/wine/wine.inf:
I worked around it by not needing the information about the number of arguments
and their sizes which is what I was asking for at the time. However, I still
have the need for that data so once Wine makes it available, I can change my
code to consume it.
Regards
Roger Cruz
That is great Andre. I managed to work-around the issue for the time-being but
having this work properly on ARM is a great step. Looking forward to your
contribution.
Regards,
Roger
From: André Hentschel
To: wine-devel@winehq.org; Roger Cruz
Sent
piler flag. I guess one more
research task for me :-)
Regards,
Roger
From: Eric Pouech
To: Roger Cruz
Cc: Wine Devel
Sent: Wednesday, June 6, 2012 8:12 AM
Subject: Re: Wine's support for reporting calling conventions
dwarf4 allows each compiler vendor
ut defining it further)
> FYII, the codeview format reports correctly this information
> note also that winedbg doesn't support calling functions in the
> debuggee, so this information is actually not used in winedbg
> A+
>
> 2012/6/6, Roger Cruz :
>>
>>
>>
In dlls/dbghelp/dwarf.c, there is this snippet of code which appears to
hard-code the calling convention to CALL_FAR_C. Does Wine not support
reporting a function's calling convention correctly then? Is it a limitation
of DWARF or just that it is not implemented? I can see that DWARF has a
obviously I haven't looked through this entire array to see if
this function got inserted into the wrong place. I will continue to debug this
but I figure I ask first in case there is a known issue which has been address
in a subsequent release.
Regards
Roger
er R. Cruz
> *From:* Roger Cruz
> *To:* "wine-devel@winehq.org"
> *Sent:* Monday, April 16, 2012 9:13 PM
> *Subject:* SymEnumSymbolsForAddr in dbghelp.dll
>
>
> I wrote a simple piece of code that uses dbghelp.dll's
> SymEnumSymbolsForAddr() b
merate the arguments. I will let you know more
soon.
Roger
____
From: Roger Cruz
To: "wine-devel@winehq.org"
Sent: Monday, April 16, 2012 9:13 PM
Subject: SymEnumSymbolsForAddr in dbghelp.dll
I wrote a simple piece of code that uses dbghelp.dll'
I wrote a simple piece of code that uses dbghelp.dll's SymEnumSymbolsForAddr()
but when I went to search for its code in Wine, it looks to be missing. The
dbghelp.spec has that function listed as "stub". What does stub mean in this
context? Does it mean the function is not implemented? Are
rt to ARM?
Am 13.04.2012 08:55, schrieb Roger Cruz:
> Is anyone interested in helping me port the x86 specific code in Winebuild to
> ARM so I can get the relay tracing working? I am relatively new to ARM so
> any help would be appreciate it.
>
> Thanks
> Roger R. Cruz
>
&
Is anyone interested in helping me port the x86 specific code in Winebuild to
ARM so I can get the relay tracing working? I am relatively new to ARM so any
help would be appreciate it.
Thanks
Roger R. Cruz
From: Roger Cruz
To: "wine-devel@winehq.org&qu
Has anyone worked or is currently working on porting the x86 specific code in
Winebuild to ARM? Specifically the relay.c file?
Thanks
Roger R. Cruz
How are the tools under the winapi directory used? I've tried running them but
they all complain about the same error.
~/sandbox/wine/sources/wine-1.3.36/dlls/kernel32$
~/sandbox/wine/sources/wine-1.3.36/tools/winapi/winapi_extract
winapi_extract: You must run this tool in the main Wine dire
Hello fellow Wine developers,
I am looking for paid programming help to help me finish a proof of concept
application that utilizes Wine. This is a short-term contract project with
terms negotiated based on your experience and ability to finish tasks in a
timely manner. The right person sh
s
Roger R. Cruz
From: Juan Lang
To: Roger Cruz
Cc: "wine-devel@winehq.org"
Sent: Monday, April 2, 2012 3:45 PM
Subject: Re: Programmatically determining arguments to a WinAPI function
Hi Roger,
On Mon, Apr 2, 2012 at 10:41 AM, Roger Cruz wrote:
> I'
I'm looking for a way to determine programmatically what the arguments to a
Win32 API implemented in Wine are. I'm trying to implement an API redirection
stub that I can use to trace calls into all of the Wine-implemented DLLs. My
stub needs to know what each argument passed into the Win32 API
Could someone tell me if Wine has a built-in Window Manager of its own or does
it count on the host's window manager for such things as window hierarchy
(parent-child relationships), clipping, move, resize, iconify, etc? I want to
run Wine on an environment which lacks X and I have been told
Subject: Re: dosdevices/c not present.. how is it created?
On 7/12/2011 11:30 AM, Roger Cruz wrote:
> I'm getting the following error when running Wine.
>
> Using the debugger, I think I found where the problem is:
>
> 2140 int fd = open( unix_name, O_RDONLY | O_DIRECT
I'm getting the following error when running Wine.
err:process:init_windows_dirs directory L"C:\\windows" could not be created,
error 2
err:process:init_windows_dirs directory L"C:\\windows\\system32" could not be
created, error 3
Using the debugger, I think I found where the problem is:
214
Great. Thanks for the explanation
On Nov 27, 2011, at 6:32 PM, Vitaliy Margolen wrote:
> On 11/27/2011 03:24 PM, Roger Cruz wrote:
>> Could you expand what exactly would not work?
> Some copy-protection systems, and any other programs that do dlls patching
> using IPC. T
My apologies on mispelling your name Maarten
From: Roger Cruz
To: Maarten Lankhorst
Cc: "wine-devel@winehq.org"
Sent: Sunday, November 27, 2011 5:24 PM
Subject: Re: Compiling Wine without prelink
Hi Marteen,
Could you expand what exactly woul
0
p_offset=0x"
I'm looking for a way around this and not p;roviding a base address may do it.
Roger
From: Maarten Lankhorst
To: Roger Cruz
Cc: "wine-devel@winehq.org"
Sent: Sunday, November 27, 2011 4:45 PM
Subject: Re: Compil
What is the proper way to ask the configure script not to use 'prelink' on the
generated shared libraries? I don't want to remove the prelink from my
development platform but just tell the configurator to ignore it.
Thanks
Roger R. Cruz
aybe i can find a solution, but only maybe. BTW all the
> problems you will find are Android specific.
>
> Gesendet mit meinem HTC
>
> - Reply message -
> Von: "Roger Cruz"
> An: "wine-devel@winehq.org"
> Betreff: signal_arc.c failing to cross-com
Hi Andre et al,
Wondering if any of you know how to get around this? The compiler is barfing
at the lack of ucontext_t when doing a typedef of SIGCONTEXT.
Thanks in advance,
Roger R. Cruz
arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll
-I. -I/home/rcruz/sandbox
Hi Dan,
So far that autoconf script has been a nightmare. It doesn't include string.h
(where strerror.h is defined) directly BUT I did include unistd.h in order to
get autoconf to find getpagesize().
I'm building under the Android development which uses GCC for cross-compiling
for ARM.
I'm still attempting to cross-compile Wine to ARM and I'm running into many
compile errors right off the bat. I have tracked these down to the lack of
HAVE_xxx in the config.h file generated from configure script.
Many of the functions being checked from this list fail when they are compiled
b
Yes, exactly. So far so good with their toolchain except for this redefinition
of routines. It looks like it needs some architecture specific implementations
of these routines.
Thanks
Roger R. Cruz
On Oct 23, 2011, at 12:07 PM, André Hentschel wrote:
> Am 22.10.2011 20:07, schrieb Ro
I'm attempting to cross-compile Wine for ARM and during the compilation of the
first file, I get the following error about some strings.h routines not being
portable. I have tracked this down to the redefinitions for these routines in
include/port.h.
How do I get around this issue? Is there a
32 matches
Mail list logo