June 2002 - Wine-Devel - list.winehq.org

Lotus Notes R5 devel

by JJ Neff

I am a NON-Programmer (very few C C++ classes some time ago:-) I read that regulr Notes users are needed. I have been trying to run Notes with verying success for some time. I am a Notes Admin and have had some success with R5 under Wine. I run Debian unstable and use daily build Wine debs from gluck.debian.org. I regularly use IRC to get assistance or to try to troubleshoot. PLease let me knwo how I can best help jjneff(a)yahoo.com John __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 7, 2002

ttc & sbit patch

by Won Kyu Park

Hello, This is a quick hack for ttc fonts and it enables embeded sbits in ttc/ttf with a recent freetype library. It is based on a Korean patch but I don't know who make it :-) Regards, Won kyu Park

June 7, 2002

RE: null midi device

by Johan Gill

On Fri, 7 Jun 2002, degs wrote: > I'd still have thought that some more general way to get at Wine MIDI output > would be more useful - like the ALSA output that someone suggested, or maybe > Arts. That way at least people have a choice what synthesiser they use - > timidity isn't everyone's cup of tea. > > I might be able to help with this If anyone was going to have a stab at it. I like that approach. Since I am personally motivated, I'll have a look. /Johan Gill, johane(a)lysator.liu.se

June 7, 2002

RE: null midi device

by degs

I'd still have thought that some more general way to get at Wine MIDI output would be more useful - like the ALSA output that someone suggested, or maybe Arts. That way at least people have a choice what synthesiser they use - timidity isn't everyone's cup of tea. I might be able to help with this If anyone was going to have a stab at it. -- degs -----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com]On Behalf Of Chris Sent: 06 June 2002 23:49 To: wine-devel(a)winehq.com Subject: Re: null midi device Exactly. There are at least two Win32 games (one from the Win95 age and another from the Win98 era) that require the presence of a MIDI device. The game Final Fantasy VIII supports MIDI via DirectMusic, so a DirectMusic implementation would solve that, but Final Fantasy VII still uses the old Windows MIDI device (old meaning it's not using DirectMusic, which is a more modern solution). So, I think a null midi device is still a good idea, I just haven't had the time to look into it too much. (summer plans?) On Thu, 2002-06-06 at 07:22, Johan Gill wrote: > degs wrote: > Final Fantasy VII uses midi for music, that's my reason. > > /Johan Gill, johane(a)lysator.liu.se -- Chris chris(a)luethy.net

June 7, 2002

WinExec16 in shlexec.c

by Steven Edwards

Can we use CreateProcess here instead if WinExec? I only have this and about 6 other things stopping the mingw build Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

June 7, 2002

Minor build system change for the Windows ports

by Steven Edwards

Anyone got any input on this? We need to be able to link to imports for kernel32 other then the standard libkernel32.a. Mingw doesn't keep all of the kernel32 import information in libkernel32.a instead it is like MSVC where it has a libth32.a and libthunk32.a. What is needed here is a change to the build system that allows for importing of these libs at link time when building a dll that needs those exports. Psapi.dll needs the toolhelp lib and one of the directx dlls needs the libthunk. I submitted a dirty patch for this a week or two ago but it wasn't accepted. The other option is to make the "make implib" rule and change the search path for the import libs. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

June 6, 2002

Re: Error messages when typing Hebrew characters

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > I tried repeating Hetz's experiment, and run the command "LANG=he_IL > wine notepad", and then type a few (random) Hebrew chars. I get the > following messages on screen: > > Warning: Language 'he_IL' was not found, retrying without country name... Probably LOCVAL(LOCALE_SISO3166CTRYNAME,"HE") in dlls/kernel/nls/heb.nls is wrong and "HE" should be replaced by "IL" (at least Windows 2000 reports "IL"). Windows2000 also reports LOCALE_SISO639LANGNAME = "iw". It would be a good idea to revise all fields in that file. > fixme:edit:EDIT_EM_FmtLines soft break enabled, not implemented > fixme:win:GetProcessDefaultLayout ( 0x40556df4 ): No BiDi > err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CEA > (hebrew_finalkaph) : > err:keyboard:X11DRV_ToUnicode (virtKey=4C,scanCode=26,keycode=2E,state=2010) > err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CF9 > (hebrew_shin) : > err:keyboard:X11DRV_ToUnicode (virtKey=41,scanCode=1E,keycode=26,state=2010) > err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CEC > (hebrew_lamed) : > err:keyboard:X11DRV_ToUnicode (virtKey=4B,scanCode=25,keycode=2D,state=2010) > err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CE3 > (hebrew_dalet) : > err:keyboard:X11DRV_ToUnicode (virtKey=53,scanCode=1F,keycode=27,state=2010) > > I tried following X11DRV_ToUnicode around a bit, but hit a brick wall at > the X11 function "TSXKeysymToString". Anyone has any idea why the Hebrew > characters are not being translated correctly (the character names are > correct). First of all: are hebrew keyboard input works in a native X11 text editor? What reports xev? (And it would be a good idea to add setlocale(LC_CTYPE,""); at the very first lines of xev.c, recompile it, and check whether it still works). -- Dmitry.

