wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Wintab.dll technical issues.
by Robert North 25 Nov '02

25 Nov '02

Firstly a quick note: I have opened a bug for implementation of wintab.dll (Bug No. 1160) Now the questions: 1: Writing stubs. I'll be taking up Patrik Stridvall's offer to write stubs for anyone new to wine development. One question about stubs: What's the wine policy on stub return values? Should a stub always return an error? Should/Can it return success? 2: Testing wintab.dll in Win98. wintab.dll is quite complex for what it does. Therefore the only practical way to implement it is to work on the functions and communication models that are used by the apps I want it to support. To do this, I need some tool that can log the function calls and parameters to the DLL, while wunning Win98.The logging must be able to let the programmer choose elements from data stuctures in parameters/retvals to log. Any ideas???? I've attempted to use apis32 and built a wintab.fnl file for wintab.dll. Unfortunately apis32 doen't allow the logging of the contents of data structs. I would also like to know experinces with Spy++. Wintab can send it's own custom messages, so I'm wondering how good Spy++ is at detecting custom messages? I've used it many times before, but only to examine standard windows messages. 3: Coding standards. I haven't found any coding standards associated with wine. This is particularly important, as I'll be writing new source files. Can someone point me to the standards? Hope you guys have the answers -Rob.

5 5

[RFC] pthread emulation on FreeBSD (and Linux)
by Patrik Stridvall 25 Nov '02

25 Nov '02

With the attached patch FreeBSD compiles again even if OpenGL (which need pthreads) is used. Since it is only stubs at present OpenGL can't really work, but Wine and the normal test runs fine ("make test"). Anyway, to answer the first obvious question: Why didn't you just put it in scheduler/pthread.c? Well, the thing is it didn't work. It still generates the same link errors. However that is not very suprising since the pthread_ implementation is in ntdll.dll which is not linked with during the "-Bsymbolic -z defs" step. This begs the question: Does the Linux implementation of pthread really work anyway? The thing is Linux (or rather the GNU C library) always links in pthread suppport. However since some of the symbols are on purpose defined as weak they can be overriden. This is what scheduler/pthread.c does on Linux. Or rather tryies to do. I'm not really sure if works any longer. Note that if I apply the attach patch and compiles on Linux it seems to work with "make test" as well. Anyway be pthreads on Linux working properly as it may, the big question is how do we support pthreads on both Linux and FreeBSD. FreeBSD since it AFAICS have no default overridable implementation seems to require that we have some sort of wine_pthread library to implement pthreads from scratch like outlined in the attached patch. I'm not really very good on how runtime linking on Linux and FreeBSD. So, I would very much like comments from people more knowledgeable than I on that area. Comments? Suggestions? PS. Can somebody test if OpenGL:s pthread locking REALLY works properly on Linux?

3 2

Re: Screwed up textures in OpenGL apps
by David D. Hagood 25 Nov '02

25 Nov '02

Dan Kegel wrote: > Please verify that booting with just one CPU active > doesn't fix the problem. e.g. at lilo prompt, do something like > linux nosmp > It could be that Wine doesn't support SMP yet. > > - Dan > > First thing I tried, and with no change, so I don't think it's a SMP issue. Furthermore, my other apps under Wine work fine, only the OpenGL ones die.

2 2

Visual Basic runtimes?
by Mike Hearn 25 Nov '02

25 Nov '02

Hi, (btw, thanks to ove and alexandre for catching my patch booboo). Anyway, I'm trying to install Tipic IM (tipic.com), and once I figured out how to install .msi files in wine (hint: install ie6 then run msiexec /i foo.msi) I hit the lack of VB runtimes. It appears the MSI file assumes you already have msvbvm50 and msvbvm60 installed, but of course I don't. Tracking these down on the net wasn't too hard, but I'm wondering whether Wine could ship with them included or would it require a cleanroom implementation of these DLLs? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

1 0

RE: [RFC] pthread emulation on FreeBSD (and Linux)
by Patrik Stridvall 25 Nov '02

25 Nov '02

