Re: 64bit Wine?
On Mon, Dec 01, 2003 at 10:18:57PM +, J. Grant wrote: Hello I'm considering getting an Opteron. With this being a 64bit CPU I wondered if there would be any issues with using WINE to make use of win32 software on this 64bit CPU. There are no issues. SUSE LINUX 9.0 for AMD64 is capable of running all WINE products, including regular WINE, CrossOver Office, CrossOver Plugin and WineX in the 32bit compat mode. Ciao, Marcus
Status : Multimedia section
Hi, Here is the new layout of the Multimedia section of the Status Dll's page. May I ask what you guys here think of it?, constructive criticism? Tom Wine Status - DLLs Aspect or Component Documentation status WWN article coverage Implementation status (estimated) Recent primary workers Multimedia Low level drivers (audio, midi, mixer) ALSA ALSA Users Documentation #121 75% complete(x--) (basic support for MIDI) Sylvain Petreolle,Christian Costa aRtS aRts - documentation #118 25% complete(x--) AudioIO AudioIO Class Reference #131 20% complete(x--) JACK jack docs #139 25% complete(x--) NAS Network Audio System #131 20% complete(x--) OSS OSS Programmer's guide #110 95% complete(xxx) Eric Pouech mappers wave mapper (wavemap) None 80% complete(uses MSACM for audio codecs) Eric Pouech midi mapper (midimap) None 80% complete Eric Pouech MCI drivers CD audio driver (mcicda) None 100% complete Eric Pouech Wave driver (mciwave) None 60% complete( Problems with implementing mmtask.) Eric Pouech Midi driver (mciseq) None 60% complete( Problems with implementing mmtask.) Eric Pouech Video driver (mcianim, mciavi) None 60% complete( Problems with implementing mmtask.) Eric Pouech,Michael Gnnewig MSACM Codecs ADPCM None 50% complete G711: u/A law None 50% complete MP3 None 50% complete msvideo/msvfw32 Video codecs MSRLE32 None 100% complete Michael Gnnewig Multimedia DLL's avicap32.dll Video Capture Reference None 5% complete Eric Pouech avifil32.dll None 70% complete Michael Gnnewig mmsystem.dll None 80% complete Michael Gnnewig,Eric Pouech msvideo.dll/msvfw32.dll Multimedia Functions None 60% complete Michael Gnnewig winmm.dll None 80% complete Michael Gnnewig,Eric Pouech Miscellaneous Multimedia Components Multimedia joystick driver Joystick Functions None 80% complete Only implemented for Linux joystick API. Eric Pouech opengl32: OpenGL interface OpenGL Developer Documentation #2, #8, #44, #45, #158 90% complete Some compatibility problems. Lionel Ulmer
Wineinstall, Regedit seg faults
Hi I just tried to install wine (from cvs 2003-12-02) on a fresh install of Knoppix (Debian). Configure/Compile went fine but I got an error with regedit as already reported here: http://bugs.winehq.org/show_bug.cgi?id=1664 In my case: Compiling regedit... make: nothing to do for all Preparing to install default wine registry entries... Installing default wine registry entries... tools/wineinstall: line 648: 10747 memory access error $REGEDIT $DEFREG /dev/null Registry install failed. Is there something we can do to help? Anybody working on this? Thanks bye Fabi
Re: Wineinstall, Regedit seg faults
I just tried to install wine (from cvs 2003-12-02) on a fresh install of Knoppix (Debian). Configure/Compile went fine but I got an error with regedit as already reported here: http://bugs.winehq.org/show_bug.cgi?id=1664 Just wanted to add that starting 'wine regedit' and then importing the winedefault.reg works ok. bye Fabi
Re: Status : Multimedia section
What about the DirectShow and DMO side of things. Should they not be listed to complete the Multimedia picture? Mainly the filters in Quartz.dll and other basic filters that come with the OS. if you want me to, I can make a list of the Basic filters and Interfaces that are needed (and the dlls they are implemented in. but that is not Important in DS) . I'm not sure which of them get Installed when you download a new Media player from MS, and which ones are strictly OS. I do know that the status must be good if CrossOver is able to run Windows-Media-Player. Tom wrote: Hi, Here is the new layout of the Multimedia section of the Status Dll's page. May I ask what you guys here think of it?, constructive criticism? Tom
Re: Status : Multimedia section
Boaz Harrosh wrote: What about the DirectShow and DMO side of things. Should they not be listed to complete the Multimedia picture? Hi, DirectShow = Quartz.dll And DirectShow is listed under the DirectX section of the status page as Quartz.dll is a part of DirectX. http://www.winehq.com/site/status_dlls But have no fear, I plan to expand the DirectX section next and list msdmo, devenum, d3d9 and so on. :-) But in the future im going to just go with Quartz.dll and not DirectShow as people ask me to also list quartz.. Mainly the filters in Quartz.dll and other basic filters that come with the OS. If you can code im sure Robert would welcome the help :) if you want me to, I can make a list of the Basic filters and Interfaces that are needed (and the dlls they are implemented in. but that is not Important in DS) . Well so far we have only lised components that have to some degree been implemented in wine. Here is where I will cheat and ask, should I also list components that are not implemented? 0% items... I'm not sure which of them get Installed when you download a new Media player from MS, and which ones are strictly OS. I do know that the status must be good if CrossOver is able to run Windows-Media-Player. Yip.. And if you install the divx codecs into cx-plugin it will play divx movies :) Tom
Re: 64bit Wine?
On Tue, Dec 02, 2003 at 08:02:37AM -0600, Jeremy White wrote:
I'm considering getting an Opteron. With this being a 64bit CPU I
wondered if there would be any issues with using WINE to make use of
win32 software on this 64bit CPU.
There are no issues.
SUSE LINUX 9.0 for AMD64 is capable of running all WINE products,
including regular WINE, CrossOver Office, CrossOver Plugin and WineX
in the 32bit compat mode.
Okay, I read that to mean that you can run already built
32 bit binary versions of Wine.
What about compiling? Would compiling Wine on an Opteron
work? Hmm. I suppose you could cross compile to 32 bit,
couldn't you.
Well, I do ;)
SUSE 9.0 comes with full biarch toolchain support on AMD64.
Before you start, install additionaly to the default packages:
glibc-devel-32bit
freetype2-devel-32bit
XFree86-devel-32bit
XFree86-Mesa-devel-32bit
fontconfig-devel-32bit
openssl-devel-32bit
ncurses-devel-32bit
alsa-32bit
and any dependend rpms.
Then:
export LD=ld -m elf_i386
CC=gcc -m32 AS=gcc -c -m32 \
./configure --prefix=/usr --x-libraries=/usr/X11R6/lib
make depend all
The -m32 switches gcc to 32bit mode.
If you have arts-devel installed, you might need to patch
dlls/winmm/winearts/Makefile and replace lib64 by lib.
You will also need attached winebuild patch that uses LD from the environment.
Ciao, Marcus
diff -x CVS -ruN wine-20030217/tools/winebuild/import.c
marcus-wine-20030217/tools/winebuild/import.c
--- wine-20030217/tools/winebuild/import.c 2002-12-20 01:36:18.0 +0100
+++ marcus-wine-20030217/tools/winebuild/import.c 2003-01-13 17:54:10.0
+0100
@@ -569,7 +569,7 @@
static const char *ldcombine_files( char **argv )
{
int i, len = 0;
-char *cmd;
+char *cmd, *ldcmd;
int fd, err;
if (output_file_name output_file_name[0])
@@ -584,9 +584,11 @@
close( fd );
atexit( remove_ld_tmp_file );
+ldcmd = getenv(LD);
+if (!ldcmd) ldcmd=ld;
for (i = 0; argv[i]; i++) len += strlen(argv[i]) + 1;
-cmd = xmalloc( len + strlen(ld_tmp_file) + 10 );
-sprintf( cmd, ld -r -o %s, ld_tmp_file );
+cmd = xmalloc( len + strlen(ld_tmp_file) + 10 + strlen(ldcmd) );
+sprintf( cmd, %s -r -o %s, ldcmd, ld_tmp_file );
for (i = 0; argv[i]; i++) sprintf( cmd + strlen(cmd), %s, argv[i] );
err = system( cmd );
if (err) fatal_error( ld -r failed with status %d\n, err );
pgp0.pgp
Description: PGP signature
RE: Question about libwine_unicode functions and others in WINE
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steven Edwards Sent: 01 December 2003 00:03 To: [EMAIL PROTECTED] Subject: Question about libwine_unicode functions and others in WINE Hello, We are looking at porting more code from WINE to ReactOS and I am having trouble understanding the need for libwine_unicode as a shared library. Some of the functions that it exports such as CompareString are implemented in ntdll as RtlCompareString and then also used in shlwapi as per a recent patch. Wouldnt it better to import the function from ntdll and hide libwine_unicode or make the parts that we need to share a static library? In ReactOS we have created NT compatible NLS files. Could WINE do this also and dump libwine_nicode? As noted by others, we don't want to create an unnecessary dependency on ntdll and more importantly we don't want to scare people off by using undocumented functions everywhere. However, couldn't we just replace the libwine_unicode function with an appropriate (well-documented) kernel32 string function: strcatW - lstrcatW strcmpW - lstrcmpW strcpyW - lstrcpyW strlenW - lstrlenW ... etc It may add a little bit of overhead in Wine (which we could possibly solve by adding #define's for e.g. lstrcatW - strcatW), but it would solve the problem. We will still use libwine_unicode for the backend implementation of the string functions and for the tools, but it wouldn't matter for ReactOS. It would probably be best to add this as another janitorial project if we go for it. You can quite easily see which dlls use libwine_unicode as it links to it in the makefile. Rob
RE: Status : Multimedia section
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tom Sent: 02 December 2003 09:50 To: Boaz Harrosh Cc: Wine Development Subject: Re: Status : Multimedia section Boaz Harrosh wrote: What about the DirectShow and DMO side of things. Should they not be listed to complete the Multimedia picture? Hi, DirectShow = Quartz.dll And DirectShow is listed under the DirectX section of the status page as Quartz.dll is a part of DirectX. http://www.winehq.com/site/status_dlls But have no fear, I plan to expand the DirectX section next and list msdmo, devenum, d3d9 and so on. :-) But in the future im going to just go with Quartz.dll and not DirectShow as people ask me to also list quartz.. Mainly the filters in Quartz.dll and other basic filters that come with the OS. If you can code im sure Robert would welcome the help :) Definitely! If anyone would like to help with this please get in contact with me so I can help explain how I've implemented certain things so far, about locking, etc. The main things that are left to do to play 90% of media files out there are implementing the filter graph manager, the reference clock and the audio and video renderers (I have a hacky version of the video renderer in my local tree but it is not ready for submitting as a patch). Anyone that likes COM and graph algorithms should love the filter manager! I'm not sure which of them get Installed when you download a new Media player from MS, and which ones are strictly OS. I do know that the status must be good if CrossOver is able to run Windows-Media-Player. That must not be using the code in the Wine tree as it won't play any movies at the moment :( Rob
Re: Question about libwine_unicode functions and others in WINE
Robert Shearman [EMAIL PROTECTED] wrote: However, couldn't we just replace the libwine_unicode function with an appropriate (well-documented) kernel32 string function: strcatW - lstrcatW strcmpW - lstrcmpW strcpyW - lstrcpyW strlenW - lstrlenW ... etc No. The above APIs use SEH internally which make things a lot slower. I think ReactOS wants to avoid them as well, as much as possible and use some internal versions instead. -- Dmitry.
Re: Status : Multimedia section
Dear Robert I meant to drop you a note, ask what is the status. But you bit me to it. I have 7 years experience in writing DS filters. I am currently working on enhancing C++ on wine. I have ATL/WTL/MFC compiling and working under winelib. I have compiled COM controls generated by ATL VC++ wizards. I have some problems with the typelibs and so. But this is beside the subject. I would be happy to help in any way I can. I have lots of code that is not MS's. Also I have MS Direct Show Classes compiling and linking under Winelib (again some problems with the typelibs.) I have my own copyrighted DirectShow video render that is implemented on top of DirectDraw. It uses the Overlay Surfaces YUV or RGB what ever is available/requested. It will also fall back to HW (HardWare) memory surfaces that are not overlay. I did not yet implement the Memory surfaces support. (didn't need to but it should be easy to add them). I could release that code under wine I guess. If so I would also release the windows version of it. But before I do that, there are some issues to resolve (in order of importance): 1. C++ code must be accepted - This is not an area that C is good enough, and in any way I don't know C I am only good in C++ 2. What is the status of the DDraw lib. Will it support HW and Overlay 2D surfaces? (does it support HW BOB) 3. I am some what dependent on MS DirectShow Classes. (Derivation) I have a lot, self implemented, but some of the basic stuff I used. I guess I could reimplement them but it will take time. Do you know what is the license issues with this code. I know that I have delivered them to many paying clients, and it was checked by the legal department. I all ways thought that, that code is: Do what you like no liability what so ever. About the Graph manager: I'll think about it. I can certainly do it. But It is a big project. Do you know of a Company that would like to finance such a thing to some extent. ( condition 1 above applies C++ only). I'll think about it any way. Maybe it is not as big as I think. (Usually projects are much bigger then I think they are) Robert Shearman wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tom Sent: 02 December 2003 09:50 To: Boaz Harrosh Cc: Wine Development Subject: Re: Status : Multimedia section Boaz Harrosh wrote: What about the DirectShow and DMO side of things. Should they not be listed to complete the Multimedia picture? Hi, DirectShow = Quartz.dll And DirectShow is listed under the DirectX section of the status page as Quartz.dll is a part of DirectX. http://www.winehq.com/site/status_dlls But have no fear, I plan to expand the DirectX section next and list msdmo, devenum, d3d9 and so on. :-) But in the future im going to just go with Quartz.dll and not DirectShow as people ask me to also list quartz.. Mainly the filters in Quartz.dll and other basic filters that come with the OS. If you can code im sure Robert would welcome the help :) Definitely! If anyone would like to help with this please get in contact with me so I can help explain how I've implemented certain things so far, about locking, etc. The main things that are left to do to play 90% of media files out there are implementing the filter graph manager, the reference clock and the audio and video renderers (I have a hacky version of the video renderer in my local tree but it is not ready for submitting as a patch). Anyone that likes COM and graph algorithms should love the filter manager! I'm not sure which of them get Installed when you download a new Media player from MS, and which ones are strictly OS. I do know that the status must be good if CrossOver is able to run Windows-Media-Player. That must not be using the code in the Wine tree as it won't play any movies at the moment :( Rob
Re: Question about simple profiling implementation
On Tuesday 02 December 2003 04:13, Alexandre Julliard wrote: Andrew de Quincey [EMAIL PROTECTED] writes: However, if no one minds, I think I'll still implement the stuff I was doing. I found being able to examine the call tree with ballpark figures of how long was spent in each call was very invaluable. Note that the relay debugging adds a huge overhead, especially for functions that call other parts of Wine, so adding precise timings in there is pretty much useless. That may also explain why you get such strange results. I'm aware of that; I merely wanted them as figures showing which functions were were used the most. CharNextW specifically does not call any sub-functions, so will not generate any further delays by additional logging.
Re: new old winetests
On December 2, 2003 05:48 am, Ferenc Wagner wrote: Dimitrie O. Paun [EMAIL PROTECTED] writes: -- the mkdir() issue is still not 100% solved. We currently have: #ifndef _WIN32 # define mkdir(d) mkdir (d, 0777) #endif [...] Why don't we just link with msvcrt? Dimitrie O. Paun [EMAIL PROTECTED] also wrote: Doctor, it hurts when I do that... :))) I'd say, don't do it. Just use libc calls, don't link against msvcrt. That's why. To preserve our sanity. Maybe it's not worth it. :))) I know there was a reason, but I can't quite remember what the problem was. :) Or we can change the test to: #if defined(__unix__) !defined(__MSVCRT__) which should work with all: gcc/winegcc/mingw/msvc It may be the easier path. But this strongly depends on Alexandre's verdict. See the discussion on the other branch of this thread. Well, unfortunately, the mkdir() bit is a ugly wart. I've run into it in other projects (wxWindows comes to mind). If anyone can figure out a solution that doesn't involve modifying the app, let me know. Until then this should do. -- we use fatal() in remove_dir() Again, not a problem, but I'm wondering if we're not too strict. Sure, we are. In the beginning, nothing useful happened after remove_dir(), so I just didn't care. Moving send_file before this would be useful indeed. Someone someday may create a real UI for this and handle it properly. Until then, how about we replace the fatal() call to a warning() call which does not exit? -- running ELF tests When we do so, we use a hardcoded path for wine Oh yes, that's for me who does not have wine in the path. We could just remove the path, I could add wine to my PATH, and that's it. Well, let's do that then :) -- we're linking against ws2_32 Is this DLL available on all versions of Windows we want to run on? As far I know http://msdn.microsoft.com/library/en-us/winsock/winsock/windows_sockets_st art_page_2.asp yes. It's OK then. We need to depend on _something_ to send out the results, this seems like a decent dependency. I can't see any showstoppers Good to you. :) What do you think about Alexandre's cross- configuring idea? Well, it's a clean idea. The CROSSCC stuff that I've adopted from the tests it's a bit of a hack, and I do not understand why we have it in the first place. It's convenient, but a bit ugly (and I guess it survives since it's so small). However, as you pointed out, if we do use it for tests, why not for winetests, it fits in the same category, it's convenient, and we can use it almost as is (this is the only thing we do in our Makefile): winetests_cross.exe: $(CROSSOBJS:_so.res.cross.o=_pe.res.cross.o) $(CROSSCC) $^ -o $@ $(IMPORTS:%=-l%) $(LIBS) So Alexandre, what say you? :) We'd really like to get this in and move forward, there still so much work to do on this front. Let's not lose momentum. -- Dimi.
Re: new old winetests
Dimitrie O. Paun [EMAIL PROTECTED] writes: Well, unfortunately, the mkdir() bit is a ugly wart. I've run into it in other projects (wxWindows comes to mind). If anyone can figure out a solution that doesn't involve modifying the app, let me know. Until then this should do. Without modifying the app I don't know, but in this case you could use CreateDirectory instead. Well, it's a clean idea. The CROSSCC stuff that I've adopted from the tests it's a bit of a hack, and I do not understand why we have it in the first place. It's convenient, but a bit ugly (and I guess it survives since it's so small). However, as you pointed out, if we do use it for tests, why not for winetests, it fits in the same category, it's convenient, and we can use it almost as is (this is the only thing we do in our Makefile): winetests_cross.exe: $(CROSSOBJS:_so.res.cross.o=_pe.res.cross.o) $(CROSSCC) $^ -o $@ $(IMPORTS:%=-l%) $(LIBS) So Alexandre, what say you? :) We'd really like to get this in and move forward, there still so much work to do on this front. Let's not lose momentum. The crosstest stuff is a hack that's here to make it possible to do a quick check under Windows when you modify a test. I don't really see the same need for winetests, so I'd suggest we do things the clean way first. If it turns out we really need the hack we can always add it later. Also a minor detail: I'd propose to rename winetests to winetest, since we already have a directory by that name in CVS, it avoids having too many ugly useless dirs in the repository (plus it fits in a 8.3 file name ;-) -- Alexandre Julliard [EMAIL PROTECTED]
Re: Question about simple profiling implementation
Andrew de Quincey [EMAIL PROTECTED] writes: As you say, relay debugging adds a huge overhead... however, would you say that this overhead would be fairly constant for each particular function? No, it all depends on what other functions it is calling, and this may change for each call. I'm thinking of not outputting the raw values as they are quite misleading; instead percentages would probably be better. What do you think? I'd suggest you look into Charles' profiler support that was posted some time ago on wine-patches (and that I'll get around to merge someday, promised g). -- Alexandre Julliard [EMAIL PROTECTED]
Sound capture issues...
Hi list, in the voice com program Skype (www.skype.org), I'm able to hear other people but I can't talk to them myself. Does anyone have a clue why? I believe this program uses DirectX to capture voice input. Not implented? Greetings, --Thomas _ My worst enemy gave me a copy of Windows...
IDA speed problem analysis
Hi, I've been doing some more work on this, and I think I've found the culprit (my apologies to everyone for the crap I've been talking recently). Whenever IDA opens the Save box.. and in fact when it does a lot of operations, it seems to completely regenerate its menus. It uses an MDI interface, and so uses the WM_MDISETMENU message to set menus. The problem function is controls/menu.c/SetMenu(). Specifically, the call to SetWindowPos() passing the SWP_FRAMECHANGED flag. If I comment this call out, IDA becomes very fast... as fast as is it in windows. If I add in Y copies of that call, IDA becomes about Y times slower. Looking at the docs on MSDN for WM_MDISETMENU, it says After sending this message, an application must call the DrawMenuBar function to update the menu bar. Which implies that the application is in charge of telling the menu bar to redraw, meaning the call to SetWindowPos() is superfluous. However, SetMenu() is used non by MDI menus as well, which DO expect the menu to be updated automatically (MSDN: The window is redrawn to reflect the menu change), which means it can't just be removed. Does anyone have any suggestions for the cleanest way to resolve this? Perhaps MDI should have an internal copy of SetMenu() tailored to its needs? BTW, under windows, the MDI code does not call the USER32.SetMenu() function.
Problem with latest MDK package.
Hi folks, not sure if this belongs on this list or not, and its probably a stupidly simple question, but its got me stumped. I just installed the latest MDK package for wine (wine-20031118-mdk.i586) to update the one that shipped with MDK 9.2 (wine-20030813-1mdk.i586). Now, when I try and run wine I get wine: error while loading shared libraries: libwine.so.1: cannot open shared object file: No such file or directory libwine.so.1 is in /usr/lib/wine and I've run ldconfig after the package install, but still no joy. Any ideas what's going on here? The install also un-installed several other packages (not sure which ones though, good aren't I??) that I probably need to re-install too. It also removed the menu icons for wine and left XWine not functioning too (guess that's because wine doesn't work though). Thanks heaps. Peter Nunn. -- Think IT for your computing needs. InfoTeq Pty. Ltd.
Re: 64bit Wine?
Marvelous, Thanks for the responce guys. JG on the 02/12/03 16:06, Marcus Meissner wrote: On Tue, Dec 02, 2003 at 08:02:37AM -0600, Jeremy White wrote: I'm considering getting an Opteron. With this being a 64bit CPU I wondered if there would be any issues with using WINE to make use of win32 software on this 64bit CPU. There are no issues. SUSE LINUX 9.0 for AMD64 is capable of running all WINE products, including regular WINE, CrossOver Office, CrossOver Plugin and WineX in the 32bit compat mode. Okay, I read that to mean that you can run already built 32 bit binary versions of Wine. What about compiling? Would compiling Wine on an Opteron work? Hmm. I suppose you could cross compile to 32 bit, couldn't you. Well, I do ;) SUSE 9.0 comes with full biarch toolchain support on AMD64. Before you start, install additionaly to the default packages: glibc-devel-32bit freetype2-devel-32bit XFree86-devel-32bit XFree86-Mesa-devel-32bit fontconfig-devel-32bit openssl-devel-32bit ncurses-devel-32bit alsa-32bit and any dependend rpms. Then: export LD=ld -m elf_i386 CC=gcc -m32 AS=gcc -c -m32 \ ./configure --prefix=/usr --x-libraries=/usr/X11R6/lib make depend all The -m32 switches gcc to 32bit mode. If you have arts-devel installed, you might need to patch dlls/winmm/winearts/Makefile and replace lib64 by lib. You will also need attached winebuild patch that uses LD from the environment. Ciao, Marcus
JournalPlayBack hook
Hello, I'm trying to use the JournalPlayBack hook in a Win32 application and it doesn't work. However it looks to work in 16 bits. Any idea? Thank you ---Juan Antonio Boscá LloretDepartamento Programación CAE, S.A.[EMAIL PROTECTED]---
Re: Installshield7 notes
Gregory M. Turner [EMAIL PROTECTED] wrote in reply to http://marc.theaimsgroup.com/?l=wine-develm=106746370617833w=2 : Could you recommend any particular installer that fails to me (preferably something I can download for free)? I'd be happy to take a look at this, although I can't make any promises as some code-paths (like stubless proxies) are not likely to be fixed anytime soon. The installer for SourceStyler (a c++ beautifier available for free download from http://www.ochresoftware.com/download.html) It fails with the message Installer terminated prematurely., about the time Wine complains fixme:imagehlp:StackWalk (332, 0x, 0xfffe, 0x41b5bb44, 0x41b5c360, (nil), 0x42054e44, 0x42054e9c, (nil)): stub I would try the workarounds listed earlier in this thread, but don't have a native copy of Windows handy. - Dan
Re: wine in the press
Warning: you can skip the comments at OSnews of that article. Really boring mudslinging back and forth. Tom wrote: http://www.osnews.com/story.php?news_id=5262 ill add it to the press page in a couple days ill look around for other articles as well. Tom
Re: new old winetests
Title: Re: new old winetests -- we're linking against ws2_32 Is this DLL available on all versions of Windows we want to run on? As far I know http://msdn.microsoft.com/library/en-us/winsock/winsock/windows_sockets_start_page_2.asp yes. But I am not sure whether it is installed in the base system or only an option if you want to have networking (like on Win3.1). Probably not too many people would run the tests on a standalone machine anyway, but who knows... I actually just ran into this the other night. I installed TaxCut 2003 (which, by the way, mostly works with a few native DLL's) when it didn't like Wine's ws2_32. According to the references built into TaxCut this wasn't part of the original Win95 that shipped. It came out shortly after as an add-on and was likely first included in OSR2. --- Brian Vincent Copper Mountain Telecom [EMAIL PROTECTED]
Re: new old winetests
Brian Vincent (C) [EMAIL PROTECTED] writes: -- we're linking against ws2_32 Is this DLL available on all versions of Windows we want to run on? As far I know http://msdn.microsoft.com/library/en-us/winsock/winsock/windows_sockets_start_page_2.asp yes. According to the references built into TaxCut this wasn't part of the original Win95 that shipped. It came out shortly after as an add-on and was likely first included in OSR2. Damnit. How can we test it? It is possible to split out the Winsock calls into a separate executable, invoke it and check the return value. No rocket science, but I can imagine it work... Feri.
Re: new old winetests
On December 2, 2003 11:10 am, Brian Vincent (C) wrote: It came out shortly after as an add-on and was likely first included in OSR2. Not a big deal, we'd be hard pressed to find a Win95 pre OSR2 system these days anyway. We can live with it. -- Dimi.
