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: 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-patches problem
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! Have a good one, Dave
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.
Re: wine-patches problem
Patrik Stridvall wrote: > > The most important point IMHO is merging with Corel's tree. > Since IIRC Corel Draw for Linux has been released, I should > guess that it will take that long before it will happends. > Anybody from Corel care to comment on it? 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). -- Jeff Tranter Project Leader, Linux Development (Wine team), Corel Corporation The free download of Corel PHOTO-PAINT for Linux is now available. Check it out at http://linux.corel.com/products/pp9 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
RE: wine-patches problem
> >What you said was: > >"Errmm... if you know the API you probably used it for quite a while, > >so you probably had a compiler once, which you (being > typically dishonest) > >warezed, so you can compile the examples for err... home use... or > >something." > > >What I said was: > >1. I _have_ learned Win32 using a legal compiler > >2. Since I know Win32 I might use WineLib for writing simple > > applications. > > I think this is not the norm (just my oppinion, I may be > wrong), Perhaps. In any case it is their problem (and Microsoft's), not mine, nor yours. > I think most > people want to port apps usine Winelib, not generate them. Probably. > Of course only the > people > who use wine for this will reply to my email telling me I'm wrong :-). :-) > There's still a learning curve coming from Win32 since you have to > know what is and isn't supported (no offence intended to the > developers). I'm not talking about writing a large application, I'm talking about a small one week (or a little more) project, that primarily uses GDI and USER functons. Wine implements almost all of them, especially the commonly used ones. > >Whether is would be cost efficient in my example abovr to > buy an extra > >computer with Windows and Microsoft Visual C++ is beside the point. > > I thought your point was about time vs money. Sorry if I > misunderstood. It was. But a programmers salery is the largest cost so any marginal cost like a Windows license or a Microsoft Visual C++ can be mostly ignored, especially since it is a one time cost (excluding upgrades). > >The point is that we shouldn't require people to use Windows > >at all, it is only a lot of extra problems for them. > > If this is a realistic, achievable aim, then sure. In this case I think it is. Just put the DLL:s at WineHQ with source for people you really want to compile it themselves. > >Sure, but Wine (WineLib) aims to replace Windows so we > >shouldn't require people to have it if it can be at all > >avoided. > > It's still in beta though. It is still in Alpha. There has been no Beta annoncement, nor will there until all pre 1.0 restructuring of the code is finished. The most important point IMHO is merging with Corel's tree. Since IIRC Corel Draw for Linux has been released, I should guess that it will take that long before it will happends. Anybody from Corel care to comment on it? > It's a nice thought, but probably > unrealistic at > this stage of the game. Agreed, but that doesn't rule out fixing the problems that can easily be fixed now, instead of waiting and having to do everything at once later.
RE: wine-patches problem
>> Patrik Stridvall <[EMAIL PROTECTED]> wrote >> >You know there are people (like me) that programs Win32 (MFC) for >> >a living, that uses a company paid Microsoft Visual C++. >> >> >If I started working for another company that didn't use >> >Microsoft Visual C++ and perhaps even didn't use Windows >> >I wouldn't have any legal license so I if a had to >> >write a simple GUI program to run under X Windows it would >> >be entirely possible that I wrote that using Win32 (WineLib) >> >that I know very well, instead of using some X Windows >> >toolkit that I only knew the basics of. >> >> >Time is money you know. >> >> You could use the MFC dlls legally (release versions only), >> but you don't get >> to debug into them and you don't get the project wizard. >> Also, you won't have >> the resource editor (that saves a *lot* of time. If time's >> an issue the >> companies going to buy it for you, windows too. >Sure. But I was talking about the time I had use writing >the application not the cost of any extra software and hardware, >which is likely to be insignification unless the application >is very small. The that was not really what was discussed. >What you said was: >"Errmm... if you know the API you probably used it for quite a while, >so you probably had a compiler once, which you (being typically dishonest) >warezed, so you can compile the examples for err... home use... or >something." >What I said was: >1. I _have_ learned Win32 using a legal compiler >2. Since I know Win32 I might use WineLib for writing simple > applications. I think this is not the norm (just my oppinion, I may be wrong), I think most people want to port apps usine Winelib, not generate them. Of course only the people who use wine for this will reply to my email telling me I'm wrong :-). There's still a learning curve coming from Win32 since you have to know what is and isn't supported (no offence intended to the developers). >Whether is would be cost efficient in my example abovr to buy an extra >computer with Windows and Microsoft Visual C++ is beside the point. I thought your point was about time vs money. Sorry if I misunderstood. >The point is that we shouldn't require people to use Windows >at all, it is only a lot of extra problems for them. If this is a realistic, achievable aim, then sure. >> >> Hands up >> >> people who don't know >> >> someone with >> >> Visual C++ 5.0. >> >> >That is completely beside the point. >> >> >Using a "warezed" compiler is one thing, recommending or >> >requiring somebody to use a "warezed" compiler is quite >> >another thing, especially if done in an offical maner. >> >> Wait a minute! That wasn't what I was recommending, and >> certainly not what the >> wine >> project should recommend, whether officially or not. I'm >> simply pointing out >> that VC is >> fairly prevalent, and a huge number of developers (yes there >> will always be >> exceptions) will have access to it, legally or otherwise. >Sure, but Wine (WineLib) aims to replace Windows so we >shouldn't require people to have it if it can be at all >avoided. It's still in beta though. It's a nice thought, but probably unrealistic at this stage of the game.
RE: wine-patches problem
> Patrik Stridvall <[EMAIL PROTECTED]> wrote > >You know there are people (like me) that programs Win32 (MFC) for > >a living, that uses a company paid Microsoft Visual C++. > > >If I started working for another company that didn't use > >Microsoft Visual C++ and perhaps even didn't use Windows > >I wouldn't have any legal license so I if a had to > >write a simple GUI program to run under X Windows it would > >be entirely possible that I wrote that using Win32 (WineLib) > >that I know very well, instead of using some X Windows > >toolkit that I only knew the basics of. > > >Time is money you know. > > You could use the MFC dlls legally (release versions only), > but you don't get > to debug into them and you don't get the project wizard. > Also, you won't have > the resource editor (that saves a *lot* of time. If time's > an issue the > companies going to buy it for you, windows too. Sure. But I was talking about the time I had use writing the application not the cost of any extra software and hardware, which is likely to be insignification unless the application is very small. The that was not really what was discussed. What you said was: "Errmm... if you know the API you probably used it for quite a while, so you probably had a compiler once, which you (being typically dishonest) warezed, so you can compile the examples for err... home use... or something." What I said was: 1. I _have_ learned Win32 using a legal compiler 2. Since I know Win32 I might use WineLib for writing simple applications. Whether is would be cost efficient in my example abovr to buy an extra computer with Windows and Microsoft Visual C++ is beside the point. The point is that we shouldn't require people to use Windows at all, it is only a lot of extra problems for them. > >> Hands up > >> people who don't know > >> someone with > >> Visual C++ 5.0. > > >That is completely beside the point. > > >Using a "warezed" compiler is one thing, recommending or > >requiring somebody to use a "warezed" compiler is quite > >another thing, especially if done in an offical maner. > > Wait a minute! That wasn't what I was recommending, and > certainly not what the > wine > project should recommend, whether officially or not. I'm > simply pointing out > that VC is > fairly prevalent, and a huge number of developers (yes there > will always be > exceptions) will have access to it, legally or otherwise. Sure, but Wine (WineLib) aims to replace Windows so we shouldn't require people to have it if it can be at all avoided.
Re: wine-patches problem
Patrik Stridvall <[EMAIL PROTECTED]> wrote >You know there are people (like me) that programs Win32 (MFC) for >a living, that uses a company paid Microsoft Visual C++. >If I started working for another company that didn't use >Microsoft Visual C++ and perhaps even didn't use Windows >I wouldn't have any legal license so I if a had to >write a simple GUI program to run under X Windows it would >be entirely possible that I wrote that using Win32 (WineLib) >that I know very well, instead of using some X Windows >toolkit that I only knew the basics of. >Time is money you know. You could use the MFC dlls legally (release versions only), but you don't get to debug into them and you don't get the project wizard. Also, you won't have the resource editor (that saves a *lot* of time. If time's an issue the companies going to buy it for you, windows too. >> Hands up >> people who don't know >> someone with >> Visual C++ 5.0. >That is completely beside the point. >Using a "warezed" compiler is one thing, recommending or >requiring somebody to use a "warezed" compiler is quite >another thing, especially if done in an offical maner. Wait a minute! That wasn't what I was recommending, and certainly not what the wine project should recommend, whether officially or not. I'm simply pointing out that VC is fairly prevalent, and a huge number of developers (yes there will always be exceptions) will have access to it, legally or otherwise. -Simon.
Re: wine-patches problem
Hello again, I *really* appreciate your involvement into Winelib things; Winelib is crucial for getting new and, more importantly, experienced Windows developers. BUT: On Thu, Jul 06, 2000 at 10:43:01AM +0200, Wilbur N. Dale wrote: > As you can see, the dll is critical to the example. I do provide the source > code for the dll so if the reader has a windows compiler, he can compile the > dll. However, I am concerned for the reader who does not have a windows > compiler. I want the reader to see the example work. Sure it is critical, but... > As I have posted previously, I will remove the binary parts and resubmit the > patch. However, I think a solution needs to be found for readers who do not > have access to a windows compiler. Putting this on a web site isn't acceptable as a solution ? This is the (IMHO perfect and only) solution for that. Or maybe one could use several web sites for failure prevention's sake... Sorry, but I still can't see at all why everybody would want to download 2 MB of binary rubbish (sorry ;) and even fill their tiny hard disk with that stuff. I suppose only about 30% (if at all) of all Wine archive users would find this DLL useful... Not that this DLL is completely useless, but it's just useless for too many Wine users. I'm pretty sure Alexandre would think the same of that, given his mostly pretty minimalistic point of view. That shows that we're already really missing him: We're already thinking of what he'd do in such-and-such case ;-) We don't want to just imitate Windows - ultimately we want to be better. And that means e.g. that we should try to avoid any code or file size bloat. Andreas Mohr
Re: wine-patches problem
On Thu, 6 Jul 2000, Wilbur N. Dale wrote: > As I have posted previously, I will remove the binary parts and resubmit the > patch. However, I think a solution needs to be found for readers who do not > have access to a windows compiler. There are several free compilers available for compiling Windows code, including: 1. Cygnus GNU/Win32 (free as in GPL, based on gcc) 2. Borland C++ 5.5 command-line tools (free download (binaries only) from the Borland community pages, if you fill out a questionnaire) 3. Others (I think I've heard about lcc-win32, for example) (Borland seems to claim to be doing the free software community a favor by releasing their Windows compiler (command-line version, at least) for no charge (to encourage development of open-source Windows apps or something?)... well, who knows) And like others have stated, you could put a precompiled binary up on a webpage as a service... just like there aren't any precompiled Wine binaries included in the official .tar.gz, just third-parties offering .rpms and .debs as a service...
Re: wine-patches problem
On Thu, 06 Jul 2000, admiral coeyman wrote: [snip] > My hand is up. My compilers are all legitimate. I got three coppies of > Microsoft Visual C++ from Ollies, a local surplus retailer. > I concurr, though. The source code makes a much better example than the > binary. > -Robert 'Admiral' Coeyman This last statement makes me wonder if everyone understands what I am providing. To simplify things I will discuss only one example. I provide: 1. a windows dll (binary) 2. a C file (ascii) 3. a spec file (ascii) 4. makefiles (acsii) The makefiles compile the C file and the spec file into an executable. When the user runs the executable, the executable loads the dll and calls functions within the dll to draw a picture on the screen. >From this, the reader will find out the mechanics needed to write a spec file and glue code needed to load a dll (you may not have the source to compile the dll). So I am providing the source for them to play with. However, my source is loading a binary file. As you can see, the dll is critical to the example. I do provide the source code for the dll so if the reader has a windows compiler, he can compile the dll. However, I am concerned for the reader who does not have a windows compiler. I want the reader to see the example work. As I have posted previously, I will remove the binary parts and resubmit the patch. However, I think a solution needs to be found for readers who do not have access to a windows compiler. -- 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: wine-patches problem
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. -- 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: wine-patches problem
Simon Harrison, > > Errmm... if you know the API you probably used it for quite a while, so you probably > had a compiler once, which you (being typically dishonest) warezed, so you can >compile the > examples for err... home use... or something. Hands up people who don't know >someone with > Visual C++ 5.0. > My hand is up. My compilers are all legitimate. I got three coppies of Microsoft Visual C++ from Ollies, a local surplus retailer. I concurr, though. The source code makes a much better example than the binary. -Robert 'Admiral' Coeyman -- http://www.corner.net/admiral/ May you live as long as you wish and age but a single day. [Telnet to telnet.corner.net]
RE: wine-patches problem
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
RE: wine-patches problem
> >On Wed, 05 Jul 2000, Simon Harrison wrote: > >> Forgive me for intruding (I'm not a wine developer) but I > thought winelib was > >> mainly for porting from Win32 -> Unix. > >> Why would someone porting from Win32 *not* have access to > Visual Studio? > >> > >> -Simon. > > >WineLib allows you to use the win32 API under Unix/Linux. > You might be > >developing your application for Linux using winelib so you can > >use the API you > >know instead of learning a new one. > > Errmm... if you know the API you probably used it for quite a > while, so you > probably > had a compiler once, which you (being typically dishonest) > warezed, so you can > compile the > examples for err... home use... or something. You know there are people (like me) that programs Win32 (MFC) for a living, that uses a company paid Microsoft Visual C++. If I started working for another company that didn't use Microsoft Visual C++ and perhaps even didn't use Windows I wouldn't have any legal license so I if a had to write a simple GUI program to run under X Windows it would be entirely possible that I wrote that using Win32 (WineLib) that I know very well, instead of using some X Windows toolkit that I only knew the basics of. Time is money you know. > Hands up > people who don't know > someone with > Visual C++ 5.0. That is completely beside the point. Using a "warezed" compiler is one thing, recommending or requiring somebody to use a "warezed" compiler is quite another thing, especially if done in an offical maner.
Re: wine-patches problem
>On Wed, 05 Jul 2000, Simon Harrison wrote: >> Forgive me for intruding (I'm not a wine developer) but I thought winelib was >> mainly for porting from Win32 -> Unix. >> Why would someone porting from Win32 *not* have access to Visual Studio? >> >> -Simon. >WineLib allows you to use the win32 API under Unix/Linux. You might be >developing your application for Linux using winelib so you can >use the API you >know instead of learning a new one. Errmm... if you know the API you probably used it for quite a while, so you probably had a compiler once, which you (being typically dishonest) warezed, so you can compile the examples for err... home use... or something. Hands up people who don't know someone with Visual C++ 5.0. The point is that the binaries shouldn't be in CVS, and if you want to cover Borland and MS then have makefiles for both. I'm not going to do the predictable thing and start ranting about security issues and viruses which (if you look at my domain) would be all too predictable. Ooops too late. >Winelib also allows you to use dll's that >can be purchased to add to the functionality of your application. Just because >you are using the win32 API does not mean you are developing for the windows >platform (although the port from winelib to windows should be easy). -Simon.
Re: wine-patches problem
On Wed, 05 Jul 2000, Simon Harrison wrote: > Forgive me for intruding (I'm not a wine developer) but I thought winelib was > mainly for porting from Win32 -> Unix. > Why would someone porting from Win32 *not* have access to Visual Studio? > > -Simon. WineLib allows you to use the win32 API under Unix/Linux. You might be developing your application for Linux using winelib so you can use the API you know instead of learning a new one. Winelib also allows you to use dll's that can be purchased to add to the functionality of your application. Just because you are using the win32 API does not mean you are developing for the windows platform (although the port from winelib to windows should be easy). -- 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: wine-patches problem
OK, since binary files invoke such negative reactions, I will split the patch. Where do I send the binaries so they can be placed on winehq? -- 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: wine-patches problem
On Wed, Jul 05, 2000 at 01:18:35PM +0200, Juergen Schmied wrote: > > > Forgive me for intruding (I'm not a wine developer) but I thought winelib was > > mainly for porting from Win32 -> Unix. > > Why would someone porting from Win32 *not* have access to Visual Studio? > Just because of using Borland C > > I think it would be good to have such files on a ftp directory on winehq for the ones > interested to have with a binary to play with and not to make the cvs tree even >bigger. Yes, adding binary files with a size of even more than 2 MB is *HORRIBLE* !! To repeat it one more time: not everyone has broadband access at home. And even if everyone had: it still would not be a good idea at all. This kind of stuff belongs to a web site, nowhere else. The Wine .tgz is big enough (too big ?) already... Not even binary files of less than 100k should go there IMHO. We may even want to think of moving some files from the Wine archive to a separate "support" archive. I think that will need to be done within the next year or so. Andreas Mohr
Re: wine-patches problem
> Forgive me for intruding (I'm not a wine developer) but I thought winelib was > mainly for porting from Win32 -> Unix. > Why would someone porting from Win32 *not* have access to Visual Studio? Just because of using Borland C I think it would be good to have such files on a ftp directory on winehq for the ones interested to have with a binary to play with and not to make the cvs tree even bigger. Ciao Juergen --- [EMAIL PROTECTED] ... from sunny Berlin
Re: wine-patches problem
Forgive me for intruding (I'm not a wine developer) but I thought winelib was mainly for porting from Win32 -> Unix. Why would someone porting from Win32 *not* have access to Visual Studio? -Simon.
Re: wine-patches problem
On Wed, 5 Jul 2000, Wilbur N. Dale wrote: > On Tue, 04 Jul 2000, Juergen Schmied wrote: > > > The patch contains example programs including a windows dll and a windows exe. > > > The net result is the tar file is about 2 meg. Is there a limit set someplace > > > on the size of an email sent to wine-patches? > > Hmm, the cvs tree is text-only. Why do you send binarys??? This stuff is better > > located at a web page somewhere... > > I am writing the HOWTO-winelib. As part of this I want to present examples of > > 1. A windows exe using a winelib dll. > 2. A winelib executable using a windows dll. > 3. A winelib executable using a winelib dll. I don't see the need for exe files to be distributed just to tell how it works - isn't it good enough to show the source and tell the user how it works? The user doesn't have to actually *test* it without having a special interest in it (and if the user does have such an interest, the user is perfectly able to compile his/her own examples). > I think most winelib users will expect the HOWTO and the examples to which it > refers to be in the wine tree. But not binaries of it. > CVS can handle binary files (see the info pages and the -kb option). So there > is no technical reason stopping the inclusion of the binary files. Yes, there is. You cannot diff a binary file, which makes creating diffs and applying patches rather impossible (for users that upgrade Wine via patching but don't have access to CVS, for example). And no, adding a .tar.gz along with each release patch is not a solution, it's a hassle for everyone involved. This is why there's no binary data in the Wine tree, everything is generated from text files (even the bitmap data in .rc files). > So I see the following issues: > 1. Are binary files warranted in this particular case? No > 2. Should the binary files be in the wine tree? No > 3. Should binary files only be submitted directly to Alexandre and not to > wine-patches? They should not be submitted at all, it seems.
Re: wine-patches problem
Wilbur N. Dale writes: > On Tue, 04 Jul 2000, Juergen Schmied wrote: > > > The patch contains example programs including a windows dll and a windows exe. > > > The net result is the tar file is about 2 meg. Is there a limit set someplace > > > on the size of an email sent to wine-patches? > > Hmm, the cvs tree is text-only. Why do you send binarys??? This stuff is better > > located at a web page somewhere... > > I am writing the HOWTO-winelib. As part of this I want to present examples of > > 1. A windows exe using a winelib dll. > 2. A winelib executable using a windows dll. > 3. A winelib executable using a winelib dll. > > As I see it, I have two choices: either provide binaries or force the user to > use Visual Studio to generate the windows exe and dll files. I think it is > better to provide the binaries with the examples. The point of the examples is > to show how to glue the pieces together. The user may not have Visual Studio. > I think most winelib users will expect the HOWTO and the examples to which it > refers to be in the wine tree. Cygwin/Mingw/LCC-Win32 can produce windows executables/dlls with free software and both former may be used as crosscompilers e.g. running on Linux and the lcc compiler can be used with Wine (at least the last time I tried). Source and appropriate Makefiles are always preferred and should go into ../programs. That way, people can play with the examples and learn more. Perhaps a pointer to some ftp/http repository for precompiled binaries in the README of the examples would be sufficent. Probably WineHQ could host the binaries. But don't let you get stopped by poeple requesting additional features :-) ... Bye Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: wine-patches problem
On Tue, 04 Jul 2000, Juergen Schmied wrote: > > The patch contains example programs including a windows dll and a windows exe. > > The net result is the tar file is about 2 meg. Is there a limit set someplace > > on the size of an email sent to wine-patches? > Hmm, the cvs tree is text-only. Why do you send binarys??? This stuff is better > located at a web page somewhere... I am writing the HOWTO-winelib. As part of this I want to present examples of 1. A windows exe using a winelib dll. 2. A winelib executable using a windows dll. 3. A winelib executable using a winelib dll. As I see it, I have two choices: either provide binaries or force the user to use Visual Studio to generate the windows exe and dll files. I think it is better to provide the binaries with the examples. The point of the examples is to show how to glue the pieces together. The user may not have Visual Studio. I think most winelib users will expect the HOWTO and the examples to which it refers to be in the wine tree. CVS can handle binary files (see the info pages and the -kb option). So there is no technical reason stopping the inclusion of the binary files. > I see your test-mail in wine-patches but again, please send not such big > patches some 10..100 people will have to download it. > juergen So I see the following issues: 1. Are binary files warranted in this particular case? 2. Should the binary files be in the wine tree? 3. Should binary files only be submitted directly to Alexandre and not to wine-patches? My arguments above suggest yes to questions 1 and 2. I am willing to abide by any consensus on question 3. Being new to wine development, are these questions something for debate here or are they Alexandre's decision? > --- > [EMAIL PROTECTED] > > ... from sunny Berlin > . -- 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: wine-patches problem
> The patch contains example programs including a windows dll and a windows exe. > The net result is the tar file is about 2 meg. Is there a limit set someplace > on the size of an email sent to wine-patches? Hmm, the cvs tree is text-only. Why do you send binarys??? This stuff is better located at a web page somewhere... > I expect this to be my only patch of this size. Don't know about. I see your test-mail in wine-patches but again, please send not such big patches some 10..100 people will have to download it. juergen --- [EMAIL PROTECTED] ... from sunny Berlin