> On Sun, 24 Nov 2002, Patrik Stridvall wrote: > > > Anyway, to answer the first obvious question: > > Why didn't you just put it in scheduler/pthread.c? > > > > Well, the thing is it didn't work. It still generates the > > same link errors. However that is not very suprising since > > the pthread_ implementation is in ntdll.dll which is > > not linked with during the "-Bsymbolic -z defs" step. > > scheduler/pthread.c should be linked into libwine, which is > linked into > everything, at least this is the idea and was the case last time I > checked. It is not so in the current CVS of Wine: scheduler/pthread.c is linked with ntdll not with libwine. However libwine is not an appropriate place for the pthread implementation since the pthread implementation needs to call Windows API functions. libwine is a strictly Unix API library AFAICS. That why I made a new libwine_pthread library. > > This begs the question: > > Does the Linux implementation of pthread really work anyway? > > Works in WineX (though we needed some more hacks in it to > make it interact > well with the nvidia opengl drivers), and it'd surprise me if > it doesn't > still work in Wine, as the OpenGL deployed by most linux > distros wouldn't > work *at all* under Wine if it didn't, and people currently seem to be > working on Wine as if it did work. True. However, while I can't say I really understand how runtime linking work, I still feel that something is wrong. > > The thing is Linux (or rather the GNU C library) always links > > in pthread suppport. However since some of the symbols are > > on purpose defined as weak they can be overriden. This is > > what scheduler/pthread.c does on Linux. Or rather tryies to > > do. I'm not really sure if works any longer. > > It's not the weak symbols that allow overrides, weak symbols > only allow > the pthreads library to *not* be linked in (so your statement > about always > linking it in is untrue). Weak symbols work such that until > the library is > linked in, they are just null pointers, and glibc only calls > them if they > aren't null. Overriding symbols can only be done by linking > things in the > right order (link the wine overrides before the real pthread lib), and > since libwine is loaded before > opengl-linked-against-pthreads, the libwine > pthread implementation is used instead of the pthreads linked > in later, > and this don't need a special kind of symbol to work. OK. Thanks for the explaination. As I said not my area or expertise. > > Note that if I apply the attach patch and compiles on > > Linux it seems to work with "make test" as well. > > > > Anyway be pthreads on Linux working properly as it may, the big > > question is how do we support pthreads on both Linux and FreeBSD. > > I'd say link -lwine in before -lc_r, but then I don't know much about > FreeBSD. It is already done that what eventhough: 1. We current link with -lc not -lc_r, but maybe we should. 2. scheduler/pthread.c is as I said earlier in ntdll not libwine, so I can't see how linking can work and futhermore is doesn't for empirical evidence. > > FreeBSD since it AFAICS have no default overridable implementation > > seems to require that we have some sort of wine_pthread library to > > implement pthreads from scratch like outlined in the attached patch. > > The scheduler/pthread.c is basically the same thing, since it needs to > override every single pthread symbol used by apps, otherwise > the override > fails (or if it would be successful, it would still be incomplete). > > Stupid question: the reason for the missing symbols on FreeBSD isn't > because of the #ifdef __GLIBC__ in scheduler/pthread.c, is it? No, I would have to be VERY tired to make that mistake. :-) But since your premise scheduler/pthread.c in libwine is wrong that might be the answer. However it still doesn't explain why OpenGL seems to work on Linux. Perhaps it is because Linux have weak symbols or whatever concerning pthreads in libc and everything is OK because of this...

1 0

Off Topic: Off-list help needed with SGML Tools please
by Dustin Navea 25 Nov '02

25 Nov '02

For some reason I cant get SGMLTools to compile properly, everything but jade compiles but when it goes to compile that, I get a bunch of errors. I could leave out jade but thats what Im needing to compile to build sgml docs... I have tested this with Slackware 8.1 default GCC and the prepackaged GCC 3.2.1 Source from Slackware-current and neither would compile it. I also tested that its not just Slackware's GCC... Redhat 8.0 would not compile it either with GCC 3.2.1... So if anyone can help me it would be most appreciated.. I still have a couple of other things to try (installing the latest slackware binutils, and trying out CVS sgmltools, if i can ever connect to the cvs server) :/ -Dustin

