wine-devel June 2002

wine-devel@winehq.org

96 participants
211 discussions

Where is ELF stab documented?
by Medland, Bill 06 Jun '02

06 Jun '02

For the sheer heck of it I was going to have a look at bug 650. I know its not a high priority or anything but it intrigued me. Anyway, to look into it I would want decent documentation on the format of the stab/stabstr sections of the ELF files to understand what the parser should be doing. Does anyone know where I can find that information? I didn't see anything immediately in the Intel v1.1 specification. Bill

2 1

Re: opengl32 wglSwapLayerBuffers
by Lionel Ulmer 06 Jun '02

06 Jun '02

> I do think it's odd as well since a more basic function can handle it. > fixme:opengl:wglSwapLayerBuffers (0000087c, 00000001) > ..repeated until exiting the game. > > So it's basically switching the main layer over and over again? Yes, so they are simply 'emulating' SwapBuffers with the 'wglSwapLayerBuffers' call (as they only request swapping of the main buffer as shown by the 0x00000001 parameter given to the fuPlane parameter). > I don't think it uses other layers. Because I think there would be a > graphics corruption if it did. None have been observed so far. Anyway, as seen in the trace you posted, they seem to not use it. > Heh, since I'm a beta tester, I can ask blizz why they even use this > function, and see if they respond. You could always try... > And it's the best running game I've seen running under wine. =) A pity I am not a fan of RTS games :-) Lionel (wondering if MacOS X is not to thank for all those OpenGL + D3D games coming out) -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: imports by ordinal
by juergen.schmied＠debitel.net 06 Jun '02

06 Jun '02

>> I'd like to use in a internal wine-dll(shell32) a function exported >> by an other dll(shlwapi) by ordinal. How can I do this in a clean >> way without use of GetProcAddress in a way it works with native >> dll's too? >You have to use GetProcAddress, there is no automatic import >mechanism. That's a feature to discourage you from calling ordinal >functions ;-) shlwapi.dll exports quite a lot of functions to shell32 what would mean a lot of duplicate code ;-(. juergen

1 0

RE: How big is the Direct3D stuff?
by Patrik Stridvall 06 Jun '02

06 Jun '02

> At 08:37 PM 6/6/02 +0200, Patrik Stridvall wrote: > > >I'm not distracting. I wasn't refering to anything you said. > >I merely stated that whether you agree or not I don't consider > >to be of your concern. > > This will be my last email to this thread. You originally said: > > > > > > >Secondly who are you to tell people what they can or can't do > > > > > >for a living? > > And this is nonsense, since I didn't say anything like that. If the sentence implies that you said that then perhaps it is because english is not my main language. A better formulation would perhaps be: Secondly what other people do for living is not of your concern. This was an reaction to your statement: "What do you mean by 'bought out'? I suppose there where WINE contributors who now work for TG, right? If this is the case it is another point in favour of the LGPL..." This I interpreted as you MIGHT be against that some of Wine's contributors starting working with Transgaming and that is was POSSIBLE that you thought (or hoped) that a LGPL:ed Wine would have prevented that. Thus I replied as I did in the event that you really was against it. I should perhaps have formulated myself better, though. You one the other hand shouldn't interpreting everything litterary. This is especially true when discussing things with non native english speakers. > Please keep your twisted logic for youself, I won't bother > discussing this > anymore, I have better things to do... I don't think logic have very much to do with it in this case. It lies more in the realm of miscommunication.

1 0

RE: How big is the Direct3D stuff?
by Patrik Stridvall 06 Jun '02

06 Jun '02

> At 08:10 PM 6/6/02 +0200, Patrik Stridvall wrote: > > > > >Secondly who are you to tell people what they can or can't do > > > >for a living? > > > > > > Huh? Did I say it was wrong what they did? Please provide > > > some evidence, > > > otherwise apologize... > > > >It was not meant as an accusation, merely a statement that > >it is not of your concern what other people do. > > Please don't try to distract. I'm not distracting. I wasn't refering to anything you said. I merely stated that whether you agree or not I don't consider to be of your concern. > Someone mentioned that > programmers got bought > out, then I asked what that meant exactly. I never said, that > I didn't > agree with programmers working for TG. In fact I think there > is nothing > wrong with that. So I didn't tell anyone they shouldn't do it. > Ok? So then we agree. Good.

