Does anyone know how _CRT_INIT should interact with winelib?
I have a load of code which uses it in the DllMain but I presume that it is
a Microsoft hack that the compiler/linker cleverly converts to something
else
Bill
On Tue, Jan 01, 2002 at 05:47:26PM +0100, eric pouech wrote:
> as spotted by Marcus, but only half done, the fg & bg colors were
> inverted
> moreover, this patch also some initialisation problems in wineconsole
Oh, sorry for not fixing correctly.
Eric, I have also found following additional problems:
- The Apply button in the Propertysheet never gets enabled.
It always stays grayed out. When I press [Ok], the changes do get active,
but are not saved into the registry. Somehow the property sheet does not
get noticed that values inside it have changed... I do not have a clue
how that works.
- The default font is not fixed pitch. This is strange, since the font enum
appears correct. I hardcoded the default font to Console, but this is
not a good solution.
Testing now appears to provide only correct fonts. Strange.
- IDA text display is slow, it does a lot of redraws all the time.
I tried the following patch, which makes redraws async:
Index: user.c
===================================================================
RCS file: /home/wine/wine/programs/wineconsole/user.c,v
retrieving revision 1.4
diff -u -r1.4 user.c
--- user.c 2002/01/01 00:14:02 1.4
+++ user.c 2002/01/02 18:59:18
@@ -501,7 +501,9 @@
r.bottom = (bm - data->curcfg.win_pos.Y + 1) * data->curcfg.cell_height;
InvalidateRect(PRIVATE(data)->hWnd, &r, FALSE);
WCUSER_FillMemDC(data, tp, bm);
+ /*
UpdateWindow(PRIVATE(data)->hWnd);
+ */
}
}
However, while the redraws do work, they are coming very late sometimes,
as if repaints do not appears frequently enough. Strange.
- Mouse presses should be sent as input events. If I get too annoyed I just
can just implement it ;)
- wineconsole without arguments crashes:
6 faulted at EIP=0x00000043, CR2=0x00000000, EAX 0x00000001
EBX 0x401ed0bc, ECX 0x40596cec, EBP 0x40596e18
EDI 0x00000000, ESP 0x002b:0x40596e08 FS 0x008f, pid 1189
exception 0xc000001d at address 0x00000043, fs 8f, pid 1189 ()
wine: Unhandled exception, starting debugger...
err:seh:start_debugger Couldn't start debugger ((null)) (0)
Read the Wine Developers Guide on how to set up winedbg or another debugger
Ciao, Marcus
This patch implements asynchronous I/O on regular file objects.
It is against the current (02/01/02) CVS version of wine.
I know that async IO on regular files is pretty pointless at the moment,
but it's better to have it working as expected, I guess ...
The patch was successfully tested with a simple test program that checks
the sequence of scheduled reqeuests and file positioning via the
lpOverlapped->Offset and OffsetHigh fields.
server/file.c:
struct file: add two async_queue fields (read/write) for async IO.
create_file_for_fd(): Intialize async queues.
destroy_file(): destroy async queues.
file_poll_event(): invoke async requests for overlapped files.
file_queue_async(): implement the queue_async() method.
file_get_info(): return FD_TYPE_OVERLAPPED for overlapped files.
files/file.c:
FILE_AsyncReadService():
Use pread() for fd's that support seeking.
FILE_AsyncWriteService():
Use pwrite() for fd's that support seeking.
Regards
Martin
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
>Have a look at the following two messages from Marcus Meissner to
>wine-devel and wine-patches:
Hmm, those links dont work for me, however I remember:
The header files for stdio have macro versions of putc/getc so your
implementation must use the FILE structure fields in a binary
compatable way (as they are currently; I implemented the code to
pretend that the buffer is alway empty and needs to be reread/put on
every operation).
Provided you can make optimised VC++ compiled programs (i.e. those
that use the macro version of get/putc) work, you dont have any extra
threading issues that the code should handle already (but probably
doesn't; large sections are not yet thread safed). The performance
improvement would be significant also.
You should make sure you test your changes thoroughly tho, as the
file code is rather vital to avoiding needing native msvcrt ;-)
Cheers,
Jon
=====
"Don't wait for the seas to part, or messiahs to come;
Don't you sit around and waste this chance..." - Live
jon_p_griffiths(a)yahoo.com
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
I have the dubious distinction of having hired
a friend back in 1997 to write perhaps the first PE compressor
utility.
It eventually became the core of http://www.neoworx.com/products/neolite/
(a competitor to Shrinker).
He mentioned recently that he found
"Windows NT/2000 Native API Reference" by Gary Nebbett
http://www.amazon.com/exec/obidos/ASIN/1578701996/
to be useful in updating his compressor to handle .exe's
that use some of the newer API calls.
http://kt.linuxcare.com/kernel-traffic/kt20000724_77.epl mentions it, too,
as do many posts in comp.os.ms-windows.programmer.nt.kernel-mode,
so it appears to be useful.
Just thought I'd mention that book in case anyone here hasn't
heard of it.
- Dan
I'm getting the wrong sort of terminal. Why?
I vaguely remember doing something to the registry settings for the debugger
about a month ago but I can't remebber what. Since then I have not been
tripping it anyway. However I am now investigating a problem that does trip
the debugger. However it now comes up with an enormous terminal of some
sort with terrible font and bad agreement between font and cursor
positioning, so that important data disappears off the right of the screen
before wrapping. However in the old days it used to use an xterm. I'd like
to go back to that.
Did I do that or is it a result of the stuff going on with the debugger?
TIA
Bill
p.s. Merry Christmas to all.
Hello Waldek,
Have a look at the following two messages from Marcus Meissner to
wine-devel and wine-patches:
Mon, 23 Jul 2001 09:08:31 -0400
http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2001-
07/date/article-185.html
Sat, 21 Jul 2001 09:14:03 -0400
http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/archives/200
1-07/date/article-102.html
You can probably also use the native MSVCRT.DLL, from your windows
installation.
Mike
> Recently I tried to run g77 compiled Fortran program under Wine.
> It seems that to do any input g77 uses `ungetc'. Currently,
> Wine msvcrt has unbufferd stdio. I would like to add buffering
> and implement `ungetc'. Are there any traps (thread safety ??)
> or will strightforward implementation work ?
> --
> Waldek Hebisch
> hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl
------------------------------------------
mailto:[email protected]
ph +82 16 430 0425
__________________________________________________________________
Get your free Australian email account at http://www.Looksmart.com.au
Hi,
I tried compiling current cvs wine on RH 7.2, and it fails...
gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2
-g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT
-I/usr/X11R6/include -o freetype.o freetype.c
freetype.c:43:31: freetype/ftnames.h: No such file or directory
make[2]: *** [freetype.o] Error 1
make[2]: Leaving directory `/share/building/wine/wine/dlls/gdi'
It seems that the autoconf test for freetype/ftnames.h doesn't work
properly. The file is not present in the RH package, and is not included
in the freetype-2.0.3 tarball either.
BTW, I'm not on the list atm.
Ben.