1 0

Exe, Com and PATH
by Sylvain Petreolle 25 Nov '02

25 Nov '02

Wanting to run msdos debugger, I ran from c:\ : wine debug. the 2 debug that exists on my fake windows are c:\debug.com c:\windows\command\debug.exe My PATH variable is set as "Path" = "c:\\program\ files\\java\\j2re1.4.0_01\\bin;c:\\windows;c:\\windows\\command;c:\\windows\\system32;c:\\windows\\system;e:\\" Currently running wine debug from c:\ runs c:\windows\command\debug.exe,ignoring debug.com in the current directory. This is not the behaviour expected in real windows. These are 2 problems here : - Normally dos looks first in current directory => would load c:\debug.com. There is a problem with PATH here. - Putting 2 files with a .exe and .com with the same name in the same directory loads the .exe first, which shouldn't happen. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Fwd: Problem with network functions
by Sylvain Petreolle 24 Nov '02

24 Nov '02

Does someone has a clue for this / has same issues ? I cant figure how to find what is causing the network errors I have. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Bug #416: Missing Exports in Winsocks
by Andrew John Hughes 24 Nov '02

24 Nov '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch adds stubs for the functions listed in Bug #416, SetService{A,W} and GetTypeByName{A,W}. License: LGPL - - -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE94VftSE/kMce1ABARAipUAJ0ew9mD8eqn+2HrS1Yk72lvy+h4QACfaIeV uPloEX9A/xk4ptC6l0Xl5Z4= =K3YG - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE94VggSE/kMce1ABARAleXAJ40B6etNGsPhlZdm7GoqCrvYpGwpACgiU/o 2chi+d/NOUGg3WhHjj31UwQ= =Za8w -----END PGP SIGNATURE-----

1 0

Re: Some additions to D3D
by Alexandre Julliard 24 Nov '02

24 Nov '02

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > Note (for Alexandre): how would you prefer for us to track dependencies > between patches ? Submit each time a patch agains fresh CVS with all > previous patches sent (with an ever growing changelog) or do you prefer > (like here) a lot of patches dependant one on the others ? > If it's the latter, do we need to do 'letter tracking' as Dimi did ? In general separate patches are better; the exception is if they are fixes to a previous patch then it's better to resend all so I don't have to try to understand the broken version before reading the fix. And yes, in either case please find a way to clearly mark the sequence, don't rely on the submission order because mail doesn't always arrive in the correct order. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: _ fstati64
by Stefan Leichter 24 Nov '02

24 Nov '02

Am Sonntag 24 November 2002 11:11 schrieben Sie: > ChangeLog > ------------- > converted implementation of _fstat to _fstati64 > implemented _fstat by calling _fstati64 > Hello Alexandre, this patch is relative to my patch _stati64 please apply the _stati64 patch before this one. The _stati64 patch went to the worng list by accident. Thanks Stefan

1 0

Screwed up textures in OpenGL apps
by David D. Hagood 24 Nov '02

24 Nov '02

I'd asked this before, but received no response, so I'll ask it again. Does anybody have any suggestions on where to start debugging textures being wrong under OpenGL apps under Wine? Specifically, I am trying to get HalfLife-Blue Shift to run, but all the "static" textures (walls, floors, etc.) are screwed up. The "dynamic" textures on things like people are fine. Now, I USED to have Halflife running great, but then I upgraded my system to a SMP P3 system (I had been running a UMP P3) (the old system died.) All my native apps (Q3A, RTCW, gears, etc.) are just fine. Only Windows apps running under Wine are screwed up. Does anybody have a simple Windows OpenGL app I can use for testing? Or a direction to begin looking in? I do know this - forcing OpenGL to go to indirect rendering does NOT fix the textures - they are still just as screwed up, just a lot slower.

2 1

Re: [Fwd: [Bug 688] - make documentation produces only files as 'x6772.html']
by Tony Lambregts 24 Nov '02

24 Nov '02