June 6, 2002

Re: dlls/shell32/dialogs.c:RunFileDlg - implemented

by Nix N. Nix

On Thu, 2002-06-06 at 11:20, Nix N. Nix wrote: > On Thu, 2002-06-06 at 09:14, Mike McCormack wrote: > > > > You'd better use cvs diff -u (you can add diff -u to your ~/.cvsrc so as > > not to forget). > > > > You should just submit the changelog entries like this: > > > > Well, here it is with these mods then. I removed the stuff from the > ChangeLog file. Everything quoted below still holds. > > > ChangeLog: > > Added RunFileDlg with MRU list (based on the template found in > > Win98 shell32.dll) Added template to all .rc files Translated the hungarian copy of "Wine was brought to you by" > > > > Looks like good work though! I have updated the patch such that it modifies shell32_*.rc (except shell32_xx.rc, of course) to include the dialog box template. I have translated where I could. I also translated the "Wine was brought to you by:" string in shell32_Hu.rc . If you want me to put that in a separate patch, please let me know. > > > > Mike > > > > Nix N. Nix wrote: > > > I implemented RunFileDlg from dlls/shell32/dialogs.c, together with the > > > MRU list that Windoze has. I placed the MRU list stuff in the same > > > registry key as in Windoze. I had to add a dependency. The > > > "&Browse..." button requires commdlg. I didn't know how to do this in > > > the Makefile, so I used LoadLibraryEx. > > > > > > Well, here it is (diff is against CVS from around Wed Jun 5 16:00:00 > > > EDT 2002) > > Thanks for the help.

June 6, 2002

RE: Where is ELF stab documented?

by Medland, Bill

> -----Original Message----- > From: Medland, Bill [mailto:Bill.Medland(a)accpac.com] > Sent: Thursday, June 06, 2002 3:57 PM > To: Wine devel (E-mail) > Subject: RE: Where is ELF stab documented? > SNIP > > There is a GNU stabs documentation but I think it is not > complete. The > > only complete one might be the one in the gcc source :/ > > That's what I thought. Thanks anyway. > > Bill > or maybe http://sources.redhat.com/gdb/onlinedocs/stabs_toc.html Bill

June 6, 2002

Re: Winehq: Bugzilla responsibilities page

by Francois Gouget

On Thu, 30 May 2002, Andriy Palamarchuk wrote: [...] > > I really don't think adding a sort of "duplicate" page is going to > > help with the Wine users Agreed. The web site already has way too much redundancy and off-topic stuff (making progress though). > > My reasoning is: how many external winehq maintainers do we have ? > > how many main AppDB maintainers ? How many FAQ-O-Matic maintainers ? > > How many documentation writers ? How many translators ? How many > > regular application testers ? (Almost) all are tasks that even a > > non-programmer can easily handle given some dedication... All these should be listed on the 'How to contribute' page. For the above, a call for volunteers posted on wine-dev, wine-users, the newsgroup and the WWN would probably help too. > Agree. > Lets remove talkback.inc, make a link to the contrib > page from development page too. The contrib page may > also have a link to the bugzilla repsponsibilities > page. The 'How to Contribute' page should be made more visible. I would put it as a top-level item, same as About, Development, etc. It may require a web site reorganization but I think it is worth it. For a proposal see: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=608 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

June 6, 2002

RE: Where is ELF stab documented?

by Medland, Bill