2 1

GlobalAlloc returning memory that isn't 8-byte aligned?
by Warren_Baird＠cimmetry.com 06 Jun '02

06 Jun '02

Hi all, It looks to me like the wine implementation of GlobalAlloc is only returning addresses that are 4 byte aligned, not 8-byte aligned as MSDN says it should... Unfortunately on Sparc-Solaris double values need to be 8-byte aligned, and if GlobalAlloc is returning 4-byte aligned addresses - this is pretty hard. I'm afraid I don't really understand all of the magic going on in dlls/ntdll - I tried redefining ARENA_SIZE_MASK to ~7 instead of ~3, but this caused seg-faults in various places... Any suggestions on how to convince GlobalAlloc to actually return 8-byte aligned addresses would be greatly appreciated! Warren

1 0

winebootup
by Dustin Navea 06 Jun '02

06 Jun '02

After searching through the docs to see why there isnt any code in wine to run the normal windows bootup routines, i.e. Run/RunOnce/winboot.ini, see bug 717, I found something mentioning winebootup in the programs directory. I did a search for it on my whole system and didn't find it. What happened to it? Does anyone still have an old copy of it, I would like to put some of it's code directly into wine, or maybe reimplement it if it was problematic... Any info/help would be appreciated... -Dustin __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

4 4

RE: How big is the Direct3D stuff?
by Patrik Stridvall 06 Jun '02

06 Jun '02

> At 07:04 PM 6/6/02 +0200, Patrik Stridvall wrote: > > >First of all since it was in parts their code the could have > relicensed > >it to whatever they wished, so that wouldn't have been that large > >problem. > > No quite true. If the code is based on previous LGPL code, > they couldn't > relicense it, unless they also coded all of that previous > stuff. That's the > whole point of the LGPL. Obviously the author can relicense his code to whatever he wish. Now if if there are LGPL:ed parts that his code depends on he must remove them and if he wishes make his code usable in other contexts rewrite the LGPL:ed parts. Note that copyright only covers unique expression. Whether some his code was based on facts or ideas discover by authors of LGPL:ed licensed code doesn't count as far as copyright law is concerned. Also note that the LGPL has been fulfilled by since the other LGPL authors can keep his code so it will be quite hard to make additional claims especially since as I said copyright only protects unique expression. > >Secondly who are you to tell people what they can or can't do > >for a living? > > Huh? Did I say it was wrong what they did? Please provide > some evidence, > otherwise apologize... It was not meant as an accusation, merely a statement that it is not of your concern what other people do.

3 2

Problems converting DLL to unix SO with winelib
by list＠vmn.com.br 06 Jun '02

06 Jun '02