Tony Lambregts wrote: > Vincent Béron wrote: > >> Hi guys, >> >> Alexandre just committed my patch concerning the documentation building >> process. Could you verify it works for you? >> >> >> > I am sure it is something on my end but I get the following when I > "make html", "make everything" > > docbook2html -d ./default.dsl -o wine-devel wine-devel.sgml > Using catalogs: /etc/sgml/sgml-docbook-3.1.cat > Using stylesheet: ./default.dsl > Working on: /usr/local/src/wine/documentation/wine-devel.sgml > jade:E: cannot find "./default.dsl"; tried "./default.dsl", > "/usr/share/sgml/./default.dsl" > jade:E: specification document does not have the DSSSL architecture as > a base architecture > ..... > spews out sgml > .... > > It must be something I've done but I have no idea what, since > db2html -d ./faq-plain.dsl wine-faq.sgml > jade:E: cannot find "./faq-plain.dsl"; tried "./faq-plain.dsl", > "/usr/share/sgml/./faq-plain.dsl" > jade:E: specification document does not have the DSSSL architecture as > a base architecture > > > same thing. WTF. > Ok heres what I have found. "db2html -d ../faq-plain.dsl wine-faq.sgml " works, However if I use "db2html -d ./faq-plain.dsl wine-faq.sgml " it blows chunks. as I reported. So the change to two dots works, which makes sense, therfore I changed the Makefile so that SRCDIR = .. and re-ran "make html" and produces the html beautifully. So all that tells me is "There is something wrong here" ./ should work (right?) -- Tony Lambregts

3 5

Re: dosconf move
by Alexandre Julliard 24 Nov '02

24 Nov '02

"György 'Nog' Jeney" <nog(a)sdf.lonestar.org> writes: > Is there any reason why this patch has not been applied? This is essentially > the same as my dosconf try 3 patch but for your convinience I made a new diff > against the current cvs. It's really ugly to export the DOSCONF structure as part of the DOS module interface. I think it's better to wait until that stuff can be moved without having to export it. -- Alexandre Julliard julliard(a)winehq.com

2 2

RE: wintab.dll: Copyright & trademark issues.
by Patrik Stridvall 23 Nov '02

23 Nov '02

> As I mentioned in an e-mail a couple of days back, > I'm about to start implemening a version of wintab.dll. > First I want to ask about legal issues: > > 1. trademark issues. > > wintab is a trademark. > Does this impact on the ability to implement wintab.dll No, I can't see how. Everything we will reasonable do with the name are either unrelated to trademarks or are used in reference to what is protected by the trademark. > 2. API header files. > Please look at the licence for the API files, avaialable at the > following URL: > http://www.pointing.com/Wintab/WTKIT126.ZIP > Does this allow our use of the headers, in Wine? > Does it allow the use of fragments of the headers in Wine? >From the headers: < The text and information contained in this file may be freely used, < copied, or distributed without compensation or licensing restrictions. So the headers are basicly public domain. Specifically it is compatible with the X11 license and the LGPL so no problem. We could include the files as they are without any modification at all as far as copyright is concerned. Presumably we might need some compiler related fixes though. > This is not too much of an issue, as I understand it's OK to re-write > compatible headers "In your own words". True. > 3. I am in the UK, how does this affect the copyright/trademark issues > above? It is not likely to matter very much almost regardless of there you are in the world, copyright and trademark laws are usually not that different. UK is pretty normal AFAIK. > Ok, some background about wintab: > wintab.dll is an "open industry standard" API > developed by a group of tablet manufacturers, and seems to > be currently maintained by the company LCS/Telegraphics. > Web page for wintab: http://www.pointing.com/WINTAB.HTM > LCS/Telegraphics home: http://www.pointing.com/LCS.HTM OK. Seem to contain documentation and other things nessary or useful for implementing. I can see two issues though. 1. It is not an offical Microsoft DLL so should it be part of Wine or not? IMHO yes, it seems to be widely used. However Alexandre decides. 2. How do you expect to implement this presumably very complicted DLL? Does Linux have some special libraries for supporting tablets?

2 1

gcc 2.95.3 breakage
by Johan Gill 23 Nov '02

23 Nov '02