> -----Original Message----- > From: Marcus Meissner [mailto:marcus(a)jet.franken.de] > Sent: Thursday, June 06, 2002 3:26 PM > To: Medland, Bill > Cc: Wine devel (E-mail) > Subject: Re: Where is ELF stab documented? > > > On Thu, Jun 06, 2002 at 03:14:45PM -0700, Medland, Bill wrote: > > 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. > > It appears not harmful (libstdc++ is pulled by libXrender.so here). > > Oh and the new debugging format of gcc 3.1 is DWARF-2, not stabs > anymore. > > There is a GNU stabs documentation but I think it is not complete. The > only complete one might be the one in the gcc source :/ That's what I thought. Thanks anyway. Bill

June 6, 2002

Re: Do we need Direct3D? How about OpenGL?

by Chris

Yea. I don't like the idea of putting off D3D. If we can find a few people to start it, I think we should go ahead and do it. On Thu, 2002-06-06 at 10:50, Lionel Ulmer wrote: > On Thu, Jun 06, 2002 at 01:24:04PM -0300, Roland wrote: > > I just thought about this. AFAIK most good 3D games support OpenGL anyway. > > Well, that is if you are a fan of Q3A-derived shooters.. Otherwise, most > other games are D3D only. > > Lionel > > -- > Lionel Ulmer - http://www.bbrox.org/ > -- Chris chris(a)luethy.net

June 6, 2002

Re: null midi device

by Chris

