From: Wu Y. <ad...@ne...> - 2002-05-27 03:14:52
|
Do you think it is needed to completely eliminate the dependency of MSVCRT.DLL? We have two choices: 1) Make something that wraps MSVCRT.DLL when necessary so that all calls will be standards-conformant; 2) Make something that depends only on system DLLs like KERNEL32.DLL. Either way (esp. for the second), we also need to decide whether we want a DLL or a static library or both. What are you thinking? WARNING: Microsoft still has the best locale and international support as I know (integration with Windows). Ignoring this will be dangerous for international users. But I think the idea of a new run-time worth serious consideration. Maybe we could also incorporate something like non-GPLed POSIX support? Best regards, Wu Yongwei |
From: Wu Y. <ad...@ne...> - 2002-05-27 06:01:19
|
In principle we can do anything Microsoft did. In fact ... Don't underestimate the difficulties. I do not see any open-source implementation as decent as M$ when dealing with Chinese characters. The simple fact is that Microsoft has thousands of developers and supports about thirty languages. Do we want to labour to support all those, or ignore the non-English speaking people? Another fact is that there are still nearly 20 per cent of English-speaking people using Netscape, while in China there are only 2 per cent (mostly Linux gurus). Microsoft is apparently a winner on international support. I know no Chinese company caring for Netscape support when designing Internet/Intranet applications. Just want to emphasize something that you guys in the West might not clearly know. And I hate the idea that if I need Chinese support I need to do it myself. I like MinGW and don't mind contributing something when I have time (I have a normal job on software development). But there are things I am not fluent with and I do not think doing things others have done is a good idea just because something is not "free" (open source). Hey, we are not using an open-source OS, are we? Best regards, Wu Yongwei --- Original Message from Luke Dunstan --- I think that a new runtime independent of MSVCRT.DLL would be useful because there would be full control over how it behaves, and it would help with debugging because a special debug version could be used (like MSVC uses the non-redistributable debug version of MSVCRT.DLL). There is no reason in principle why this new library could not have international support equivalent to MSVCRT, and the "mingwacr" page lists this as a goal. However, I also think that it would be _much_ quicker to base this library on existing C runtimes like newlib. It may also be worth looking at the ReactOS project because they have an initial version of a replacement for MSVCRT (and CRTDLL I think), and sharing "mingwacr" with them would help both projects. Luke Dunstan |
From: Wu Y. <ad...@ne...> - 2002-05-27 07:29:43
|
You replied to Mingw-dvlpr, but I "suppose" you meant the users list. So continue here. I know no programs developed with Mingw that supports Chinese. But that only shows MSVC is still prevalent on this market. I don't want the new runtime will make people choose. I would like to have the benefit of both runtimes: better standard support and MSVCRT compatibility; when possible. I just do not see why you hope people will use MSVCRT less. But maybe I should not stress too much on the difficulty. I just checked the directory "C:\Program Files\Microsoft Visual Studio\VC98\CRT\SRC" and found 793 files totalling 3,718,297 bytes. Take it to estimate the work to be done. Best regards, Wu Yongwei --- Original Message from Luke Dunstan --- I understand your point, and I wouldn't expect it to be easy to replicate all of the multilingual support in the MS runtime. Just out of interest, how many programs do you know of that are developed using Mingw and support Chinese characters? Anyway, an alternate C runtime would be unlikely to replace the current runtime, it would just be an alternative, but if it provides significant extra functionality then I suppose people might use MSVCRT less. Another question: how well does newlib and other GNU software support Chinese/Japanese/etc? Luke |
From: Luke D. <cod...@ho...> - 2002-05-27 04:18:59
|
I think that a new runtime independent of MSVCRT.DLL would be useful because there would be full control over how it behaves, and it would help with debugging because a special debug version could be used (like MSVC uses the non-redistributable debug version of MSVCRT.DLL). There is no reason in principle why this new library could not have international support equivalent to MSVCRT, and the "mingwacr" page lists this as a goal. However, I also think that it would be _much_ quicker to base this library on existing C runtimes like newlib. It may also be worth looking at the ReactOS project because they have an initial version of a replacement for MSVCRT (and CRTDLL I think), and sharing "mingwacr" with them would help both projects. Luke Dunstan ----- Original Message ----- From: "Wu Yongwei" <ad...@ne...> To: "MinGW-Users" <min...@li...> Sent: Monday, May 27, 2002 11:14 AM Subject: Re: [Mingw-users] Mingw32 Alternate C Runtime Library > Do you think it is needed to completely eliminate the dependency of > MSVCRT.DLL? > > We have two choices: > > 1) Make something that wraps MSVCRT.DLL when necessary so that all calls > will be standards-conformant; > > 2) Make something that depends only on system DLLs like KERNEL32.DLL. > > Either way (esp. for the second), we also need to decide whether we want a > DLL or a static library or both. What are you thinking? > > WARNING: Microsoft still has the best locale and international support as I > know (integration with Windows). Ignoring this will be dangerous for > international users. > > But I think the idea of a new run-time worth serious consideration. Maybe we > could also incorporate something like non-GPLed POSIX support? > > Best regards, > > Wu Yongwei > > |
From: Earnie B. <ear...@ya...> - 2002-05-27 13:25:08
|
I had thoughts of ReactOS as well; but, isn't it's license GPL or LGPL? It was a requirement that L/GPL not be an existing license. Earnie. --- Luke Dunstan <cod...@ho...> wrote: > > I think that a new runtime independent of MSVCRT.DLL would be useful because > there would be full control over how it behaves, and it would help with > debugging because a special debug version could be used (like MSVC uses the > non-redistributable debug version of MSVCRT.DLL). There is no reason in > principle why this new library could not have international support > equivalent to MSVCRT, and the "mingwacr" page lists this as a goal. However, > I also think that it would be _much_ quicker to base this library on > existing C runtimes like newlib. It may also be worth looking at the ReactOS > project because they have an initial version of a replacement for MSVCRT > (and CRTDLL I think), and sharing "mingwacr" with them would help both > projects. > > Luke Dunstan > > ----- Original Message ----- > From: "Wu Yongwei" <ad...@ne...> > To: "MinGW-Users" <min...@li...> > Sent: Monday, May 27, 2002 11:14 AM > Subject: Re: [Mingw-users] Mingw32 Alternate C Runtime Library > > > > Do you think it is needed to completely eliminate the dependency of > > MSVCRT.DLL? > > > > We have two choices: > > > > 1) Make something that wraps MSVCRT.DLL when necessary so that all calls > > will be standards-conformant; > > > > 2) Make something that depends only on system DLLs like KERNEL32.DLL. > > > > Either way (esp. for the second), we also need to decide whether we want a > > DLL or a static library or both. What are you thinking? > > > > WARNING: Microsoft still has the best locale and international support as > I > > know (integration with Windows). Ignoring this will be dangerous for > > international users. > > > > But I think the idea of a new run-time worth serious consideration. Maybe > we > > could also incorporate something like non-GPLed POSIX support? > > > > Best regards, > > > > Wu Yongwei > > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: F. <j_r...@ya...> - 2002-05-27 14:15:00
|
WINE has an implementation of MSVCRT.DLL (http://cvs.winehq.com/cvsweb/wine/dlls/msvcrt/). Although WINE changed recentely its license from X11 to LGPL, the X11 fork (http://rewind.sourceforge.net/) has been maintained by the folks at TransGaming - check http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rewind/rewind/dlls/msvcrt/ . Anyway, I don't understand what's the problem with LGPL anyway - it allows static/dinamic linking with proprietary code. I'm not seeing why would someone pick a open-source implementation of MSVCRT.DLL, change it and release in binary form... Note that the ReactOS and WINE projects have been joining efforts to reuse Win32 API code ( http://www.winehq.org/news/?view=122#MinGW%20and%20ftruncate() ). WINE is even being ported to Mingw, not only for ReactOS, but to make tests to the Win32 library in window boxes ( http://www.winehq.org/news/?view=123#Cross-compiling%20Wine , http://www.winehq.org/news/?view=120#Header%20Files%20and%20Testing ) . Starting a new C RT library and ignoring all this just doesn't make sense to me... Well, just my 2c. José Fonseca On 2002.05.27 14:25 Earnie Boyd wrote: > I had thoughts of ReactOS as well; but, isn't it's license GPL or LGPL? > It was > a requirement that L/GPL not be an existing license. > > Earnie. > > --- Luke Dunstan <cod...@ho...> wrote: > > > > I think that a new runtime independent of MSVCRT.DLL would be useful > because > > there would be full control over how it behaves, and it would help with > > debugging because a special debug version could be used (like MSVC uses > the > > non-redistributable debug version of MSVCRT.DLL). There is no reason in > > principle why this new library could not have international support > > equivalent to MSVCRT, and the "mingwacr" page lists this as a goal. > However, > > I also think that it would be _much_ quicker to base this library on > > existing C runtimes like newlib. It may also be worth looking at the > ReactOS > > project because they have an initial version of a replacement for > MSVCRT > > (and CRTDLL I think), and sharing "mingwacr" with them would help both > > projects. > > > > Luke Dunstan > > > > ----- Original Message ----- > > From: "Wu Yongwei" <ad...@ne...> > > To: "MinGW-Users" <min...@li...> > > Sent: Monday, May 27, 2002 11:14 AM > > Subject: Re: [Mingw-users] Mingw32 Alternate C Runtime Library > > > > > > > Do you think it is needed to completely eliminate the dependency of > > > MSVCRT.DLL? > > > > > > We have two choices: > > > > > > 1) Make something that wraps MSVCRT.DLL when necessary so that all > calls > > > will be standards-conformant; > > > > > > 2) Make something that depends only on system DLLs like KERNEL32.DLL. > > > > > > Either way (esp. for the second), we also need to decide whether we > want a > > > DLL or a static library or both. What are you thinking? > > > > > > WARNING: Microsoft still has the best locale and international > support as > > I > > > know (integration with Windows). Ignoring this will be dangerous for > > > international users. > > > > > > But I think the idea of a new run-time worth serious consideration. > Maybe > > we > > > could also incorporate something like non-GPLed POSIX support? > > > > > > Best regards, > > > > > > Wu Yongwei > > > > > > > > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > MinGW-users mailing list > > Min...@li... > > > > You may change your MinGW Account Options or unsubscribe at: > > https://lists.sourceforge.net/lists/listinfo/mingw-users > > > ===== > Earnie Boyd > mailto:ear...@ya... > > --- <http://earniesystems.safeshopper.com> --- > --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- > --- Minimalist GNU for Windows <http://www.mingw.org/> --- > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Bob W. <bo...@ph...> - 2002-05-27 05:56:58
|
> Do you think it is needed to completely eliminate the dependency of > MSVCRT.DLL? > > We have two choices: > > 1) Make something that wraps MSVCRT.DLL when necessary so that all calls > will be standards-conformant; > > 2) Make something that depends only on system DLLs like KERNEL32.DLL. My two cents follows: It really all depends on the aim of the "group." If the aim is to remain totally clear of the "Evil Empire," then option two is the only choice. If the aim is to make sure everything you create will remain compatible with whatever Bill Gates and crew decide to do with their operating system, option one is the answer, but that implies that whatever effort is required will be expended to ensure that whatever is created remains current and Microsoft compatible. Or . . . Everyone bows to the reality that Microsoft will continue to dominate the market and that the non-Microsoft tools that are developed make a bold iconoclastic statement of independence. Regards, Bob |
From: Matthew M. <ma...@ma...> - 2002-05-27 14:53:53
|
On Mon, May 27, 2002 at 12:56:27AM -0500, Bob Wilson wrote: > It really all depends on the aim of the "group." If the aim is to remain > totally clear of the "Evil Empire," then option two is the only choice. If But what's the point then? Why not just run gcc on Linux? I mean, once you're running on MS Win at all, isn't it already too late to "remain totally clear"? -- Matthew Miller ma...@ma... <http://www.mattdm.org/> Boston University Linux ------> <http://linux.bu.edu/> |
From: Chan K. H. <ka...@so...> - 2002-05-28 15:19:39
|
greetings. hmm.. seem to get the feeling that mingw might end up trying to be another unixish emulation layer for windows. hope it doesn't. introducing a runtime that every mingw program *has* to link to however, tends to bend mingw that way. it'd then be not too far different from others like cygwin for instance. i suppose as mingw continues to grow, some changes must take place and certain sacrifices to its minimalist nature have to be made. hope the tools are flexible enough and will provide users with the ability to make that decision as desired. for example, it would be nice if users can choose between several runtime libs made available (eg: users can choose msvcrt.dll or crtdll.dll or newlib or whatever runtime). or the user could have his/her app statically link the runtime in. personally, just hoping mingw doesn't get bulky and continue to stick to its minimalist nature. if mingw starts detracting from its minimalist nature too much, i suppose i might as well just stick to cygwin since it's doing a very good job at wrapping up microsofts dlls and providing more complete functions of its own. just my 2 cents. rgds, kh |
From: Earnie B. <ear...@ya...> - 2002-05-28 16:08:43
|
Chan Kar Heng wrote: > > greetings. > > hmm.. > > seem to get the feeling that mingw might end up trying to be another > unixish emulation layer for windows. hope it doesn't. > Nope, this thread is concerning alternatives. It is a separate project. Opinions where being asked. > > personally, just hoping mingw doesn't get bulky and continue to stick > to its minimalist nature. > if mingw starts detracting from its minimalist nature too much, > i suppose i might as well just stick to cygwin since it's doing a very good > job at wrapping up microsofts dlls and providing more complete functions > of its own. > I would agree. That's why MSYS itself is minimalist. Earnie. |
From: Chan K. H. <ka...@so...> - 2002-05-31 03:22:26
|
greets. :) >> seem to get the feeling that mingw might end up trying to be another >> unixish emulation layer for windows. hope it doesn't. >> > >Nope, this thread is concerning alternatives. It is a separate >project. Opinions where being asked. ahh.. maybe i wasn't paying attention.. :) good to know this. hoorah mingw! :P rgds, kh |