It seems that latest CVS does not work well with gcc 2.95.3. collect2 segfaults when linking user, it seems. Gnarl -- /Johan Gill, johane(a)lysator.liu.se

1 1

[bug 718] Executing dos DPMI programs
by Sylvain Petreolle 23 Nov '02

23 Nov '02

Does someone has success when executing DPMI programs ? Every program I try to execute at this time fails, going to the debugger, saying : Unhandled exception: privileged instruction in 32-bit code (0x00000000). In 32-bit mode. 0x00000000: int $0x31 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: [wine-users] Can't get Unreal to work in opengl mode
by Sylvain Petreolle 23 Nov '02

23 Nov '02

Have exactly the same error when trying to run Max Pane. Tried with --debygmsg +seh, but didn't give any clue. Perhaps weshould file a bugreport on bugs.winehq.com or try wine-devel. Anyone who knows about seh at wine-devel, could you say what makes this happen ? > err:seh:EXC_DefaultHandling Exception frame is not in stack limits => > unable > to dispatch exception. > -------------------------------------------------------------------------- > > Here is how I got it: > > I started Wine from the command line; the resolution changed from > 1024x768 > to 64x480; then I got the Unreal menu; I then selected 'options' and > then > 'advanced options'; Unreal popped-up a window where I chose 'drivers' > then > 'opengl support'; after that I got back to the desktop ('err:seh...' > line). > > Hope it helps. > > N.B. I checked my config.log again; ./tools/wineinstall did > > $ ./configure -C --enable-opengl > > All the opengl items got a 'yes' answer, except this one: > > -------------------------------------------------------------------------- > configure:6918: checking for thread-safe OpenGL version > configure:6938: gcc -o conftest -g -O2 -I/usr/X11R6/include > conftest.c > -L/usr/X11R6/lib -lGL >&5 > /tmp/ccc9a5Qz.o: In function main': > /home/fab/test/wine/configure:6930: undefined reference to > pthread_getspecific' > collect2: ld returned 1 exit status > configure:6941: $? = 1 > configure: failed program was: > #line 6925 "configure" > #include "confdefs.h" > > int > main () > { > pthread_getspecific(); > ; > return 0; > } > configure:6959: result: no > -------------------------------------------------------------------------- > > See you. > > -- > Fabrice DELENTE > E-mail : fabrice.delente(a)free.fr > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-users ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Menu selection algorithm
by Jeff Smith 23 Nov '02

23 Nov '02

Dmitry, I still have win95-osr2 loaded on a machine. Let me know what I need to run the test on that box and I would glad to do so if this would help out. -- Jeff S >From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> >"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > > > So, what's the problem - you ask? While my view of what should happen is > > obviously consistant with that of Wine's - i.e. - the locale should > > select which menu to use, Windows displays the English locale ONLY. The > > only way I could make it display the Hebrew one was by changing the > > language on the English one to something else (French). > >I revived my old test for FindResource and now I see what are you talking >about. >LoadStringA/W and FindResourceA/W under Win2000 do search for language >resource >in the following order: >1. Neutral language with neutral sublanguage >2. LANG_ENGLISH, SUBLANG_DEFAULT >3. LANG_ENGLISH, SUBLANG_NEUTRAL >4. Current locale lang id >5. Current locale lang id with neutral sublanguage >6. Return first in the list > >But that means that the whole our internationalization will not work, if >we will go that way. But the question I have is: had I made an error when >I did the test under Win95OSR2 or MS has changed algorithm since then? > >-- >Dmitry. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

Menu selection algorithm
by Shachar Shemesh 23 Nov '02

23 Nov '02