Exactly. There are at least two Win32 games (one from the Win95 age and another from the Win98 era) that require the presence of a MIDI device. The game Final Fantasy VIII supports MIDI via DirectMusic, so a DirectMusic implementation would solve that, but Final Fantasy VII still uses the old Windows MIDI device (old meaning it's not using DirectMusic, which is a more modern solution). So, I think a null midi device is still a good idea, I just haven't had the time to look into it too much. (summer plans?) On Thu, 2002-06-06 at 07:22, Johan Gill wrote: > degs wrote: > Final Fantasy VII uses midi for music, that's my reason. > > /Johan Gill, johane(a)lysator.liu.se -- Chris chris(a)luethy.net

June 6, 2002

Re: How big is the Direct3D stuff?

by Chris

Alright, so, are there any people out there that would like to work on a Direct3D implementation for the winehq.com tree? I'd love to contribute but I don't know D3D well enough (I'll read up on it). I'm hoping there're a few people out there that would like to, yes? On Thu, 2002-06-06 at 09:00, Lionel Ulmer wrote: > Hi all, > > As I once started working on Direct3D in Wine and was one of the contributor > to the DDraw code, let me answer some of these questions :-) > > > * What are the tasks for implementing Direct3D? > > It's not easy to separate the tasks. For one, documenting and > re-appropriating the DDraw code would be the first thing to do. > > <start of minor rant> > > As other people discussed it, the current DDraw code in WineHQ's CVS tree is > from TransGaming. I do not say that it's worse than the previous code (it's > certainly better and respects the DLL separation stuff), but my biggest > problem with it is that it was entirely developped 'in-house' and sumbitted > 'as is' to the WineHQ tree without really involving any of the WineHQ > DirectX developpers (like Marcus or me). Now don't undertand this wrong, I > am certainly also to blame because I found other interests at that time and > mostly stopped working on Wine. > > This means that now that TG does not really contribute back much to WineHQ > (even in pure 2D stuff), we have a large piece of code that nobody really > bothered to undertand and is largely unmaintained. > > Now I understand why Linus absolutely refuses big patches doing a lot of > stuff in one go and wants small incremental patches :-) > > Finally, saying 'now let's start working on Direct3D' will not help much if > we do not find at least 3 or 4 people interested in working on it. I once > submitted some D3D work but nobody ever contributed to it and it was mostly > unmaintained once I stopped working on it (and I fear that would be the same > for other parts of Wine like Multimedia, the debugger for example, if Eric > did take some prolonged vacations :-) ) > > So the current situation is *not* TransGaming fault, but largely the > 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 :-) ). > > <end of minor rant> > > > * Can older versions be implemented independently from the newer ones? > > This is the big problem when doing DDraw work, designing stuff that : > > a) can work accross multiple DDraw versions (ie find the common stuff and > implement hardware acceleration here and then doing the rest in some > 'emulation' layer). > > b) can work accross multiple object 'types' (for example, a surface can be > the front / back buffer, a texture, a ZBuffer, a compressed texture, some > random buffer, an overlay, ...). > > c) respects the DLL separation (ie puts all 'hardware' related stuff like > X11 calls or OpenGL in the X11drv). > > > * Do we have nothing at all or do we have something? What changes need > > to be done to this something to make it better. > > We still have the old Direct3D code that I wrote to support DirectX 5 / 6 in > CVS (not functionnal, but enough to see the ideas :-) ). > > > * What modifications are necessary to other parts (x11drv, DirectDraw) > > to implement Direct3D? > > As said before, a lot of X11drv work and a DDraw rework :-) > > > * Are there other DirectX areas that are lacking and that will prevent > > games from working even if we get Direct3D working (DirectPlay, > > DirectInput)? > > Mostly all the DirectX 8 (Dinput and DSound 8) if we want to support > Direct3D 3. Otherwise, we should have almost everything needed in the other > DirectX stuff to implement Direct3D. > > > * One item I can suggest is adding support for XVideo to DirectDraw (I > > believe that's where it fits) to enable hardware scaling and YUV > > conversion when playing videos. This would be more for media players > > than games but could be useful anyway. > > I have a patch than I am slowly working on to re-add the Xv support to DDraw > (it's based on some work that Marcus did). But as explained before, it's not > that easy to do :-) > > Lionel > > -- > Lionel Ulmer - http://www.bbrox.org/ > -- Chris chris(a)luethy.net

June 6, 2002

Re: Where is ELF stab documented?

by Marcus Meissner

On Thu, Jun 06, 2002 at 03:14:45PM -0700, Medland, Bill wrote: > 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. It appears not harmful (libstdc++ is pulled by libXrender.so here). Oh and the new debugging format of gcc 3.1 is DWARF-2, not stabs anymore. There is a GNU stabs documentation but I think it is not complete. The only complete one might be the one in the gcc source :/ Ciao, Marcus

June 6, 2002

Where is ELF stab documented?

by Medland, Bill

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

June 6, 2002

Re: opengl32 wglSwapLayerBuffers

by Lionel Ulmer

> 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/

June 6, 2002

Re: imports by ordinal

by juergen.schmied＠debitel.net

>> 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

June 6, 2002

RE: How big is the Direct3D stuff?

by Patrik Stridvall

> 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.

June 6, 2002

RE: How big is the Direct3D stuff?

by Roland

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. Please keep your twisted logic for youself, I won't bother discussing this anymore, I have better things to do... Roland

June 6, 2002

GlobalAlloc returning memory that isn't 8-byte aligned?

by Warren_Baird＠cimmetry.com

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

June 6, 2002

Re: winebootup

by Dustin Navea

--- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > On Tue, Jun 04, 2002 at 10:52:07PM -0500, Jeremy > White wrote: > > Hetz Ben Hamo wrote: > > > > >I've seen in the crossover office that there is a > reboot.so file, but I think > > >thats codeweaver's closed source part since it's > not part of wine itself (if > > >I'm not mistaken) > > > > > > > Well, when we were hip deep in preparation for > CrossOver Office, > > Andreas had just started doing a full set of boot > processing logic. > > I had a conversation with Andreas about it; > convinced that his was > > the 'right' approach, but that it wouldn't be > ready soon enough for us, > > we hacked together something quick and dirty. > > > > The idea was that Andreas was to have been done by > now, hint, hint <grin>. > > > > Andi? > /me better won't reveal his feelings now :-\ > > I'm attaching the current implementation of > programs/wineboot. > I removed all GUI code and made sure that it still > works, but it's not > fully ready yet, I think (configuration settings, > for example). > I always planned to finish it, but with 50 mails in > my "reply" queue > and Linuxtag looming, the prospects for this are a > bit grim at the moment... > Also, I feel that I'm still a bit unsure as to how > exactly it should > be implemented: > - how exactly are we going to check for new "bootup" > entries to be processed ? Same way windows does, when the program is run, check autoexec.bat, winstart.bat, win.ini, system.ini and the registry... > - when exactly would it be run when the user feels like it, or optionally at linux boot, or optionally when wine is started, but that would be a pain if the stuff to be started had nothing to do with the program being run... > - etc. etc. > > In case someone wants to work on it, feel free. > Otherwise I'll continue to work on it when I've got > a lot more free time, > i.e. in August/September. > I will take a look at it when i get a chance... -Dustin __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 6, 2002

Re: How big is the Direct3D stuff?

by Joerg Mayer

Please move the License part of this thread to wine-license Thanks Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

June 6, 2002

Problems converting DLL to unix SO with winelib

by list＠vmn.com.br

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

June 6, 2002

Problems converting DLL to unix SO with winelib

by list＠vmn.com.br

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

June 6, 2002