May 2002 - Wine-devel - list.winehq.org

DOS memory Question..... or How to increase base memory for DOS apps
by Christian Costa 01 Jun '02

01 Jun '02

Hi, Many DOS apps needs a lot of base memory even if EMS or XMS memory are used. The first 64K of memory being lock to catch null pointer, the DOS memory must start at 0x10000 as you can see in the code below (msdos/dosmem.c) : /*********************************************************************** * DOSMEM_InfoBlock * * Gets the DOS memory info block. */ static dosmem_info *DOSMEM_InfoBlock(void) { return (dosmem_info*)(DOSMEM_dosmem+0x10000); /* 64K */ } /*********************************************************************** * DOSMEM_InitMemory * * Initialises the DOS memory structures. */ static void DOSMEM_InitMemory(void) { /* Low 64Kb are reserved for DOS/BIOS so the useable area starts at * 1000:0000 and ends at 9FFF:FFEF. */ Changing this value to the end of the BIOS DATA area (0x500) does the job and things work as expected (at least for DOS apps). But I was told that this causes problems for others apps. Probably for Win16 ones that use DOS3CALL and not int21h via DPMI. If it's true, a solution could be to initialize DOS memory differently for pure DOS apps by modifying the DOSMEM_Init function. DOSMEM_Init is called at 3 different places : - process_attach in dlls/kernel/kernel_main.c - DOSVM_Init in dlls/winedos/dosvm.c - MZ_InitMemory in dlls/winedos.dosvm.c and acts differently the first and second calls. Since I don't know wine internals enough and the "flow of execution", I have no idea how to do it in a clean way that do not break everything. If someone can help me or give me hints? A+ Christian

3 3

How to fix SizeOfImage when loading a builtin dll ?
by Laurent Pinchart 01 Jun '02

01 Jun '02

Hi everybody, I noticed that, when a builtin dll (.so) is loaded, the SizeOfImage field in the OptionalHeader is not updated and stays equal to page_size (see winebuild, spec32). I need to get the correct value in SizeOfImage. I thought about updating that field in map_dll(a)library/loader.c, but don't know how to get the size of the image. Could anyone help me ? I'm not familiar with the PE loader. Thanks in advance, Laurent Pinchart

5 12

translating docs
by Damian Wojslaw 01 Jun '02

01 Jun '02

Hello I just posted similiar thing on wine-users, but Anriy Palamarchuk said, that he intend to say something about it here. I thought I might as well give him a good opportunity and ask: what about translating docs? Those at WineHQ and within Wine tree? What I would like to know is, which of them would you like to see translated first (as for now, I am, unfortunately, the only person I know of, that intends to do this)? What about user interface? How do you want to distribute it - want to have it at your site, or ony host a link? And so on, and so forth, and whatever... :)))) -- Damian Wojslaw

1 0

Re: wine can't find regedit.exe.so when it is not on the path
by Alexandre Julliard 31 May '02

31 May '02

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > I can't start just installed regedit manually, > wine gets confused by symbolic links in the windows > directory: > regedit.exe -> /usr/local/bin/regedit > regedit.exe.so -> /usr/local/bin/regedit.so These symlinks should be removed too, they are no longer necessary. -- Alexandre Julliard julliard(a)winehq.com

2 4

Re: [Bug 751] Changed - GetDiskFreeSpace should return >2GB on some systems
by Andreas Mohr 31 May '02

31 May '02

Hi all, could you have a look at bug #751 and check the values on your Windows version and add a comment to the bug on what your version does ? (please don't forget to only check for partitions > 2GB !!) Thanks ! On Thu, May 30, 2002 at 11:19:14PM -0500, wine-bugs(a)winehq.com wrote: > http://bugs.winehq.com/show_bug.cgi?id=751 > > *** shadow/751 Thu May 30 23:18:08 2002 > --- shadow/751.tmp.27844 Thu May 30 23:19:14 2002 > *************** > *** 25,27 **** > --- 25,31 ---- > the selected emulated version, or always return the actual free size. > > I'll attach a small program to obtain the return values from GetDiskFreeSpaceA. > + > + ------- Additional Comments From vberon(a)mecano.gme.usherb.ca 2002-05-30 23:19 ------- > + Created an attachment (id=150) > + Test program to obtain the return values of GetDiskFreeSpaceA -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

