Re: winegcc: Add support for -Ttext-segment linker flag to set image base of a dll. (try 2)
On 2013-03-06 12:25, Alexandre Julliard wrote: Alexandre Julliard julli...@winehq.org writes: Tijl Coosemans t...@coosemans.org writes: On 03-03-2013 17:44, André Hentschel wrote: You would rather call it PLATFORM_FREEBSD Well, the flag isn't FreeBSD specific. It works on all ELF targets (including Linux which then wouldn't need prelink). Then it should be used by default, and you don't need to add a new platform for it. Actually, I looked into this and it isn't widely supported at all, so it can't be the default. Ideally it would need a run-time check to see if the option works. Wouldn't a run-time check be too much of a performance hit? Loading a library at a specific address not only depends on the compile-time linker, but also on the run-time loader, so it's probably best to implement -image-base only on PLATFORM_* where the loader supports it. Since a target platform would then have to choose to use PLATFORM_ELF explicitly I think it's reasonable for PLATFORM_ELF to have a dependency on binutils=2.20 (or compatible) rather than a run-time test for -Ttext-segment support.
Re: Raise the minimum version of FreeBSD to 8.0.
On 04-03-2013 01:54, Frédéric Delanoy wrote: On Sun, Mar 3, 2013 at 12:22 AM, Gerald Pfeifer ger...@pfeifer.com wrote: We've had this as a requirement in the FreeBSD ports for quite a while (and the Wiki describes some background). Gerald --- - FreeBSD 7.0 or later + FreeBSD 8.0 or later ... FreeBSD info: - Wine will generally not work properly on versions before FreeBSD 7.0. + Wine will generally not work properly on versions before FreeBSD 8.0. Maybe just remove this sentence since it's redundant.
Re: winegcc: Add support for -Ttext-segment linker flag to set image base of a dll. (try 2)
On 03-03-2013 17:44, André Hentschel wrote:
Am 03.03.2013 16:58, schrieb Tijl Coosemans:
---
README | 3 +++
tools/winegcc/utils.h | 3 ++-
tools/winegcc/winegcc.c | 11 ++-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 783e798..75aff5a 100644
--- a/README
+++ b/README
@@ -40,6 +40,9 @@ support kernel threads may be supported in the future.
FreeBSD info:
Wine will generally not work properly on versions before FreeBSD 7.0.
+ You need GCC with GNU Binutils 2.20 or higher and run configure with
+ environment variables like CC, CFLAGS, CXX, CXXFLAGS, CPP, CPPFLAGS,
+ LD and LDFLAGS set correctly to use this compiler and linker.
See http://wiki.freebsd.org/Wine for more information.
Do you really need that? is there no script on freebsd to set the
compiler toolchain or something?
This is only if you run configure directly. If you build Wine using
the ports system everything is set up for you.
enum target_platform
{
-PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS,
PLATFORM_WINDOWS, PLATFORM_CYGWIN
+PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS, PLATFORM_ELF,
+PLATFORM_WINDOWS, PLATFORM_CYGWIN
};
You would rather call it PLATFORM_FREEBSD
Well, the flag isn't FreeBSD specific. It works on all ELF targets
(including Linux which then wouldn't need prelink).
+if (opts-image_base !opts-target opts-target_platform ==
PLATFORM_UNSPECIFIED)
I'm in doubt here
It's to make sure prelink isn't run when image base has already
been handled.
prelink --reloc-only versus ld -Ttext-segment
Hi, I'm looking into supporting winegcc -Wl,--image-base on FreeBSD. On Linux prelink --reloc-only is used for that but rather than porting prelink it seems easier to pass -Wl,-Ttext-segment to the compiler instead. Is there anything obviously wrong with that? Winedbg shows kernel32 and ntdll are loaded at their respective addresses: ELF 7b80-7ba41000 Dwarf kernel32elf \-PE 7b82-7ba41000 \ kernel32 ELF 7bc0-7bccd000 Dwarf ntdllelf \-PE 7bc1-7bccd000 \ ntdll The output of readelf -l ntdll.dll.so looks good too: Elf file type is DYN (Shared object file) Entry point 0x7bc20200 There are 5 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x7bc0 0x7bc0 0xafce4 0xafce4 R E 0x1000 LOAD 0x0afce4 0x7bcb0ce4 0x7bcb0ce4 0x0941c 0x1c2b4 RW 0x1000 DYNAMIC0x0b 0x7bcb1000 0x7bcb1000 0x000e8 0x000e8 RW 0x4 GNU_EH_FRAME 0x0960bc 0x7bc960bc 0x7bc960bc 0x04144 0x04144 R 0x4 GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x4
prelink --reloc-only versus ld -Ttext-segment
Hi, I'm looking into supporting winegcc -Wl,--image-base on FreeBSD. On Linux prelink --reloc-only is used for that but rather than porting prelink it seems easier to pass -Wl,-Ttext-segment to the compiler instead. Is there anything obviously wrong with that? Winedbg shows kernel32 and ntdll are loaded at their respective addresses: ELF 7b80-7ba41000 Dwarf kernel32elf \-PE 7b82-7ba41000 \ kernel32 ELF 7bc0-7bccd000 Dwarf ntdllelf \-PE 7bc1-7bccd000 \ ntdll The output of readelf -l ntdll.dll.so looks good too: Elf file type is DYN (Shared object file) Entry point 0x7bc20200 There are 5 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x7bc0 0x7bc0 0xafce4 0xafce4 R E 0x1000 LOAD 0x0afce4 0x7bcb0ce4 0x7bcb0ce4 0x0941c 0x1c2b4 RW 0x1000 DYNAMIC0x0b 0x7bcb1000 0x7bcb1000 0x000e8 0x000e8 RW 0x4 GNU_EH_FRAME 0x0960bc 0x7bc960bc 0x7bc960bc 0x04144 0x04144 R 0x4 GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x4
Re: Building Wine on amd64 FreeBSD?
On 05-07-2012 23:37, Hilko Bengen wrote: Following Marcus Meissner's advice how to build a WoW64 setup (thanks!), I have succeeded in building a set of co-installable i386/amd64 Debian packages. Those won't make it into the wheezy release as I was just a bit late for the freeze, but I have uploaded packages to experimental. What didn't work was building the 64-bits of wine on Debian/kfreebsd-amd64 (Debian userland including GNU libc on a FreeBSD kernel): https://buildd.debian.org/status/fetch.php%3Fpkg%3Dwine%26arch%3Dkfreebsd-amd64%26ver%3D1.4.1-1.2%26stamp%3D1341358832 Apparently the reason is that the uc_mcontext structure does not store the DS, ES, FS, and GS registers. After I made the changes below, everything compiled, but how useful is the result? Are those registers contained in uc_mcontext on plain FreeBSD? They were added in FreeBSD 8: http://svnweb.freebsd.org/base/head/sys/amd64/include/ucontext.h
Re: Anyone wants to ban spammer on forum
On Wednesday 19 October 2011 14:08:14 L. Rahyen wrote: On 2011-10-19 (October, Wednesday) 02:37:41 Vitaliy Margolen wrote: On 10/18/2011 07:37 PM, Vitaliy Margolen wrote: So any admins actually watching and want to bad roberbdib3a on forum? Also why aren't every moderator has these rights to block spammers, since we have only one forum. So no takers? I'm guessing we need more forum admins then, so more timezones can be covered. I agree. I and other morerators have deleted spam messages, but the spammer kept using the same account to post more. Inability to ban spammer's account is frustrating. I would happely volonteer to be forum admin so I can ban spammers. The past few days there's been spam messages every few minutes and as soon as you ban an account an other one appears. Obviously the bots have figured out the answer to the captcha. signature.asc Description: This is a digitally signed message part.
Re: d3dx9/tests: Fix comparison that expects NAN, since NAN != NAN.
On Tuesday 28 June 2011 00:40:09 Alexandre Julliard wrote:
Dylan Smith dylan.ah.sm...@gmail.com writes:
@@ -4834,7 +4834,7 @@ static void test_create_skin_info(void)
for (i = 0; i num_influences; i++) {
ok(exp_vertices[i] == vertices[i],
influence[%d]: expected vertex %u, got %u\n, i,
exp_vertices[i], vertices[i]);
-ok(exp_weights[i] == weights[i],
+ok((isnan(exp_weights[i]) isnan(weights[i])) ||
exp_weights[i] == weights[i],
I put this in for now to fix the tests, but isnan() isn't really
portable, we should try to find a better way.
You can replace isnan(x) with (x != x), but isnan is specified by the
ISO C99 standard, so it should be portable.
signature.asc
Description: This is a digitally signed message part.
Re: libwine: Make addresses above 0x82000000 available on FreeBSD.
On Monday 20 September 2010 15:10:58 Alexandre Julliard wrote:
Tijl Coosemans t...@coosemans.org writes:
With this patch it is possible that a .dll.so is loaded beyond the
2GiB limit, but this does not seem to be a problem in practice. All
mmap calls from within Wine and thus all .dll stay below 2GiB and core
.dll.so such as ntdll, kernel32, user32,... are also loaded below 2GiB
because they are loaded early and are placed in the 32MiB mentioned
above. Also note that a .dll.so is only loaded above 2GiB when needed,
i.e. the program wouldn't have worked at all without this patch. It is
preferred that Wine at least makes an attempt at running the program
and therefore loosens the restriction on the use of addresses above
2GiB, especially since it seems to work so far.
It would be better to fix this properly. If there's no way to convince
FreeBSD's mmap to use all available space, you'll have to move the
loader down to make some room.
I've attached a patch that takes a different approach. I still need to
test it more extensively, but is this patch acceptable in principle?
It adds an mmap symbol to the loader thereby overriding the libc symbol.
This captures all calls to libc mmap and allows modifying the address
argument if needed. It doesn't capture cases that call the kernel
syscall directly, so shared libraries for instance are all still loaded
in the narrow address space close to the 2GiB boundary. This patch also
increases that space to 48MiB. It might work, but needs more testing.
diff --git a/libs/wine/mmap.c b/libs/wine/mmap.c
index b400189..296ffa9 100644
--- a/libs/wine/mmap.c
+++ b/libs/wine/mmap.c
@@ -200,11 +200,6 @@ void *wine_anon_mmap( void *start, size_t size, int prot,
int flags )
if (!(flags MAP_FIXED))
{
-#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
-/* Even FreeBSD 5.3 does not properly support NULL here. */
-if( start == NULL ) start = (void *)0x11;
-#endif
-
#ifdef MAP_TRYFIXED
/* If available, this will attempt a fixed mapping in-kernel */
flags |= MAP_TRYFIXED;
diff --git a/loader/main.c b/loader/main.c
index 628a0fa..2b731a2 100644
--- a/loader/main.c
+++ b/loader/main.c
@@ -164,14 +164,30 @@ static int pre_exec(void)
return 1;
}
-#elif defined(__FreeBSD__) defined(__i386__)
+#elif (defined(__FreeBSD__) || defined(__FreeBSD_kernel__))
defined(__i386__)
+
+#include dlfcn.h
+
+static void *_mmap_init( void *addr, size_t len, int prot, int flags, int fd,
off_t offset );
+static void *( *_mmap )( void *addr, size_t len, int prot, int flags, int fd,
off_t offset ) = _mmap_init;
+
+static void *_mmap_init( void *addr, size_t len, int prot, int flags, int fd,
off_t offset ) {
+_mmap = ( void *( * )( void *, size_t, int, int, int, off_t )) dlsym(
RTLD_NEXT, mmap );
+return( _mmap( addr, len, prot, flags, fd, offset ));
+}
+
+void *mmap( void *addr, size_t len, int prot, int flags, int fd, off_t offset
) {
+if ((flags MAP_FIXED) == 0 addr == NULL )
+addr = (void *)0x11;
+return( _mmap( addr, len, prot, flags, fd, offset ));
+}
static int pre_exec(void)
{
struct rlimit rl;
-rl.rlim_cur = 0x0200;
-rl.rlim_max = 0x0200;
+rl.rlim_cur = 0x0100;
+rl.rlim_max = 0x0100;
setrlimit( RLIMIT_DATA, rl );
return 1;
}
signature.asc
Description: This is a digitally signed message part.
Re: base addresses of kernel32
On Sunday 04 July 2010 09:14:14 Илья Басин wrote:
2010/7/4 Marcus Meissner mar...@jet.franken.de
On Sun, Jul 04, 2010 at 10:04:01AM +0400, Илья Басин wrote:
One widely used dll injection technique is copying the dll path to
the target process memory and calling CreateRemoteThread() using
the address of LoadLibraryA as lpStartAddress. This relies on the
fact that all processes have the same base address of kernel32.dll
(and some other system dlls). On Wine only ntdll is always loaded
to the same base address, so it's potentially possible to do the
same for kernel32, right?
kernel32 is also loaded to the same base address.
(the Makefile has:
EXTRADLLFLAGS = -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b80
)
Are you seeing otherwise?
int main() {
HMODULE hKernel32 = GetModuleHandle(kernel32.dll);
printf(0x%8x\n, hKernel32);
}
[...@il winetest]$ wine a.exe
0x7edf
[...@il winetest]$ wine a.exe
0x7edf
[...@il winetest]$ wine a.exe
0x7ede
Is this on Linux?
Re: base addresses of kernel32
On Sunday 04 July 2010 12:10:36 Ilya Basin wrote:
int main() {
HMODULE hKernel32 = GetModuleHandle(kernel32.dll);
printf(0x%8x\n, hKernel32);
}
[...@il winetest]$ wine a.exe
0x7edf
[...@il winetest]$ wine a.exe
0x7edf
[...@il winetest]$ wine a.exe
0x7ede
Is this on Linux?
yes
In that case you should check if you have prelink installed and
then configure and build wine.
Re: configure.ac: detect libusb-1.0
On Wednesday 24 March 2010 18:43:22 Damjan Jovanovic wrote: On Wed, Mar 24, 2010 at 6:58 PM, Albert Lee tr...@forkgnu.org wrote: There are multiple libusb implementations (notably, Solaris libusb and FreeBSD libusb20) and it would be necessary to do an API test for those, rather than using pkgconfig. My patch already distinguishes between libusb-1.0 and libusb-0.1 - they have different headers, different libnames, and different pkg-config names. Freebsd's libusb20 has all symbols starting with libusb20_tr_: http://www.unix.com/man-page/FreeBSD/3/libusb20/ It also implements the libusb 1.0 API: http://www.unix.com/man-page/FreeBSD/3/libusb/
Re: libwine: Only partially reserve memory beyond 0x80000000 on FreeBSD.
On Tuesday 24 March 2009 12:36:05 Francois Gouget wrote: Tijl Coosemans a écrit : [...] Wine wants to allocate a few things in reserved areas, and because there were no reserved areas at all on FreeBSD it failed. That's bug 16023. My patch leaves enough reserved area for Wine to allocate these, but otherwise reservation isn't needed like it is on Linux. I have tested your patch here and the Flash installer still works. So I guess that means your analysis is spot on and that it's ok to apply it. Probably Alexandre will know. So, what do you think about this patch Alexandre? diff --git libs/wine/mmap.c libs/wine/mmap.c index d107fc7..8286052 100644 --- libs/wine/mmap.c +++ libs/wine/mmap.c @@ -344,9 +344,13 @@ void mmap_init(void) struct reserved_area *area; struct list *ptr; #ifdef __i386__ +char *user_space_limit = (char *)0x7ffe; +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) +reserve_malloc_space( 8 * 1024 * 1024 ); +reserve_area( user_space_limit, (char *)0x8200 ); +#else char stack; char * const stack_ptr = stack; -char *user_space_limit = (char *)0x7ffe; reserve_malloc_space( 8 * 1024 * 1024 ); @@ -377,6 +381,7 @@ void mmap_init(void) reserve_area( base, end ); } else reserve_area( user_space_limit, 0 ); +#endif #endif /* __i386__ */ /* reserve the DOS area if not already done */
Re: 16bit code generation
On Sunday 22 March 2009 04:00:16 Austin English wrote: Wine supports 16 bit apps, just not as well as 32-bit. Dan had an intern work on a 16 bit test suite (http://code.google.com/p/win16test/), which can be used to test 16 bit support, fwiw. Yes, this is what I meant to refer to. AFAIK this test suite isn't part of Wine because it needs Open Watcom. Now it seems gcc could be used (perhaps with some help from winegcc). There's more at http://sourceware.org/binutils/docs/as/i386_002d16bit.html
Re: libwine: Only partially reserve memory beyond 0x80000000 on FreeBSD.
On Saturday 21 March 2009 11:42:12 Francois Gouget wrote: Tijl Coosemans a écrit : I still would like to see this patch committed though, to fix bug 17718, but generally because the memory reservation doesn't fix anything and only causes problems. That's wrong. Memory reservation fixes bug 16023. Without it most applications fail to even start in FreeBSD 7.0. You can test for yourself, reverting my memory reservation patch and try to run the Flash Player 10 installer. You can grab this installer there: Wine wants to allocate a few things in reserved areas, and because there were no reserved areas at all on FreeBSD it failed. That's bug 16023. My patch leaves enough reserved area for Wine to allocate these, but otherwise reservation isn't needed like it is on Linux.
16bit code generation
I was reading through binutils documentation and came across this. Maybe it can be used to compile 16 bit tests. 3.2.4. 16-bit mode Binutils (2.9.1.0.25+) now fully support 16-bit mode (registers and addressing) on i386 PCs. Use .code16 and .code32 to switch between assembly modes. Also, a neat trick used by several people (including the oskit authors) is to force GCC to produce code for 16-bit real mode, using an inline assembly statement asm(.code16\n). GCC will still emit only 32-bit addressing modes, but GAS will insert proper 32-bit prefixes for them.
Re: libwine: Only partially reserve memory beyond 0x80000000 on FreeBSD.
On Saturday 21 March 2009 11:48:34 Francois Gouget wrote: Tijl Coosemans a écrit : I attached a typical layout. How did you get your memory layout? Did you use /proc? On my FreeBSD 7.0 VM /proc often gives me an error when I try to get the memory layout. It looks like it has to do with there being too many memory regions. So I can only get a map if I get it right after the memory reservation but before Wine has loaded all the dlls. It probably depends on the application though. It's just winedbg output. winedbg prog Wine-dbginfo share
Re: libwine: Only partially reserve memory beyond 0x80000000 on FreeBSD.
On Wednesday 18 March 2009 22:57:45 Roderick Colenbrander wrote: What exactly is the issue with OpenGL on Linux? Under OpenGL we have the same issue these days for both Nvidia and Ati hardware. Check http://bugs.winehq.org/show_bug.cgi?id=13335 which contains an early version of Alexandre his patch. There are still some issues with it (some threading one if I remember correctly) and most importantly on 64-bit Nvidia systems there are huge slowdowns. I have some Nvidia employee looking at that but haven't heard back. Thanks, so it is the same problem, except that on Linux mmap fails because large portions of address space have been reserved before 0x8000, and on FreeBSD it fails because everything has been reserved after 0x8000. I still would like to see this patch committed though, to fix bug 17718, but generally because the memory reservation doesn't fix anything and only causes problems.
Re: libwine: Only partially reserve memory beyond 0x80000000 on FreeBSD.
On Wednesday 18 March 2009 16:36:29 Francois Gouget wrote: Tijl Coosemans a écrit : After enabling the memory reservation code on FreeBSD last week, several games either suffer a performance loss or simply crash, often with GL_OUT_OF_MEMORY errors or similar out of memory errors from X libs. (Tested with nvidia driver and opensource r300 dri driver.) Which games can be used to reproduce this issue? Is one of them freely downloadable? Even better, can this issue be reproduced with a non-game application? Puzzle Quest is a game that starts up slowly and locks up before getting to the game menu. http://www.infinite-interactive.com/puzzlequest.php?page=demo Alex Kozlov (CCed) can give you more examples. He mentioned StarWolves, Warlords4, Erherlords, Soldier of Fortune Gold, Fall: Last Days og Gaia, Dominions3... Normal applications all seem to work. Also, won't this patch be obsolete once Alexandre completes his current OpenGL memory allocation work? That is, doesn't it just hide the problem rather than solving it? I don't know what Alexandre's work involves, but the problem here are malloc(3) and mmap(2) calls in code outside Wine. On FreeBSD mmap allocates upwards starting after the location of the executable + some malloc heap space. With everything above 0x8000 reserved and the wine executable located at 0x7bf0, there's only about 64MiB of address space left of which about 32MiB is currently designated malloc heap (loader/main.c:RLIMIT_DATA). The 32MiB that is left is just enough to contain all unix and Wine libs, and a 32MiB malloc heap seems to be enough for all normal applications. I attached a typical layout. It also causes other problems like: http://bugs.winehq.org/show_bug.cgi?id=17718 This bug mentions the following error: Fatal error 'Cannot allocate red zone for initial thread' at line 384 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 2) It would be nice to figure out how we get in init_main_thread(). Apparently there are only two possible cases: * 1) Some thread routines have detected that the library hasn't yet * been initialized (_thr_initial == NULL curthread == NULL), or * * 2) An explicit call to reinitialize after a fork (indicated * by curthread != NULL) I don't really understand why we would reallocate the stack in the first case so my guess is this happens through a fork. I've never been able to reproduce this and haven't looked at it very closely because the problem went away with this patch, but my best guess is case 1. The threading lib is only initialized when actually needed. And then perhaps it fails to allocate the red zone for the main process stack because that page has already been reserved. That doesn't explain why I can't reproduce it though. This patch only partially reserves memory, enough for the shared heap, virtual heap and wine top-down allocations, and leaves the majority unreserved. Isn't the memory reservation supposed to prevent Unix libraries from being mapped in this memory range? If so, won't leaving holes open us to this sort of trouble again? Also, besides FreeBSD's braindead stack allocation routines, why should this patch only be used on FreeBSD? If it's supposed to help with OpenGL memory allocation then shouldn't it be used on Linux too (which has the same issue with OpenGL)? The memory reservation is needed on Linux because mmap allocates downwards from the end of address space, so without reservation all libs end up far beyond 0x8000 close to the stack. On FreeBSD mmap allocates upwards so the layout in the attached file for instance looks the same with or without reservation. On FreeBSD the memory reservation doesn't really solve any problem. What exactly is the issue with OpenGL on Linux? Module Address Debug info Name (99 modules) PE3a- 3c6000 Deferred3dfpfpu PE3d- 3ea000 Deferred2dintmmx PE40- 83b000 Export etherlords PE 1000-10059000 Deferredbinkw32 PE 2100-21056000 Deferredmss32 PE 2200-22026000 Deferredmp3dec.asi ELF 7bf0-7bf03000 Deferredwine-loader ELF 7df02000-7df2d000 Deferredld-elf.so.1 ELF 7df3e000-7e078000 Deferredlibwine.so.1 ELF 7e078000-7e08b000 Deferredlibthr.so.2 ELF 7e08b000-7e175000 Deferredlibc.so.6 ELF 7e176000-7e21c000 Deferredntdllelf \-PE 7e19-7e21c000 \ ntdll ELF 7e21c000-7e232000 Deferredlibm.so.4 ELF 7e232000-7e365000 Deferredkernel32elf \-PE 7e25-7e365000 \ kernel32 ELF 7e365000-7e37f000 Deferredwsock32elf \-PE 7e37-7e37f000 \ wsock32 ELF 7e37f000-7e3ab000 Deferredws2_32elf \-PE
Re: WineHQ redesign
On Monday 08 December 2008 20:42:30 Jeremy Newman wrote: This is because of the font-size: medium. IE Renders medium text much larger than Gecko and Webkit. I prefer to use font-size: 12px;, but that disables IEs ability to change the text size via the page drop down. I will revert back to my method as this gives me the fine grain control over font size that I desire. That makes it unreadable on high DPI screens. What about 10pt or something?
Re: [PATCH 07/10] jscript: Added NaN handling to relational operators.
On Tuesday 14 October 2008 23:07:45 Jacek Caban wrote: --- dlls/jscript/engine.c | 28 dlls/jscript/tests/lang.js | 12 2 files changed, 28 insertions(+), 12 deletions(-) I'm not sure if this applies to javascript but if it does, you might want to add a test case for (( NaN == NaN ) === false ).
Re: Invalid '...' in resources
On Monday 02 June 2008 16:57:40 Francois Gouget wrote: The files below contain ' . . .' instead of '...'. This is invalid typographically in at least English, French and Russian. Could someone check if it is valid for the relevant languages: Dutch No.
Re: Configure question about Wine / HAL
On Saturday 17 May 2008 10:53:18 Jeroen Janssen wrote:
Kris Moore kris at pcbsd.com writes:
http://www.pcbsd.org/~kris/config.log
It seems something is wrong with your pthread library?
configure:12388: checking for dbus_connection_close in -ldbus-1
configure:12423: cc -o conftest -O2 -fno-strict-aliasing -pipe
-I/usr/local/include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/local/include/hal
-I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include
-L/usr/local/lib conftest.c -ldbus-1 -L/usr/local/lib -lhal -ldbus-15
/usr/local/lib/libdbus-1.so: undefined reference to `pthread_equal'
/usr/local/lib/libdbus-1.so: undefined reference to `pthread_cond_timedwait'
This patch to the port Makefile should fix it. The problem exists only
on FreeBSD 6 because libs like libdbus-1 aren't linked to a pthread
library and so when you link an executable with libdbus-1 some
threading lib needs to be explicitly specified as well. Just to confirm
this, can you post the output of ldd /usr/local/lib/libdbus-1.so on
FreeBSD 6?
--- Makefile.orig 2008-05-17 15:33:49.0 +0200
+++ Makefile2008-05-17 15:26:59.0 +0200
@@ -52,6 +52,7 @@
.if ${OSVERSION} 700041
${REINPLACE_CMD} 's/-lpthread/-lthr/g' ${WRKSRC}/configure
.endif
+ ${REINPLACE_CMD} '/ac_hal_libs=/s/$$/ -lthr/' ${WRKSRC}/configure
pre-build:
cd ${WRKSRC} make depend
Re: Configure question about Wine / HAL
On Thursday 15 May 2008 17:59:17 Kris Moore wrote: I was building the port, and hal / dbus were both installed. The funny thing was that the first time I built the port, it didn't even get this far, it said : checking for hal/libhal.h... no, but if I checked in /usr/local/include/hal, libhal.h was in there. Then I made a link to /usr/include ln -s /usr/local/include/hal /usr/include/hal and was able to get this far now. Can you upload the config.log file somewhere? Or mail it to me privately.
Re: Configure question about Wine / HAL
On Friday 16 May 2008 13:26:29 Kris Moore wrote: I just rebuilt wine 0.9.61 from ports, and same problem: checking dbus/dbus.h usability... yes checking dbus/dbus.h presence... yes checking for dbus/dbus.h... yes checking hal/libhal.h usability... yes checking hal/libhal.h presence... yes checking for hal/libhal.h... yes checking for dbus_connection_close in -ldbus-1... no Here's the complete build.log: http://www.pcbsd.org/~kris/build.log.gz Here's the package list of this chroot environment http://www.pcbsd.org/~kris/pkg_list For the record, I'm building wine in a chroot environment for usage in our PBI format. However, as you can see from the pkg_list, I have built all the various packages that should be required. I also tried building the port on my desktop directly, and had the exact same error, so I'm sure its nothing about the chroot environment causing this problem. Thanks, but I still want to have a look at config.log because I suspect /usr/local/include and /usr/local/lib aren't added to CPPFLAGS and LDFLAGS properly and config.log contains more info about that. It should be in the Wine build dir after running configure.
Re: Configure question about Wine / HAL
On Wednesday 14 May 2008 22:03:35 Kris Moore wrote: I'm trying to get Wine to compile with HAL support on FreeBSD, and running into this error: checking dbus/dbus.h usability... yes checking dbus/dbus.h presence... yes checking for dbus/dbus.h... yes checking hal/libhal.h usability... yes checking hal/libhal.h presence... yes checking for hal/libhal.h... yes checking for dbus_connection_close in -ldbus-1... no configure: error: libhal development files not found, no dynamic device support. This is an error since --with-hal was requested. What exactly is -ldbus-1? Is there a way around this? Configure is finding the dbus and hal headers properly, and they both work properly on the system. Are you building using the wine port? Because that should autodetect HAL when it's installed. If you're not using the port and running configure yourself you probably need to set LDFLAGS. Something like: env CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure --verbose --with-hal
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
Dan Kegel [EMAIL PROTECTED] wrote: On Sat, Apr 26, 2008 at 7:54 PM, L. Rahyen [EMAIL PROTECTED] wrote: 200 DPI limit is acceptable for most users. However, what this patch done by setting maximum to this small value (144) doesn't seems to be acceptable. Users really are lost if they set a too-high value. They don't know how to do alt+mouse_move. Thus simply setting the limit higher again would be a support nightmare; we got a preview of that on wine-users recently, with user after user panicking. But as I wrote in http://bugs.winehq.org/show_bug.cgi?id=9715 we can probably do something that will make everybody happy: arrange for winecfg to never let the user set dpi so high that winecfg is bigger than the screen. That's probably pretty easy to do. And we can probably make high-res users happier still by defaulting to Xft.dpi (used by Gnome and maybe KDE; it's set by default to 96, but is increased by some users of high-res displays). IMO the Mozilla page you linked to in the bug is the correct approach. Users should set the DisplaySize setting in their X server configuration (if it isn't detected automatically). And applications should (by default) use the X server DPI calculated from that. Applications overriding the X server DPI are bad when you start to run them remotely. If users want a graphical way of setting physical display size, then that's a job for the desktop environments to provide some tools to configure the local X server. The only time Wine should have to worry about DPI is when running apps that haven't been designed with high DPI in mind and therefore don't scale well (for instance when font sizes are set in points and other GUI elements are sized or positioned using pixels). But for those apps it might be good enough to provide a simple checkbox that says override DPI to 96 or some other sensible default value. I don't know if there actually are such apps.
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Sunday 27 April 2008 14:43:32 Dmitry Timoshkov wrote: Tijl Coosemans [EMAIL PROTECTED] wrote: If users want a graphical way of setting physical display size, then that's a job for the desktop environments to provide some tools to configure the local X server. Same applies to many other settings like fonts and colors. Wine uses the DPI setting only as a way to scale fonts, not as a general size scaler. No, fonts and colors aren't server side settings. DPI is. The only time Wine should have to worry about DPI is when running apps that haven't been designed with high DPI in mind and therefore don't scale well (for instance when font sizes are set in points and other GUI elements are sized or positioned using pixels). But for those apps it might be good enough to provide a simple checkbox that says override DPI to 96 or some other sensible default value. I don't know if there actually are such apps. Such apps would break in Windows as well, Win32 uses logical units for its GUI elements, not pixels. Ah, that's good to know. Then why not get rid of that slider all together? DPI settings are not a Wine issue and should not be solved by Wine.
Re: X developer's conference, April 16-18
On Monday 25 February 2008 17:49:42 Stefan Dösinger wrote: * Other things? Display settings at the window manager level: http://bugs.winehq.org/show_bug.cgi?id=3230 http://bugs.winehq.org/show_bug.cgi?id=10115 http://bugs.winehq.org/show_bug.cgi?id=10841
Re: PulseAudio as a sound output?
On Thursday 11 October 2007 04:02:22 Jan Zerebecki wrote: On Wed, Oct 10, 2007 at 06:22:19PM -0500, King InuYasha wrote: That way, there isn't a conflict between audio streams to send to audio output. Any mixing resolves this conflict, the only thing that does not support this is bare oss. I think OSSv4 does. Multiple applications can open the same device and the audio streams will be mixed.
Re: PulseAudio as a sound output?
On Monday 08 October 2007 14:43:30 Dave Phillips wrote: Well, first I'd suggest simply supporting ALSA as thoroughly as necessary or possible. It is the default kernel sound system, Wine may as well incorporate it as well as it can. Supporting the deprecated OSS API might be a good idea too, through ALSA's OSS-compatibility layer. As one devel noted, it may be a good idea to forego further development of things like the NAS and ESD servers until a more solid basis exists for ALSA/OSS. I just wanted to add that OSS isn't deprecated. ALSA is Linux-only. OSS is a multiplatform solution.
address space layout
Hi all! I had a user running FreeBSD 6.2, Xorg 7.3, ATI r200 DRI driver report a problem where running Warcraft3 crashed because it ran out of malloc heap space. The error was: Assertion failed: (texObj-DriverData != NULL), function r200BindTexture, file r200_tex.c, line 1098. fixme:ntdll:FILE_GetNtStatus Converting errno 12 to STATUS_UNSUCCESSFUL This error happens inside the r200 driver, errno 12 means ENOMEM. There was a bug report with a patch over at http://bugs.freedesktop.org/show_bug.cgi?id=12184 The patch gets rid of the assertion failure by doing proper error checking, but it doesn't solve the underlying problem of course, causing a NULL pointer dereference in Wine somewhat later: wine: Unhandled page fault on read access to 0x0058 at address 0x7e99cc84 (thread 0009), starting debugger... This isn't the first time such a problem appears, especially with games, so ultimately a solution has to be found. The problem is that the way Wine wants to setup the address space is really somewhat incompatible with the way FreeBSD mmap and malloc work. FreeBSD mmap allocates from the end of a process data segment upwards towards the stack. Linux mmap allocates from the stack downwards. FreeBSD (7.x) malloc doesn't fall back to mmap when it runs out of space in the data segment. Linux malloc does (I've been told). Because the wine process loads itself at 0x7bf0, this means on FreeBSD with mmap going up, both the data segment and all shared objects (like builtin dlls) sit squeezed between that address and 0x8000 since addresses above 0x8000 can't be used for builtin dlls. It's about 64Mb which is currently split 50/50 between heap space and shared objects. This works in a lot of cases, but sometimes a 32Mb heap isn't enough like in the example above, where I assume it's been taken up by textures and other graphics data. Linux doesn't have this problem because mmap allocates shared objects from 0x8000 downwards and can go beyond the address where wine is loaded if necessary. It can allocate extra heap space this way too when needed. Alexandre and I discussed this a couple weeks ago, but didn't really come up with anything. The problem back then (WoW) has since gone away (turned out to be a memory leak somewhere) so everything was left the way it was. Now it has turned up again however with a different program on a different setup, so it's something that really needs to be looked at. It could again be a memory leak in some other project's code, but then that just means the current situation isn't robust enough to deal with that, since it all does work on Linux. It appears that the only solution is to locate wine somewhere after 0x8000 instead of at 0x7bf0 and to allow mmap to allocate memory there. Then the data segment size limit can be set to 256Mb or something instead of 32Mb. The problem is then that builtin dlls are mmapped (by the runtime linker) well beyond 0x8000. Now I'm thinking, would it be possible to load dummy dlls somewhere in the first 2Gb of address space? Through which API calls can a program determine a dll is above 0x8000 by the way?
Re: [PATCH 1/2] loader: Reduce data segment size in wine-pthread/kthread on FreeBSD.
On Wednesday 26 September 2007 19:17:44 Charlie wrote: This is me. I guess I called git-format-patch from a terminal where I was root.
Re: [PATCH 2/2] configure: Build wine-kthread on FreeBSD.
On Wednesday 26 September 2007 19:24:24 Charlie wrote: This is me. I guess I called git-format-patch from a terminal where I was root.
Re: mlang: fix memory leaks in error path (found by Smatch).
On Monday 24 September 2007 14:20:51 Lionel_Debroux wrote: ConvertINetString leaks some heap memory in an error path. Found in Michael Stefaniuc's list of Wine potential bugs detected by Smatch. 2007-09-24 Lionel Debroux [EMAIL PROTECTED] * dlls/mlang/mlang.c: mlang: fix memory leaks in error path (found by Smatch). diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c index eb14ad0..c6274c5 100644 --- a/dlls/mlang/mlang.c +++ b/dlls/mlang/mlang.c @@ -635,9 +635,10 @@ HRESULT WINAPI ConvertINetString( pDstStrW = HeapAlloc(GetProcessHeap(), 0, cDstSizeW * sizeof(WCHAR)); hr = ConvertINetMultiByteToUnicode(pdwMode, dwSrcEncoding, pSrcStr, pcSrcSize, pDstStrW, cDstSizeW); if (hr != S_OK) - return hr; + goto cleanup; hr = ConvertINetUnicodeToMultiByte(pdwMode, dwDstEncoding, pDstStrW, cDstSizeW, pDstStr, pcDstSize); +cleanup: HeapFree(GetProcessHeap(), 0, pDstStrW); return hr; } This is a bikeshed issue really, but I wonder what Wine's policy on gotos like this is. Imo, it's better to add the HeapFree call to the if block and let the compiler work it out.
configure error
I get the following error running configure on FreeBSD: config.status: creating Makefile sed: 14: ./confstathEGAkR/subs-4.sed: unescaped newline inside substitute pattern There's one of those for every Makefile. The problem is with the following lines in configure.ac where I had to add '\\' to every line to work around the problem. Is this a FreeBSD only thing? AC_SUBST(DEPENDENCIES,### Dependencies:\\ \\ .INIT: Makefile\\ .BEGIN: Makefile\\ Makefile: dummy\\ -\$(MAKEDEP) -C\$(SRCDIR) -S\$(TOPSRCDIR) -T\$(TOPOBJDIR) \$(EXTRAINCL) \$(DEPEND_SRCS)\\ \\ \$(ALL_OBJS): \$(IDL_SRCS:.idl=.h)\\ \$(LEX_SRCS:.l=.yy.o): \$(LEX_SRCS:.l=.yy.c)\\ \$(BISON_SRCS:.y=.tab.o): \$(BISON_SRCS:.y=.tab.c))
static inline wine_get_fs etc
I'm looking at include/wine/library.h and was wondering why the wine_get_fs/gs/... are declared extern and not static like many other functions in that file. Is there any particular reason I'm not seeing? Their __asm__ block is also missing __volatile__ I believe.
Re: [FreeBSD] locating wine at 0x20000000
On Tuesday 08 August 2006 23:28, Alexandre Julliard wrote: Tijl Coosemans [EMAIL PROTECTED] writes: Only the super-user can increase the max limit. Other users can only decrease it. And all those unix shared libs (x11, etc.) need heap space as well. I don't know how much they all need. Maybe a 128Mb heap would be sufficient? That would bring us to 0x7400. Do you need to set the max limit? Isn't the current limit sufficient? No, it's the max limit. The FreeBSD kernel code is pretty clear on that: if (addr == 0 || (addr = round_page((vm_offset_t)vms-vm_taddr) addr round_page((vm_offset_t)vms-vm_daddr + lim_max(td-td_proc, RLIMIT_DATA addr = round_page((vm_offset_t)vms-vm_daddr + lim_max(td-td_proc, RLIMIT_DATA)); So, when the addr argument to mmap is NULL or somewhere in the text segment or maximum possible data segment it is pushed back to after the data segment, which of course works quite well for any normal unix program. Anyway, the situation is different in FreeBSD 7.0, so I need to think this over some more and do some more testing.
Re: [FreeBSD] locating wine at 0x20000000
On Tuesday 08 August 2006 20:05, Alexandre Julliard wrote: Tijl Coosemans [EMAIL PROTECTED] writes: Currently I lower RLIMIT_DATA to 0x1800 (384Mb) in wine-glibc and locate wine-pthread at 0x6400. Is this an acceptable location? There has to be enough room after wine-pthread + data segment for every lib and dlopen'ed object. Moreover, the data segment can't be too small because it's the malloc heap and the limit is inherited by the wineserver process. So this is a bit of a balancing act. It seems it would be preferable to set a much lower limit and raise it again before starting wineserver. Otherwise it creates a big range of memory that will be inaccessible to Windows apps, and force us to relocate pretty much all native dlls. Only the super-user can increase the max limit. Other users can only decrease it. And all those unix shared libs (x11, etc.) need heap space as well. I don't know how much they all need. Maybe a 128Mb heap would be sufficient? That would bring us to 0x7400. The other solution I guess would be to add a malloc implementation to libwine that overrides libc malloc. Maybe there are other platforms with older brk(2) style malloc implementation that could benefit from this as well? FreeBSD 7.0 has a more modern brk+mmap style malloc btw, so evetually this problem will disappear.
Re: libs/wine/config.c: use execve on FreeBSD
On Tuesday 08 August 2006 20:02, Alexandre Julliard wrote: Tijl Coosemans [EMAIL PROTECTED] writes: * use execve on FreeBSD Renaming the msvcrt function would really be better. Particularly since extern char **environ doesn't work right on all platforms. You mean prepending all functions with msvcrt_ or something? Or just execve?
Re: [FreeBSD] locating wine at 0x20000000
On Monday 31 July 2006 18:15, Tijl Coosemans wrote: On Monday 31 July 2006 16:22, Alexandre Julliard wrote: Tijl Coosemans [EMAIL PROTECTED] writes: So I was thinking of moving Wine to 0x2000. That would be the easiest solution by far, but, are there any potential problems with that? Yes, that's too low, apps can expect that address to be free. If you can't change the 512Mb thing then you should use something around 0x5000, but really the 0x7000 range would be preferable. I can lower the 512Mb with setrlimit and RLIMIT_DATA, but that would have to happen inside the preloader (using a direct syscall I suppose), which currently isn't used on FreeBSD and probably doesn't even work. So I'll add that to my todo list and use something in the 0x5000 range for now. It turns out I don't need the preloader for that... Currently I lower RLIMIT_DATA to 0x1800 (384Mb) in wine-glibc and locate wine-pthread at 0x6400. Is this an acceptable location? There has to be enough room after wine-pthread + data segment for every lib and dlopen'ed object. Moreover, the data segment can't be too small because it's the malloc heap and the limit is inherited by the wineserver process. So this is a bit of a balancing act.
Re: Tijl Coosemans : ntdll: Add FreeBSD default serial port device.
On Monday 07 August 2006 14:26, Marcus Meissner wrote: On Mon, Aug 07, 2006 at 07:13:04AM -0500, Alexandre Julliard wrote: Module: wine Branch: refs/heads/master Commit: e548d4083177125559f752d902907187cea60474 URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=e548d4083177125559f752d902907187cea60474 Author: Tijl Coosemans [EMAIL PROTECTED] Date: Sat Aug 5 23:12:22 2006 +0200 ntdll: Add FreeBSD default serial port device. --- dlls/ntdll/directory.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c index 47d018a..84624a8 100644 --- a/dlls/ntdll/directory.c +++ b/dlls/ntdll/directory.c @@ -175,6 +175,13 @@ #ifdef linux strcpy( ret, /dev/ttyS0 ); ret[strlen(ret) - 1] = '0' + num - 1; } +#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) +ret = RtlAllocateHeap( GetProcessHeap(), 0, sizeof(/dev/cuad0) ); Surely you mean strlen()+1. sizeof(hallo) might just be sizeof(char*) strlen would certainly be safer, but I think sizeof sees the string as an array here, not a pointer. In any case, I simply copy-pasted the #ifdef linux, so that would have to change as well.
[ws2_32] connect doesn't generate FD_CONNECT event in non-blocking mode
dlls/ws2_32/tests/sock.c:event_client:597: /* Prepare event notification for connect, makes socket nonblocking */ event = WSACreateEvent (); WSAEventSelect ( mem-s, event, FD_CONNECT ); tmp = connect ( mem-s, (struct sockaddr*) mem-addr, sizeof ( mem-addr ) ); if ( tmp != 0 ( err = WSAGetLastError () ) != WSAEWOULDBLOCK ) ok ( 0, event_client (%x): connect error: %d\n, id, err ); tmp = WaitForSingleObject ( event, INFINITE ); When dlls/ws2_32/socket.c:WS_connect returns 0 (because unix connect returns 0) no FD_CONNECT event is ever generated and the call on the last line above never returns. So who's wrong, the test case or WS_connect?
Re: msvcrt/libc clash?
On Wednesday 02 August 2006 13:52, Alexandre Julliard wrote: Tijl Coosemans [EMAIL PROTECTED] writes: The actual problem is probably with the _execve symbol, because FreeBSD doesn't have any of the spawn calls. So, how to solve this? The easiest is probably to rename ours to MSVCRT_execve. I just managed to work arround it. The problem was the execv call in libs/wine/config.c. In libc execv calls _execve which exists outside libc as part of the threading libs and is therefore dynamically resolved. This can be prevented by calling execve instead of execv. On to the next problem... pgp07rGW4qyyl.pgp Description: PGP signature
msvcrt/libc clash?
Somewhat further along the way of fixing Wine on FreeBSD I'm stuck with what appears to be a clash between msvcrt and libc. Attached is the output of running env WINEDEBUG=trace+msvcrt notepad. It looks like msvcrt's _spawnve is called to run a Wine process. The same happens when running the msvcrt file test (2nd attachment), where the test on line 563 and 565 fails. The actual problem is probably with the _execve symbol, because FreeBSD doesn't have any of the spawn calls. So, how to solve this? trace:msvcrt:DllMain (0x7cb5, UNKNOWN, 0x0) pid(8), tid(9), tls(0) trace:msvcrt:DllMain (0x7cb5, DLL_PROCESS_ATTACH, 0x1) pid(8), tid(9), tls(0) trace:msvcrt:msvcrt_init_mt_locks initializing mtlocks trace:msvcrt:msvcrt_init_io :handles (0x3c)(0x40)(0x48) trace:msvcrt:msvcrt_init_console :Opening console handles trace:msvcrt:msvcrt_init_args got notepad.exe, wide = Lnotepad.exe argc=1 trace:msvcrt:MSVCRT_setlocale (0 C) trace:msvcrt:_lock (19) trace:msvcrt:_lock (17) trace:msvcrt:_lock : creating lock #19 trace:msvcrt:_unlock (17) trace:msvcrt:_unlock (19) trace:msvcrt:DllMain finished process init trace:msvcrt:_spawnve :call (/usr/local/lib/../bin/wine), params (/usr/local/lib/../bin/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /usr/local/lib/../bin/wine.exe trace:msvcrt:_spawnve :call (/sbin/wine), params (/sbin/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /sbin/wine.exe trace:msvcrt:_spawnve :call (/bin/wine), params (/bin/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /bin/wine.exe trace:msvcrt:_spawnve :call (/usr/sbin/wine), params (/usr/sbin/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /usr/sbin/wine.exe trace:msvcrt:_spawnve :call (/usr/bin/wine), params (/usr/bin/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /usr/bin/wine.exe trace:msvcrt:_spawnve :call (/usr/games/wine), params (/usr/games/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /usr/games/wine.exe trace:msvcrt:_spawnve :call (/usr/local/sbin/wine), params (/usr/local/sbin/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /usr/local/sbin/wine.exe trace:msvcrt:_spawnve :call (/usr/local/bin/wine), params (/usr/local/bin/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /usr/local/bin/wine.exe trace:msvcrt:_spawnve :call (/usr/X11R6/bin/wine), params (/usr/X11R6/bin/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /usr/X11R6/bin/wine.exe trace:msvcrt:_spawnve :call (/home/tijl/bin/wine), params (/home/tijl/bin/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /home/tijl/bin/wine.exe trace:msvcrt:_spawnve :call (/usr/local/bin/wine), params (/usr/local/bin/wine explorer.exe /desktop), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /usr/local/bin/wine.exe trace:msvcrt:DllMain (0x7cb5, DLL_PROCESS_DETACH, 0x1) pid(8), tid(9), tls(2) trace:msvcrt:msvcrt_free_mt_locks : uninitializing all mtlocks trace:msvcrt:MSVCRT__fcloseall :closed (0) handles trace:msvcrt:_close :fd (0) handle (0x3c) trace:msvcrt:msvcrt_free_fd :fd (0) freed trace:msvcrt:_close :ok trace:msvcrt:_close :fd (1) handle (0x40) trace:msvcrt:msvcrt_free_fd :fd (1) freed trace:msvcrt:_close :ok trace:msvcrt:_close :fd (2) handle (0x48) trace:msvcrt:msvcrt_free_fd :fd (2) freed trace:msvcrt:_close :ok trace:msvcrt:msvcrt_free_console :Closing console handles trace:msvcrt:DllMain finished process free trace:msvcrt:_spawnve :call (H:\\projects\\wine\\wine\\dlls\\msvcrt\\tests\\msvcrt_test.exe.so), params (msvcrt_test.exe.so tests/file.c 3), env (Null) trace:msvcrt:_spawnve fullname: H:\projects\wine\wine\dlls\msvcrt\tests\msvcrt_test.exe.so trace:msvcrt:_spawnve :call (/usr/local/lib/../bin/wine), params (/usr/local/lib/../bin/wine msvcrt_test.exe.so tests/file.c 3), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname: /usr/local/lib/../bin/wine.exe trace:msvcrt:_spawnve :call (/sbin/wine), params (/sbin/wine msvcrt_test.exe.so tests/file.c 3), env (Custom) fixme:msvcrt:_spawnve only trying .exe when no extension given trace:msvcrt:_spawnve fullname:
[FreeBSD] locating wine at 0x20000000
Hello all, For the past week or so I've been getting to know Wine and trying to improve/fix the FreeBSD version. I've progressed somewhat since then, though there are still quite a few open issues. One of the problems on FreeBSD is that Wine is loaded at 0x7bf0. FreeBSD's mmap preserves some space for the data segment (about 512Mb by default) and every future call to mmap with NULL for the addr argument maps memory after that. This is the reason that win98 mode doesn't work, since the shared heap at 0x8000 isn't available and everything that gets dlopen'ed for instance is located beyond the 2G limit which some programs may not like. So I was thinking of moving Wine to 0x2000. That would be the easiest solution by far, but, are there any potential problems with that? pgpi81ieXrSuQ.pgp Description: PGP signature
Re: [FreeBSD] locating wine at 0x20000000
On Monday 31 July 2006 16:22, Alexandre Julliard wrote: Tijl Coosemans [EMAIL PROTECTED] writes: So I was thinking of moving Wine to 0x2000. That would be the easiest solution by far, but, are there any potential problems with that? Yes, that's too low, apps can expect that address to be free. If you can't change the 512Mb thing then you should use something around 0x5000, but really the 0x7000 range would be preferable. I can lower the 512Mb with setrlimit and RLIMIT_DATA, but that would have to happen inside the preloader (using a direct syscall I suppose), which currently isn't used on FreeBSD and probably doesn't even work. So I'll add that to my todo list and use something in the 0x5000 range for now. pgpsamwNEwYE7.pgp Description: PGP signature
