Jon Griffiths wrote: > Hi David, > > I was working on crtdll until about 3 weeks ago when i took a months > holiday. I'll be back in a couple of days and intend to start working > on it again, so we should probably discuss some aspects of the > implementation. I submitted a much fixed/extended patch than the one > sent to winehq to Alexandre before I left (the winehq version has > several bugs and shoulnd't be used, it was really put there for > discussion), however he didn't accept it based on the way file > mapping is currently done. I will be changing the patch as it stands > to conform to the style Alexandre suggested it (minor) and > resubmitting it within a week. > The one on winehq.com looked particularly bad in a lot of places to me anyway. I suppose you have a better version that I haven't seen yet. Alexandre and most of the wine developers are really picky about what goes in. Don't feel bad because I have been in the same position, it takes a while to get used to the Wine tree and some of the philosophies. I have had several patches rejected one or two times before getting accepted. Hell, even recently due to a design issue. > i have just been reading the develop mailing list and caught your > comments, i agree with most of the points that were raised during the > discussion and have a few of my own: > > -fairly few functions can be implemented using the native glibc/libc. > any function that uses file or allocates memory must be re-written > (you cant use crt mem functions on crt allocated memory). also > structures should be binary compatable with windows even on big > endian machines. True, but I have one concern. Have you looked at the MS provided MSVCRT source? If you have I would suggest consulting with a lawyer before sending in any patches. As I said before, a broken but mostly working MSVCRT is better than an illegal one. This is one of the FAQs and you really need to be careful about this. However I suppose if you have and you could describe it to me then I could implement it and it would be okay (this is how Compaq cloned IBM's BIOS IIRC). I am more than willing to sign a sworn statement that I have not looked at the code. This is especially important as it's highly likely that I'd implement something almost exactly like MS, and if I looked at the code it would seem as if I just copy and pasted it even though I didn't and that's definitely uncool. I might be overreacting, but better safe than sorry. Also, I do not have a big-endian machine to test, but I generally write good portable code so it should only require minor changes to work if Wine ever actually runs on other archs. Winelib of course works on some other archs, but in that case binary compatibility is somewhat of a non-issue. > > -compatable headers for winelib should be low priority until the > implementation is mostly complete, otherwise we could break existing > winelib users. this can be relaxed where headers arent used under > unix. Absolutely not. Compatible headers are a top priority for me and especially a top priority for those developing with Winelib. I am doing this more for winelib than for wine. > > -msvcrt *is* crtdll, with an extra 565 functions implemented on top, > and made threadsafe. the common functions should be the same code. > crtdll should be made threadsafe, the performance overhead for > programs that use crtdll is minimal, and then the code can be shared. > plus the difference between threadsafe and non threadsafe is only a > line or two in some functions. > Hmm, okay. MS must have had a reason for making MSVCRT rather than just adding the functions to CRTDLL and making some of the existing ones threadsafe. If that is the case then it leads me to believe that some functions will need to be implemented differently. Or maybe MS was just stupid which doesn't surprise me either. However, I do agree that when possible CRTDLL should use the MSVCRT implementation. crtdll.spec will mostly turn into "@ forward function MSVCRT.function" Unless there is a specific reason to implement it differently for CRTDLL. > -I am using several programs that rely on crtdll, and crtdll is > included in win2k (modified 12 July 1999). > Sounds good. I am not saying CRTDLL should not be worked on, I am just saying that MSVCRT is more of a priority as far as winelib is concerned since it would be the one used by a winelib program. I am more concerned about winelib than wine for this particular case, especially because MSVCRT is included if you download IE anyway. > > let me know what you think - if you want me to mail you my latest > patch I can do it when i send it to alexandre for resubmittal. pretty > much all file functions are now implemented along with a whole bunch > of other stuff. I also have a testbed which works for testing lots of > crtdll and mscrtdll functions. I will have a look at your patch when > I get back and get on to my pc as well, and might have some more > comments for you then. > Actually, my idea of the winemsvcrt is totally broken as I realized specfiles don't do what I want them to do. I will be sending an updated system to wine-devel shortly (like in an hour or so maybe). So please don't look at the current stuff because it will probably just confuse you since it confused me. Personally i feel that CRTDLL should use functions implemented by MSVCRT rather than the other way around. For now I am doing MSVCRT as a seperate thing and when MSVCRT goes into the wine tree I will change CRTDLL to forward to MSVCRT for most cases (if not all cases). Obviously I am going to steal code out of CRTDLL when it makes sense to do so, and I will probably steal some of your implementations too rather than reinvent the wheel. By the way, it is nice hearing from you, I was kind of wondering where you went! -Dave