Hello All At Wine-Devel! I am trying to convert a win32 DLL to a unix SO. The dll named if32dt is basically a wrapper over the serial port, interfacing some custom hardware. It is therefore a driver to the custom hw. This is part of a project to port a windows sales app to linux. There are about 6 DLLs with similar structure and my aim is to show my superiors that using winelib is much better than simply rewriting the DLL to use unix system calls. 1) I have sucessfully copied my project over to unix and built the so file The project is basicaly a couple of headers and the c file ifdt32.cpp bash# cd ifdt32/ bash# mv ifdt32.cpp ifdt32.c #the file is plain C , cpp was confusing gcc bash# winemaker --nomfc -imsvcrt.dll -I/usr/local/include/wine/msvcrt --dll . bash# ./configure bash# make bash# make install The DLL uses msvcrt so I added it. => I read some issues between msvcrt and crt in winehq.com After changing a couple lines of ifdt.c I was able to build libifdt.so . I had a lot of warnings like ifdt32.c:176: warning: comparison between pointer and integer My ifdt32.spec file is unchanged from what winemaker created name ifdt32 type win32 mode dll init DllMain import msvcrt.dll import advapi32.dll import comdlg32.dll import gdi32.dll import kernel32.dll import ntdll.dll import odbc32.dll import ole32.dll import oleaut32.dll import shell32.dll import user32.dll import winspool.drv ifdt32.c only uses msvcrt.dll, ntdll.dll , kernel32.dll, user32.dll I added simple printf calls to DllMain to see if it was being called when the SO is loaded make install correctly put libifdt.so in /usr/local/lib I ran ldconfig in /usr/local/lib with bash# ldconfig -v -n . libifdt32.so -> libifdt32.so libwine_unicode.so -> libwine_unicode.so.1.0 libwine_tsx11.so -> libwine_tsx11.so.1.0 libwine.so -> libwine.so.1.0 2) I created a trivial program to test libifdt.so bash# cat test.c #include "windows.h" #include "stdio.h" #include "stdlib.h" #include "string.h" #include "io.h" #include "conio.h" #include "fcntl.h" #include "direct.h" #include "time.h" #include "IFfunc32.h" printf("before start"); int main(void) { printf("before start"); if( IF_IFDT32_OPEN("COM2") == 0 ) { printf("We are working") ; } else { printf("Oh no!"); } } bash# make gcc -g -c test.c -I/usr/local/include/wine -I/usr/local/include/wine/msvcrt -I/home/nwine/ifdt32/ifdt32 gcc -o test test.o -lifdt32 -L/usr/local/lib This program seg faults. I have not been able to debug it with winedbg, it simply hangs with message "Starting with pid 0" bash# gdb test (gdb) b 1 Breakpoint 1 at 0x8048556: file test.c, line 1. (gdb) r Starting program: /home/nwine/ifdt32/test/test Breakpoint 1, main () at test.c:15 15 printf("before start"); (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x400387cb in dllname () from /usr/local/lib/libifdt32.so (gdb) bt #0 0x400387cb in dllname () from /usr/local/lib/libifdt32.so #1 0x8048563 in main () at test.c:15 #2 0x40057f9b in __libc_start_main () from /lib/libc.so.6 (gdb) p dllname $1 = "ifdt32" In this trace, it seems that a function named dllname is causing a segfault There is a string named dllname and it's contents are correct I think the winelib initialisation code has not been correctly called For example: the Dllmain function to start the DLL has not been called I have tried a great many things to work around this problem with no success. It is hard to debug because the seg fault happens very early and I havent been able to get winedbg to work. I have tried this on wine-20020509 and wine-20020122 with exactly the same problem. Thanks a lot for any help or pointers. Miguel Feitosa Sao Paulo - Brasil P.S> output of bash# ldd ifdt.dll libwine.so => /usr/local/lib/libwine.so (0x40010000) libwine_unicode.so => /usr/local/lib/libwine_unicode.so (0x40026000) libm.so.6 => /lib/libm.so.6 (0x40103000) libc.so.6 => /lib/libc.so.6 (0x40125000) libdl.so.2 => /lib/libdl.so.2 (0x40245000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000) ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

1 0

RE: How big is the Direct3D stuff?
by Patrik Stridvall 06 Jun '02

06 Jun '02

> At 06:00 PM 6/6/02 +0200, Lionel Ulmer wrote: > >community's for not doing anything at all and letting things > in the state it > >was (well, not TG's fault except if you consider that they > 'bought out' the > >people who would have worked on it in their free time, but > that is just > >plain good business sense :-) ). > > What do you mean by 'bought out'? I suppose there where WINE > contributors > who now work for TG, right? Yes. > If this is the case it is another point in favour of the LGPL... First of all since it was in parts their code the could have relicensed it to whatever they wished, so that wouldn't have been that large problem. Secondly who are you to tell people what they can or can't do for a living?

3 2

← Newer
1
...
14
15
16
17
18
19
20
21
22
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel June 2002