Re: Wine Weekly News #50 (2000 Week 27)
Eric Pouech wrote: Ove Kåven turned out to be the most interested in David's proposal and proposed also to share on going work he had made on re-enabling the DOS support in Wine (which has been disabled temporary by address space separation). David appreciated the help and asked to be able to get a look at the patch before it goes into CVS. Some other people asked how this evolution shall take place (since it may remove lots of 16 bit and DOS code out of the core/monolithic part of Wine, this must be handled with care). David proposed a step by step mechanism: Speaking of which Ove, how is the DOS restructure coming along anyway?? -Dave
Re: wine-patches problem
David Elliott writes: Jeff Tranter wrote: Yes, CorelDRAW and PHOTO-PAINT are now released. It's not our only task, but we will be working on a merge of our code with WineHQ. We're starting to plan it now and expect to start in a week or two (a lot of people are on vacation right now). And a well-deserved vacation IMHO! This vacation would also coincide with the vacation ( and conference tour) of Alexandre. Don't expect changes applied to the Wine-CVS tree for some time... Bye Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Wine Weekly News #50 (2000 Week 27)
On Fri, 7 Jul 2000, David Elliott wrote: Speaking of which Ove, how is the DOS restructure coming along anyway?? I'm not working on it, and haven't been for quite some time, not after I got it back into sort-of working state. It's just that my time is limited and extracting diffs of all the little things I did is tedious work... but I could make a major cvs diff and post the whole lot without bothering to split the megapatch into pieces (which I've suggested before, but with no unambiguous response on where to send it). Perhaps I'll try this weekend?
Re: Wine Weekly News #50 (2000 Week 27)
Ove Kaaven wrote: On Fri, 7 Jul 2000, David Elliott wrote: Speaking of which Ove, how is the DOS restructure coming along anyway?? I'm not working on it, and haven't been for quite some time, not after I got it back into sort-of working state. It's just that my time is limited and extracting diffs of all the little things I did is tedious work... but I could make a major cvs diff and post the whole lot without bothering to split the megapatch into pieces (which I've suggested before, but with no unambiguous response on where to send it). Perhaps I'll try this weekend? Hey dude.. no problem. I think almost everyone here doesn't exaclty have loads of time to screw with Wine (including myself). I tell you what though, if you just wanna cvs diff your stuff and send it over as one huge thing, I'd still like to see it, and I might throw some of my own stuff in there and then split it up and do small patches (the tedious work that no one really wants to ever do, but it always has to be done). The work I want to do is slightly hindered by the fact that DOS doesn't work at all right now. I did at least get basic working versions of a few functions (the memory related stuff) done. You can either send it to my normal e-mail, [EMAIL PROTECTED], or [EMAIL PROTECTED], it all goes into my mail queue just the same. -Dave "It's 4:20, do you know where YOUR kids are at?"
RE: wine-patches problem
On Fri, 07 Jul 2000, Francois Gouget wrote: [snip] Lots of stuff about files sizes. Even if the binaries are provided on a web/ftp site someone will have to download them and 2MB seems like a lot. For one Dll and an executable I would expect something like 30-50KB at most. How come they're so big? Can we trim them down? * you didn't include the debug information, right? (I have to ask because it's so big) * is it compiled in release mode? * is it the size optimization turned on? * not linking statically with anything * for the program we can also use a trick to remove most of overhead imposed by the default WinMainCRTStartup function (using this trick I decreased the size of an antorun program from 23KB to just 2560 bytes) Give the man a cigar (or is a bottle of wine more appropriate on this list?) for asking the right questions. While trying to answer them I found I had included more binary files than I should have. The 2 Meg file size I originally gave is incorrect. The (correct) uncompressed files sizes in bytes are 1. 1360036 in ascii files. 2. 360228 in *.[ch] files (these files also included in 1 above). 3. 12800 in winemain.exe (my windows executable) 412288 in winedll.dll (my windows dll) The difference in the file sizes in 1 and 2 are the scripts used by configure and libtool. Both 3 and 4 are Debug builds, so it is possible to reduce them more. Nothing is statically linked. If none of the above helps then maybe we should try to find ways to modify the example to make it smaller while remaining meaningful: * not using/not linking with the MFC (I don't know if you do) * not calling any C library function (especially if linked statically) * a text only example? But I'm not sure we would save that much. The example is a replacement for EdrTest in Petzold and is of about the same complexity. There is no MFC (I have started on that yet). There are a couple of functions in the dll and a couple of functions in the exe and it draws a window. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux. -- Wilbur Dale Lumin Software BV Zandheuvel 52 B 4901 HW Oosterhout (NB) The Netherlands phone: +31-(0)162-47.88.42 fax: +31-(0)162-43.31.52
Re: typelib
Juergen Schmied wrote: What I would suggest is a merge between your new implementation and Rein Klases' original code. The code could go like this... I removed this code because when starting hh.exe it finds something what is not a typelib and crashes. We would need a more safe way here... See also the documentation for load typelib: - first it is tried if the file is a stand-alone typelib - if that fails, then if it is a executable load the typelib from resource - if that fails parse the file into a moniker. Sounds good let's impement like this. Should I go for if? MapFile if(Signature = MSFT) ReadTypelib(BaseAdress) Unmap else if(Signature = MZ) LoadLibrary() GetResource() ReadTypelib(ResourceAdress) else FIXME: case3 juergen That sounds good to me!
Re: typelib
Rein Klazes wrote: On Thu, 6 Jul 2000 20:31:13 +0200, you wrote: Sounds good let's impement like this. Should I go for if? If I understand correctly, Francois Jacques has been assigned to fix this and others issues with regard to ole automation. True. But if Juergen feels like implementing it, I don't see any problem! This way I could concentrate my efforts on a few other issues. Cheers, Francois
Re: ASPI under Wine --- can't see devices
Well, one obvious thing would be you do have permissions for the device, right? I doubt it could be that simple though. I kind of figured this was going to happen sometime, as I still havent' been able to get Adaptec Easy CD Creator working either. Like your program, I think it may not like the output from SC_HA_INQUIRY. Fortunately, that means I have a program exhibiting similar behavior so I at least have a decent test case. I'll start debugging this problem this weekend and see if I can come up with a solution. For one thing, last time I checked, the DLLs LibMain was not being called correctly by Wine (I think this is a known problem in Wine). Although for right now the only side effect of that is that I can't free up everything when the DLL is unloaded because I don't even know when the DLL is unloaded (and half the time it somehow manages to unload the DLL more times than loading it). There are only 4 functions for WNASPI32. GetASPI32SupportInfo, SendASPI32Command, GetASPI32DLLVersion, and an ordinal only export 7. I have no idea what ordinal 7 is supposed to do, but maybe it has something to do with these problems. The GetASPI32DLLVersion always returns 1 (which should be according to spec, and I think is also what the real WNASPI32.DLL returns). The GetASPI32SupportInfo Function returns 1 controller present and SS_COMP which is not really correct, but should be fine for your situation. All that's left really is SendASPI32Command which has several cases, each of which either prints a TRACE or FIXME. I'll try adding some traces to the GetASPI32DLLVersion and GetASPI32SupportInfo functions and see what I come up with. Also, one major problem is that the way WNASPI32 is implemented, all commands complete before returning, which is not supposed to happen, but it seems to work for most stuff. Anyway, those are just some ideas I am throwing out if you would like to pursue the problem a little further. Have a good day, -Dave P.S. Thanks for the good debug info. (which I snipped in this reply)
Re: PE loader issue
as I tested the Windows (98) behaior, here are the results:
LOAD_LIBRARY_AS_DATAFILE will not really go through the PE-loader. It
just maps the entire file somewhere into memory. It doesn't even take a
look at the file-alignment (afaik), but simply does mmap(file,
somewhere, filesize).
no ref count is used. calling twie LoadLibraryEx with
LOAD_LIBRARY_AS_DATAFILE yields two different handles. Another interesting
point: handles gotten from LOAD_LIBRARY_AS_DATAFILE are odd numbers (regular
flags give an even number, which is the base address (documented as a non
portable feature). Windows shall use the lower bit of the handle to know
which type of mapping has been used. A handle gotten from
LOAD_LIBRARY_AS_DATAFILE yields to an error when trying to get the name
with GetModuleFileName
OTOH, DONT_RESOLVE_DLL_REFS does everything
the normal PE-loader does, except PE-linking (doesn't resolve imports).
Loading as datafile is a bit problematic with builtin dlls, as we do not
have properly delimited sections that can be mapped as data (would
require quite a bit of ELF hacking).
A not-resolved-dll can be integrated into the dependency list of dlls if
it is loaded once again with LoadLibrary and the proper flags (without
it's load-address changing). However, I do not know what windows does in
this case.
a non resolved DLL (loaded with DONT_RESOLVE_DLL_REFS) can be resolved
with calling LoadLibraryEx("dllname", 0, 0);
the virtual region mapped with the different flags are :
- LOAD_LIBRARY_AS_DATAFILE: size of the file (didn't check the alignment of
sections), but whole file gets mapped
- DONT_RESOLVE_DLL_REFS, 0: a single page is mapped at base address (which
means the DLL is mapped section by section)
as a conclusion, I think we can safely base Wine's design on :
- LOAD_LIBRARY_AS_DATAFILE doesn't insert the mapped file into the dependency
list, but simply mapped into memory (which means cases for odd handles passed
to some resource functions shall be added)
- non resolved DLLs can become resolved when reloaded with the proper flags
however, implementing the first item can be costly (it means accessing
the data resources from a DLL directly mapped into memory), so I'd rather suggest
to still insert the datafile DLLs into the dependency list and properly handle
the DATAFILE case
comments are welcome
--
---
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
Adding a memory zone
Hi all, I wanted to try again to make Thief working in Wine. If anyone remembers, the developpers are using the EGA screen memory to display some debug informations : Wine crashes accessing the address 0xB. Last time I tried Thief, I added a FILE_dommap at this address to prevent the crash just after the DLL initialization in miscemu/main.c But now, with ASS, where should I put this call that should be done for each process ? -- Lionel Ulmer - [EMAIL PROTECTED] My Advogato Wine diary : http://www.advogato.org/person/bbrox/
Re: Wine jobs
On Wed, 5 Jul 2000, Jeremy White wrote: Or, if you're interested in hiring, feel free to drop me a line. I'll try to put you in touch with people who might be appropriate. Doug, would it be possible to formalize this process on winehq, perhaps with a mailing list or an official place for such requests? A couple of people have suggested this. However, employment ads are particularly volatile pieces of information, and they are useless if stale, so you have to make sure that they are up to date. The big jobs sites do this, along with providing good search capabilities. Given the current size of the industry, it's probably fine for job ads to just get posted to wine-devel. If the noise gets too high, that will have to change, but this isn't a danger just yet. doug. [EMAIL PROTECTED]
RE: wine-patches problem
On Thu, 6 Jul 2000, Wilbur N. Dale wrote: On Wed, 05 Jul 2000, Christopher Morgan wrote: How big would the binaries for the programs be? I heard some mention of 2MB binaries, which is an expected size for a windows application, nothing out of the ordinary these days, but would that be 10-15 2MB files? Adding 10MB to the cvs tree probably wouldn't be all that bad considering the initial download would be the only time people would notice, but I suppose the question is exactly how much would be added to the tree if the binaries were included. Chris Morgan The compressed tar file was 2 Meg. The tar file contained all of my source and the binaries for one dll and for one exe program. I know this has already been discussed a lot but I would like to look at it from a different perspective. I would not be absolutely opposed to putting a binary file in the Wine source (that's for Alexandre Julliard to decide anyway) but what 'shocks' me is that the tar.gz file is 2MB big. Is there additional files not in the current patch that you plan to add? Just for reference the tar.gz of the latest Wine sources (Wine-2614.tar.gz) is just under 5MB (4986KB). So including your patch would represent close to a 40% increase! Even if the binaries are provided on a web/ftp site someone will have to download them and 2MB seems like a lot. For one Dll and an executable I would expect something like 30-50KB at most. How come they're so big? Can we trim them down? * you didn't include the debug information, right? (I have to ask because it's so big) * is it compiled in release mode? * is it the size optimization turned on? * not linking statically with anything * for the program we can also use a trick to remove most of overhead imposed by the default WinMainCRTStartup function (using this trick I decreased the size of an antorun program from 23KB to just 2560 bytes) If none of the above helps then maybe we should try to find ways to modify the example to make it smaller while remaining meaningful: * not using/not linking with the MFC (I don't know if you do) * not calling any C library function (especially if linked statically) * a text only example? But I'm not sure we would save that much. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