Hi list, Sorry if this is slightly off topic. I am having some trouble with a sample program I keep changing to death. This program is written in VC on Windows 2000, and being run on Wine as well. I added a Hebrew menu over an already existing English(US) one. My regional settings say that my global settings are Hebrew, as are my local settings. The two menus both have the same ID, and only the language is different between them. When VC's resource editor displays the menus, it displays one with (English U.S) appended, and the Hebrew one without any extension (implying it thinks this is the default one). So, what's the problem - you ask? While my view of what should happen is obviously consistant with that of Wine's - i.e. - the locale should select which menu to use, Windows displays the English locale ONLY. The only way I could make it display the Hebrew one was by changing the language on the English one to something else (French). Wine behaves as expected. running: wine TestApp Yields an english menu, while LANG=he_IL wine TestApp yields a Hebrew one. I wouldn't worry so much, except that since we define a bug in Wine as any inconsistancy with Windows, this is a bug. I'm mostly trying to understand why Windows won't do what it's supposed to do, however. I'm using "RegisterClass" to register a class with the menu identifier passed using "MAKEINTRESOURCE", and then just calling "CreateWindow" to create the window. Anyone has any ideas or suggestions, or just an opinion whether that should worry us at all? Shachar

2 2

Re: [Bug 688] - make documentation produces only files as 'x6772.html'
by Sylvain Petreolle 23 Nov '02

23 Nov '02

I can answer that 'make html' works beautifully and perfectly. Good job ! > ------- Additional Comments From vberon(a)mecano.gme.usherb.ca > 2002-11-22 19:32 ------- > Sylvain, Tony, Dustin, could you confirm that it works correctly now? > Alexandre > just committed my patch. > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Page fault with isspace(*p)
by John K. Hohm 23 Nov '02

23 Nov '02

I am rewriting the regsvr stuff in dlls/comcat to make it practical to extend to ole32 and all the other COM DLLs. I have a nice simple function to skip whitespace and return the next character: static int getc_skipws(char const **p) { while (isspace(*p)) ++*p; return **p; } This gets called with **p == '['. I get a page fault in the implementation of isspace(), where the macro is testing 0x20 against the value for '[' in the __ctype_b array. What gives?

1 1

Re: [Fwd: [Bug 688] - make documentation produces only files as 'x6772.html']
by Dustin Navea 23 Nov '02

23 Nov '02

On Fri, 2002-11-22 at 19:37, Vincent Béron wrote: > Hi guys, > > Alexandre just committed my patch concerning the documentation building > process. Could you verify it works for you? > > Thank you, > Vincent > ---- > > From: wine-bugs(a)winehq.com > To: vberon(a)mecano.gme.usherb.ca > Subject: [Bug 688] - make documentation produces only files as 'x6772.html' > Date: 08 Nov 2002 20:23:34 -0600 > > http://bugs.winehq.com/show_bug.cgi?id=688 > > > > > > ------- Additional Comments From vberon(a)mecano.gme.usherb.ca 2002-11-08 20:23 ------- > Please advise on which of the 2 attachments is the best. > Personnaly, I'd rather go with the second, because with the first one it creates > a directory with images, but those are unused. > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > <http://bugs.winehq.com/show_bug.cgi?id=688>. > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND > INSERTED IN THE BUG DATABASE. Well, I am still working on updating my status, turns out that since I upgraded to Slackware 8.1 the default gcc wont build the jade package of sgmltools properly and so I need to upgrade to the latest slack-prepared build of gcc... Then I will try making it again... and see what happens..

1 0

Wine & Boehm garbage collector
by François-Denis Gonthier 23 Nov '02

23 Nov '02

Hello Wine-Devel I have not filled a bug with this a some of you may already know a solution to this problem. I've a contributor to the Mono project (http://www.go-mono.com) working on the System.Windows.Forms namespace. It has been decided to use Wine to implement this assembly since the S.W.F is rather tightly bound to the Win32 API. But we are facing a nasty problem. Current Mono implementation is using Hans Boehm conservative garbage collector and Wine cannot seems to work happily with that garbage collector. The temporary solution for development is to use Mono without garbage collection. This solution however, should not even be considered when Mono and it's System.Windows.Forms implementation will go mainstream. I've joined a small test case so one can try. Wine just crash at the first call to GC_malloc. Any help or advice is appreciated. François-Denis Gonthier

4 6

where is the code that converts VARIANTS?
by Medland, Bill 23 Nov '02

23 Nov '02

Can anyone tell me where the code is that converts a VARIANT from VT_DECIMAL to VT_BSTR? Bill

2 1

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