hey everybody,
I'm trying to debug a windows application - the Paradise Poker client
program. I keep getting an error when it runs:
--
err:win32:PE_fixup_imports No implementation for
WININET.dll.102(InternetGetConnectedState) imported from C:\Program
On Mon, 1 Apr 2002, Jason M Bell wrote:
hey everybody,
I'm trying to debug a windows application - the Paradise Poker client
program. I keep getting an error when it runs:
--
err:win32:PE_fixup_imports No implementation for
WININET.dll.102(InternetGetConnectedState) imported
Shachar Shemesh [EMAIL PROTECTED] wrote:
One more thing that should be addressed IMO as the part of the unicode
support in Wine: file APIs. For instance in the current state all russian
file names created by windows programs are completely unreadable in Linux
because they are created in code
Dmitry Timoshkov wrote:
Filenames, created by windows programs running under Wine, of course are
seen correctly *under Wine*. But regular Linux applications for apparent
reasons display them incorrectly, but still can open them.
One more thing I don't understand is this. The filenames are a
On Sat, Mar 30, 2002 at 11:58:49PM +0100, Sylvain Petreolle wrote:
Did you set the Desktop parameter at any value other
than N ? Running it whitout a desktop window gives
no problem.
Hmm ... you are right, I never use wine in desktop mode. I can now
reproduce your problem.
bye
michael
Shachar Shemesh [EMAIL PROTECTED] wrote:
I would particularily recommend against switching WINE to 20866 in light
of the fact that the only text editor I know that supports UNICODE is
Notepad. Most applications are not UNICODE, and running those apps on
WINE would become impossible if
Dmitry Timoshkov wrote:
Probably I didn't make my position clear enough and somehow you
misunderstood me and decided that I propose to use code page 20866
instead of 1251 for russian locale under Wine. But that's not the case.
I only proposed to create filenames on disk in encoding used
Shachar Shemesh [EMAIL PROTECTED] wrote:
Probably I didn't make my position clear enough and somehow you
misunderstood me and decided that I propose to use code page 20866
instead of 1251 for russian locale under Wine. But that's not the case.
I only proposed to create filenames on disk in
Hi all,
I just added a link to my final wineconf 2002 summary page at
http://home.arcor.de/andi.mohr/wine/wineconf2002/
to the WineHQ News.
If anyone else has anything to contribute, then feel free to tell me NOW :)
BTW, Michael, what about your photos ?
Are they supposed to get published
According to my files WININET.dll.102 is only present on Windows 95
and should be InternetFindNextFileA
How do I fix this in wine? playing with wine -winver winXX doesn't
help. Is there some other debugging trace I should turn on?
thanks,
Jason
hmm... I guess I can put the photos on my personal web site. Once they're up,
I'll let you all know. My photos were pretty lame anyway. If you want to put
them up, let me know.
On Monday 01 April 2002 07:26, Andreas Mohr wrote:
Hi all,
I just added a link to my final wineconf 2002 summary
as already discussed a bit, here's a first shot at testing CreateProcess
patch is made of two parts:
- extension to existing C test framework to pass argc/argv to any test
function
- the test itself
any comments are welcome
A+
Name: test_arg
ChangeLog: now C tests are able to
On Mon, 1 Apr 2002, Jason M Bell wrote:
According to my files WININET.dll.102 is only present on Windows 95
and should be InternetFindNextFileA
How do I fix this in wine? playing with wine -winver winXX doesn't
help. Is there some other debugging trace I should turn on?
Well, this
Jason M Bell [EMAIL PROTECTED] writes:
The source in dlls/wininet/internet.c clearly shows a (simple)
implementation for InternetGetConnectedState, but Wine isn't importing
it for some reason. I've turned on other debug traces, but haven't
gotten any other useful information. What are some
On Sun, Mar 31, 2002 at 07:47:18PM -0800, Francois Gouget wrote:
When I compile Wine on FreeBSD and Solaris I keep getting 'undefined
sybol' errors for all the C library symbols. So I usually add the
following to 'configure.ac'.
Index: configure.ac
The basic idea is to have two separate programs; a 'wine' that does
all the command-line processing, and a 'wineloader' that simply
executes a new process from CreateProcess. Then all the option
handling can be moved out of kernel and into that wine program.
how would you pass info from the
Eric Pouech [EMAIL PROTECTED] writes:
+static int get_file_name(char* buf, size_t len, const char* hint)
+{
+char* ptr;
+if (strcmp(winetest_platform, windows))
+{
+sprintf(buf, %s/%s, base, hint);
+for (ptr = buf; *ptr; ptr++)
+if (*ptr
Eric Pouech [EMAIL PROTECTED] writes:
The basic idea is to have two separate programs; a 'wine' that does
all the command-line processing, and a 'wineloader' that simply
executes a new process from CreateProcess. Then all the option
handling can be moved out of kernel and into that wine
Hi everybody,
I've stumbled accross some code which reads a dword at memory location
0x7ffe000, which causes the program to crash and the wine debugger to start.
After some investigation, it seems that reading the memory location
0x7ffe should return KeTickCount.LowPart to the user
Francois Gouget [EMAIL PROTECTED] writes:
The first one, in Make.rules.in, makes sure that if you modify
wtmain.o, then all tests will be rebuilt. You would think that the .c.o
implicit rule should do that already, but this is not the case. I
suppose it's because the file is not in the
This used to not happen. Now, I get a crash everytime I start up AOL
5.0 under recent (today) cvs. (cut an paste bug still exists, but you
can at least read the backtrace :)
Unhandled exception: page fault on read access to 0x0010 in 32-bit code
(0x40829fd4).
On Tue, Apr 02, 2002 at 12:11:09AM +0200, Laurent Pinchart wrote:
Hi everybody,
I've stumbled accross some code which reads a dword at memory location
0x7ffe000, which causes the program to crash and the wine debugger to start.
After some investigation, it seems that reading the memory
I've stumbled accross some code which reads a dword at memory location 0x7ffe000, which causes the program to crash and the wine debugger to start.After some investigation, it seems that reading the memory location 0x7ffe should return KeTickCount.LowPart to the user process. Has
23 matches
Mail list logo