2 1

Re: PATCH: libntddl.so not found
by Alexandre Julliard 31 May '02

31 May '02

Marcus Meissner <marcus(a)jet.franken.de> writes: > This adds a helpful messages for the users who do > ./configure > make > make install > and do not have /usr/local/lib in their ld.so.conf. I think this should be in the top-level Makefile to avoid having it scroll off the screen. Also it would be nice to check LD_LIBRARY_PATH to avoid needlessly scaring users who have a working config already. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: libntddl.so not found
by Dustin Navea 31 May '02

31 May '02

Hmmm, I found some problems with this: +print NEWMAKE <<EOF; shouldn't that be printf ? + \@if test -f /etc/ld.so.conf -a -z "`grep \$(libdir) /etc/ld.so.conf`" ; \\ shouldn't that be \$(LIBDIR) + echo " Add the line '\$(libdir)' to /etc/ld.so.conf" ; \\ I think that escaping the $ in this line is unnecessary as it this prints "$(libdir)" instead of the contents of that variable, and also libdir should be capitalized there too... + echo " export LD_LIBRARY_PATH=\$(libdir):\$LD_LIBRARY_PATH" ; \\ Same as above except that it doesn't apply to \$LD_LIBRARY_PATH as we want "$LD_LIBRARY_PATH" to be printed... -Dustin __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

2 2

Re: Idea for people with priveleges
by Dustin Navea 31 May '02

31 May '02

--- Andriy Palamarchuk <apa3a(a)yahoo.com> wrote: > > --- Dustin Navea <speeddymon(a)yahoo.com> wrote: > > Well, AFAIK, there isn't reall a QA team, and if > > there > > is, they aren't checking out the bugs, because > > several > > bugs marked as resolved for over a year weren't > > closed > > until I went in and closed them.... > > Agree, we can simplify the things for now - skip > VERIFIED and RESOLVED steps in most cases - just > close > the bugs. > We can change the process later. > > Andriy > That is why I started this thread, we cant "just close the bugs" we have to resolve them first... We need 3 more options, probably would be easiest to implement in BugZilla 2.11: Close as Unresolved More information needed from User More testing Needed __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Problem with 64-bit file functions declarations
by Andriy Palamarchuk 31 May '02

31 May '02

I'm researching an issue when started regedit.exe fails to export registry. This started to happen after Alexandre's patch which included "config.h" in the regedit source file. I found out this problem was triggered by declaration #define _FILE_OFFSET_BITS 64 in config.h. The test case: ******************************************** /* Set this to 64 to enable 64-bit file support on Linux */ #define _FILE_OFFSET_BITS 64 #include <stdio.h> #include <windows.h> void test_write(void) { FILE *f = fopen("1.reg", "w"); printf("sizeof FILE: %d\n", sizeof(FILE)); fputs("DEBUG1\n", f); fclose(f); } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { test_write(); exit(0); } ******************************************** Comment out the macro definition and it works, with macro it creates file of 0 length. With the defined macro many file functions are defined as functions for 64-bit access and are linked to the native platform calls instead of msvcrt ones. Differences in precompilation output: Without macro: # 203 "/usr/include/stdio.h" 3 extern FILE *fopen (__const char *__restrict __filename, __const char *__restrict __modes) ; With macro: # 211 "/usr/include/stdio.h" 3 extern FILE *fopen (__const char *__restrict __filename, __const char *__restrict __modes) __asm__ ("" "fopen64"); The same happens for some other file functions. What is the correct fix for this problem? Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

3 4

fwait bug
by admiral coeyman 31 May '02

31 May '02

Developers, From what I've been reading on the subject, the best way of handling int 3d is to return successful. Any fpu emmulation that we'll do should not require the fwait. The problem is that I cannot find enough information on the subject to know what the successful return conditions for this interrupt are. On a system that detects an FPU, self-modifying code is used. The interrupts that emmulate the FPU functions are rewritten in the executable to use the machine code for the real FPU instructions. I'm not sure if that can be done with the current memory scheme since that is outside of my area. God Bless, --Robert 'Admiral' Coeyman -- --- May you live as long as you wish and age but a single day. http://www.dotguy.net/ admiral(a)corner.net Webmaster/ Linux Administrator Computer Co-Op/CornerNet

1 0