This list is closed, nobody may subscribe to it.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(371) |
Oct
(167) |
Nov
(412) |
Dec
(208) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(378) |
Feb
(302) |
Mar
(269) |
Apr
(296) |
May
(306) |
Jun
(381) |
Jul
(346) |
Aug
(315) |
Sep
(195) |
Oct
(216) |
Nov
(280) |
Dec
(227) |
2002 |
Jan
(309) |
Feb
(333) |
Mar
(328) |
Apr
(407) |
May
(517) |
Jun
(519) |
Jul
(400) |
Aug
(580) |
Sep
(1273) |
Oct
(984) |
Nov
(683) |
Dec
(538) |
2003 |
Jan
(578) |
Feb
(454) |
Mar
(312) |
Apr
(366) |
May
(505) |
Jun
(431) |
Jul
(415) |
Aug
(374) |
Sep
(470) |
Oct
(578) |
Nov
(372) |
Dec
(309) |
2004 |
Jan
(308) |
Feb
(247) |
Mar
(372) |
Apr
(413) |
May
(333) |
Jun
(323) |
Jul
(269) |
Aug
(239) |
Sep
(469) |
Oct
(383) |
Nov
(400) |
Dec
(332) |
2005 |
Jan
(411) |
Feb
(363) |
Mar
(346) |
Apr
(316) |
May
(275) |
Jun
(248) |
Jul
(396) |
Aug
(396) |
Sep
(279) |
Oct
(340) |
Nov
(319) |
Dec
(218) |
2006 |
Jan
(317) |
Feb
(263) |
Mar
(304) |
Apr
(296) |
May
(209) |
Jun
(349) |
Jul
(246) |
Aug
(198) |
Sep
(174) |
Oct
(138) |
Nov
(201) |
Dec
(270) |
2007 |
Jan
(223) |
Feb
(182) |
Mar
(350) |
Apr
(350) |
May
(259) |
Jun
(221) |
Jul
(299) |
Aug
(465) |
Sep
(356) |
Oct
(265) |
Nov
(417) |
Dec
(225) |
2008 |
Jan
(421) |
Feb
(327) |
Mar
(219) |
Apr
(389) |
May
(375) |
Jun
(262) |
Jul
(215) |
Aug
(289) |
Sep
(257) |
Oct
(383) |
Nov
(237) |
Dec
(209) |
2009 |
Jan
(232) |
Feb
(327) |
Mar
(306) |
Apr
(251) |
May
(146) |
Jun
(247) |
Jul
(302) |
Aug
(252) |
Sep
(263) |
Oct
(376) |
Nov
(270) |
Dec
(244) |
2010 |
Jan
(225) |
Feb
(184) |
Mar
(300) |
Apr
(290) |
May
(275) |
Jun
(535) |
Jul
(192) |
Aug
(237) |
Sep
(304) |
Oct
(142) |
Nov
(384) |
Dec
(186) |
2011 |
Jan
(305) |
Feb
(337) |
Mar
(331) |
Apr
(318) |
May
(306) |
Jun
(299) |
Jul
(205) |
Aug
(271) |
Sep
(232) |
Oct
(179) |
Nov
(252) |
Dec
(216) |
2012 |
Jan
(195) |
Feb
(268) |
Mar
(142) |
Apr
(226) |
May
(203) |
Jun
(132) |
Jul
(211) |
Aug
(429) |
Sep
(289) |
Oct
(291) |
Nov
(182) |
Dec
(188) |
2013 |
Jan
(205) |
Feb
(259) |
Mar
(224) |
Apr
(125) |
May
(295) |
Jun
(181) |
Jul
(209) |
Aug
(167) |
Sep
(330) |
Oct
(212) |
Nov
(95) |
Dec
(114) |
2014 |
Jan
(40) |
Feb
(63) |
Mar
(62) |
Apr
(65) |
May
(82) |
Jun
(105) |
Jul
(56) |
Aug
(175) |
Sep
(79) |
Oct
(49) |
Nov
(51) |
Dec
(47) |
2015 |
Jan
(26) |
Feb
(69) |
Mar
(82) |
Apr
(55) |
May
(35) |
Jun
(57) |
Jul
(54) |
Aug
(56) |
Sep
(25) |
Oct
(21) |
Nov
(8) |
Dec
(27) |
2016 |
Jan
(49) |
Feb
(44) |
Mar
(132) |
Apr
(39) |
May
(39) |
Jun
(49) |
Jul
(70) |
Aug
(43) |
Sep
(69) |
Oct
(79) |
Nov
(65) |
Dec
(32) |
2017 |
Jan
(99) |
Feb
(88) |
Mar
(42) |
Apr
(47) |
May
(56) |
Jun
|
Jul
(79) |
Aug
(9) |
Sep
(29) |
Oct
(4) |
Nov
|
Dec
(12) |
2018 |
Jan
(45) |
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ross S. <ro...@ih...> - 2001-04-03 21:02:29
|
Danny Smith wrote: > > Why can't you just do this: > #include <winsock2.h> > #include <windows.h> Because that breaks on MSVC. > This would work on Mingw Yes. > If MS has headers right, it should work with MS as well. Define "right". This is Windows, a Microsoft product, we're talking about. In this context, I'm afraid I find it difficult to wrap my head around the idea of "right" having any definition other than "compatible with Microsoft". If you want Unix, you know where to find it :-) > Actually, thus should work too: > #include <winsock2.h> > > since winsock2.h (and winsock.h) includes windows.h The MSVC versions don't. It hadn't occurred to me that the Mingw versions might do something like that. Again: It's a question of which you think is more important -- being Correct in some abstract theoretical sense, or being compatible with MSVC. -- Ross Smith <ro...@ih...> The Internet Group, Auckland, New Zealand ======================================================================== "Hungarian notation is the tactical nuclear weapon of source code obfuscation techniques." -- Roedy Green |
From: <rei...@go...> - 2001-04-03 20:56:57
|
On Tue, 03 Apr 2001, G. Bard Ermentrout wrote: > Hi >=20 > I have compiled a program using mingw natively -- call it w1.exe and th= en > compiled the same program using the cross-compiler on a Linux box. Call= it > w2.exe. w1.exe runs fine under "wine" but w2.exe does not run saying > that it needs msvcrt.dll to run. Did I miss some flags in cross-compili= ng?=20 Every windows application will need msvcrt.dll to run. This is something = like the libc.a and other libraries in Linux. I have used objdump to see which dll's need my cross compiler and which d= ll's are needed by a native program build by Mircosoft. There is a difference: The cross build program needs msvcrt.dll. The native program needs MSVCRT.dll. On Windows this doesn't matter, but maybe wine has problems with the lowe= r case version. I couldn't believe it, but it can be possible. You can use: objdump -x w1.exe > w1.dump objdump -x w2.exe > w2.dump diff w1.exe w2.exe | less Then you will see the difference. Have you tried to run w2.exe on Windows? Does it work? Some questions about your cross compiler: Which sources have you used? How did you build your cross compiler? Which runtime version are you using? Which version of binutils? --=20 Ing. Reinhard Jessich mailto: rei...@go... A-1190 Vienna, Goergengasse 2/2/1 phone: +43/1/3692600 http://go.to/jessich mobile: +43/664/1735439 |
From: <dan...@ya...> - 2001-04-03 20:11:15
|
--- Ross Smith <ro...@ih...> wrote: > Danny Smith wrote: > > > > Yes, making winsock2.h the default does work, but... it will break code > written > > for mingw which expects winsock.h to be the default. In particular, if > > windows.h includes winsock2.h, and the user thinks that winsock.h is still > the > > default and links against the winsock 1.1. lib (libwsock32.a) rather the > > winsock 2.2 lib (libws2_32.a) there can be problems with setsockopts(). > Having > > said all that, I agree with you that winsock2.h should be the default, and > if > > you really want the 1.1 winsock interface, explicitly include it before > > windows.h. That's just a personal preference. > > Well, it's a question of compatibility. As it stands, code that uses > Winsock 2 can't be made to compile with both Mingw and MSVC without > writing something ludicrous like: > > #ifdef __MINGW32__ > #include <winsock2.h> > #include <windows.h> > #else > #include <windows.h> > #include <winsock2.h> > #endif > > Why can't you just do this: #include <winsock2.h> #include <windows.h> This would work on Mingw If MS has headers right, it should work with MS as well. Actually, thus should work too: #include <winsock2.h> since winsock2.h (and winsock.h) includes windows.h Danny _____________________________________________________________________________ http://my.yahoo.com.au - My Yahoo! - Have news, stocks, weather, sports and more in one place. |
From: Jeff S. <js...@de...> - 2001-04-03 19:32:57
|
On Tue, 3 Apr 2001, G. Bard Ermentrout wrote: > I have compiled a program using mingw natively -- call it w1.exe and then > compiled the same program using the cross-compiler on a Linux box. Call it > w2.exe. w1.exe runs fine under "wine" but w2.exe does not run saying > that it needs msvcrt.dll to run. Did I miss some flags in cross-compiling? 1) Are the native compiler and cross compiler built from identical source? 2) Are they configured with the same options? My first guess is that the native compiler is linking to crtdll.dll while the cross compiler uses msvcrt.dll. You can see for yourself by running "objdump w1.exe | grep DLL" for each executable. What do you want to fix? Are you trying to get identical behavior from the two compilers, or just get w2.exe to run on Wine? Copying msvcrt.dll to your wine installation might be the simplest thing to do. -- Jeff Sturm jef...@co... |
From: G. B. E. <ba...@ma...> - 2001-04-03 18:51:42
|
Hi I have compiled a program using mingw natively -- call it w1.exe and then compiled the same program using the cross-compiler on a Linux box. Call it w2.exe. w1.exe runs fine under "wine" but w2.exe does not run saying that it needs msvcrt.dll to run. Did I miss some flags in cross-compiling? Thanks Bard Ermentrout |
From: Fabrice I. <Fab...@li...> - 2001-04-03 13:10:38
|
Fabrice ILPONSE wrote: > > Butt, Vaughn A. wrote: > >> >> I had this problem a while back. The way I solved it was as follows. >> (Thanks to Jeff Sturm for pointing me to the (old) FAQ. The FAQ also >> has >> some other methods of accomplishing what you want) >> >> Download and extract pexports-041.zip >> >> C:\TEMP>pexports foo.dll >foo.def >> where foo.dll is the DLL that you want to use. >> >> C:\TEMP>dlltool --def foo.def --dllname foo.dll --output-lib libfoo.a >> >> C:\TEMP>make > > > Well, i made it using version 0.4.3 of pexports. All went ok to > create the .a. > I used the fmod library as example. So now i've got the fmod.h, > fmod.dll and libfmod.a > However when i try the compile and link the simplest example : > gcc -mconsole -O2 main.cpp -o main.exe -L. -lfmod > > it finds undifined reference to the functions. I've checked the > names in fmod.def, they seem to be the same... > > Can u tell me where the mistake is? > > thx PRECISION: in the def the description are like: _FSOUND_SetPanSeperation@4 DATA ; no section ; RVA 0001ab3e _FSOUND_SetPaused@8 DATA ; no section ; RVA 0001bbea _FSOUND_SetPriority@8 DATA ; no section ; RVA 0001bc76 _FSOUND_SetReserved@8 DATA ; no section ; RVA 0001bce7 _FSOUND_SetSFXMasterVolume@4 DATA ; no section ; RVA 0001aabd _FSOUND_SetSurround@8 DATA ; no section ; RVA 0001bad9 _FSOUND_SetVolume@8 DATA ; no section ; RVA 0001b818 _FSOUND_SetVolumeAbsolute@8 DATA ; no section ; RVA 0001b8eb _FSOUND_StartSound@12 DATA ; no section ; RVA 0001b2bb _FSOUND_StartSoundDSP@16 DATA ; no section ; RVA 0001b1aa _FSOUND_StopAllChannels@0 DATA ; no section ; RVA 0001b54b _FSOUND_StopSound@4 DATA ; no section ; RVA 0001b4cd does DATA and "no section" mistakes? > > >> >> >> with a make file as follows >> >> mine.exe : mine.o >> gcc -mconsole -o mine.exe mine.o -LC:/temp -lfoo >> >> mine.o : mine.c makefile foo.h >> gcc -c -o mine.o mine.c >> <<<< >> >> >> > |
From: Earnie B. <ear...@ya...> - 2001-04-03 12:03:42
|
Jim Roy wrote: > > Earnie wrote: > > > Danny Smith wrote: > > > > > > I believe that stdin, stdoout, stderr are open in text mode by default, > > > regardless of _fmode. > > > > There is an explicit warning in my VC5 reference manual that stdin, > > stdout and stderr are affected by this. > > What/where is your VC5 reference manual? > It's a Microsoft Press, Vol 3 of the Programmer's Reference Set and it is in my desk drawer. I will admit that I was incorrect and miss read the words `except for stdin, stdout and stderr' on page 43-44. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Fabrice I. <Fab...@li...> - 2001-04-03 10:02:05
|
From: Lorenzo <co...@in...> - 2001-04-03 10:02:03
|
Hi, How can I create ODBC data source via code (win api); p.s. Excuse me, if the question is not about mingw, but because in this mailing list there are many experts, i hope someone can give me a tip. Regards Lorenzo |
From: Ross S. <ro...@ih...> - 2001-04-03 09:18:37
|
Danny Smith wrote: > > Yes, making winsock2.h the default does work, but... it will break code written > for mingw which expects winsock.h to be the default. In particular, if > windows.h includes winsock2.h, and the user thinks that winsock.h is still the > default and links against the winsock 1.1. lib (libwsock32.a) rather the > winsock 2.2 lib (libws2_32.a) there can be problems with setsockopts(). Having > said all that, I agree with you that winsock2.h should be the default, and if > you really want the 1.1 winsock interface, explicitly include it before > windows.h. That's just a personal preference. Well, it's a question of compatibility. As it stands, code that uses Winsock 2 can't be made to compile with both Mingw and MSVC without writing something ludicrous like: #ifdef __MINGW32__ #include <winsock2.h> #include <windows.h> #else #include <windows.h> #include <winsock2.h> #endif It's all very well to decide that making WS1 the default would help backwards compatibility, but Microsoft have decided that WS2 is the default if _WIN32_WINNT is defined and >=0x400, so you'll have to decide whether compatibility with MSVC is still a goal. -- Ross Smith <ro...@ih...> The Internet Group, Auckland, New Zealand ======================================================================== "Hungarian notation is the tactical nuclear weapon of source code obfuscation techniques." -- Roedy Green |
From: Fulvio E. <fu...@li...> - 2001-04-03 08:03:51
|
hello, I have some problem building and installing libstdc++-v3. Could someone help me? I have no experience with command line tools and so i'd like someone to tell me each step i have to take. Thank you. Fulvio Esposito |
From: <dan...@ya...> - 2001-04-03 07:27:05
|
--- Ross Smith <ro...@ih...> wrote: > Paul Sokolovsky wrote: > Finally, there's a problem with Mingw's Winsock headers. After quite a > bit of trial and error, I eventually found out that Mingw requires > winsock2.h to be included _before_ windows.h -- which doesn't work with > MSVC. This means a bunch of gratuitous #ifdefs in code that needs to be > portable. > > A look in Mingw's windows.h found this (lines 136-138): > > #if defined(Win32_Winsock) || !(defined(__INSIDE_CYGWIN__) || > defined(__CYGWIN__) || defined(__CYGWIN32__) || defined(_UWIN)) > #include <winsock.h> > #endif > > Comparison with the corresponding bits of Microsoft's windows.h suggests > that the #include <winsock.h> line should be replaced with: > > #if _WIN32_WINNT >= 0x0400 > #include <winsock2.h> > #else > #include <winsock.h> > #endif > > (I haven't tested this yet.) > Yes, making winsock2.h the default does work, but... it will break code written for mingw which expects winsock.h to be the default. In particular, if windows.h includes winsock2.h, and the user thinks that winsock.h is still the default and links against the winsock 1.1. lib (libwsock32.a) rather the winsock 2.2 lib (libws2_32.a) there can be problems with setsockopts(). Having said all that, I agree with you that winsock2.h should be the default, and if you really want the 1.1 winsock interface, explicitly include it before windows.h. That's just a personal preference. Danny _____________________________________________________________________________ http://my.yahoo.com.au - My Yahoo! - Have news, stocks, weather, sports and more in one place. |
From: Ross S. <ro...@ih...> - 2001-04-03 05:41:37
|
Paul Sokolovsky wrote: > > I don't remember your describing of the problems you face, either. > I don't recommend having wrappers around make, etc - that's way too > complicated. Just have /mingw/bin in front of your PATH always (when > you want to use mingw, of course). A wrapper around make is the easiest way to accomplish that, as far as I can see. What's complicated about it? How else would you do it? > With that, it should work > automagically without any further steps. If not (hm), take a look at > "gcc -v" output, then at "gcc -v <your_app>.c" output. It should show > clearly what's wrong. If it won't, submit those outputs along with > dump of your environment via bugtracker at > http://sourceforge.net/projects/mingw/ . I finally got it all working. The problems I was having with includes and linking came down to three causes: (Or four. My biggest mistake was listening to Paul Garceau. After a few rounds of email with him, with me getting increasingly confused, I finally came to my senses and realised he was talking complete bollocks, and went back to figuring it out for myself.) First, I had my library paths set up so my Cygwin libraries (my own libraries compiled with Cygwin, I mean, not the ones that come with Cygwin) were being found before the Mingw-compiled versions, so of course anything that used them wouldn't link. That was easy to fix by giving them different names. Second, the include files that come with Mingw weren't all being found because all the changes to the Mingw directory structure over the last few weeks had left me with some files in the wrong places and some misconfigured include paths. After I downloaded all the latest packages and reinstalled from scratch, this went away. Finally, there's a problem with Mingw's Winsock headers. After quite a bit of trial and error, I eventually found out that Mingw requires winsock2.h to be included _before_ windows.h -- which doesn't work with MSVC. This means a bunch of gratuitous #ifdefs in code that needs to be portable. A look in Mingw's windows.h found this (lines 136-138): #if defined(Win32_Winsock) || !(defined(__INSIDE_CYGWIN__) || defined(__CYGWIN__) || defined(__CYGWIN32__) || defined(_UWIN)) #include <winsock.h> #endif Comparison with the corresponding bits of Microsoft's windows.h suggests that the #include <winsock.h> line should be replaced with: #if _WIN32_WINNT >= 0x0400 #include <winsock2.h> #else #include <winsock.h> #endif (I haven't tested this yet.) -- Ross Smith <ro...@ih...> The Internet Group, Auckland, New Zealand ======================================================================== "Hungarian notation is the tactical nuclear weapon of source code obfuscation techniques." -- Roedy Green |
From: <dan...@ya...> - 2001-04-02 23:02:42
|
--- Earnie Boyd <ear...@ya...> wrote: > Danny Smith wrote: > > > > --- Jim Roy <ji...@ng...> wrote: > Earnie wrote: > > > > > > > > You can have the following code in a separate source/object and add the > > > > object to the link step or just add the code to the main() source file. > > > > Note: this also affects stdin, stdout and stderr. > > > > > > > > > I believe that stdin, stdoout, stderr are open in text mode by default, > > regardless of _fmode. > > There is an explicit warning in my VC5 reference manual that stdin, > stdout and stderr are affected by this. > > Earnie. > > On my system, they aren't. The moral: Don't believe everything the Marquis de Soft says. Do believe everything the Marquis de Soft does. Danny _____________________________________________________________________________ http://my.yahoo.com.au - My Yahoo! - Have news, stocks, weather, sports and more in one place. |
From: <rei...@go...> - 2001-04-02 22:13:33
|
On Mon, 02 Apr 2001, Christopher Burian wrote: >=20 > The former compiles an fopen of type "w" as binary mode, but=20 > the latter compiles type "w" as text mode.=20 Please read the "EOF problems" thread on this list. Regards, Reinhard --=20 Ing. Reinhard Jessich mailto: rei...@go... A-1190 Vienna, Goergengasse 2/2/1 phone: +43/1/3692600 http://go.to/jessich mobile: +43/664/1735439 |
From: <dan...@ya...> - 2001-04-02 21:31:29
|
--- Fabrice ILPONSE <Fab...@li...> wrote: > Hi again, > > I've got 2 new questions... > I think the first one had already been answered but i don't know > which keyword to use to search the mailling list archives... > > > How do i use a DLL when i only got the .DLL and the .H? > I think there's a tool to generate the appropriate .lib or .a to > link with but i don't know which one... :( > Try Paul Sokolovsky's version of pexports-0.4.3 from http://www.is.lg.ua/~paul/devel/binutils.html The other way is to convert the function declarations in the header file into stub functions definitions, compile, and run dlltool on the resulting object file. Danny > > Is there a WEB site maintaining, converted libs/DLLs of any kind for > mingwin32? > > > Bye > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > http://lists.sourceforge.net/lists/listinfo/mingw-users _____________________________________________________________________________ http://my.yahoo.com.au - My Yahoo! - Have news, stocks, weather, sports and more in one place. |
From: Butt, V. A. <vau...@nz...> - 2001-04-02 21:17:37
|
> -----Original Message----- > From: Fabrice ILPONSE [mailto:Fab...@li...] > Sent: Monday, 2 April 2001 8:35 > To: ming > Subject: [Mingw-users] When u got only an external DLL(built with vc++ > for example), what to do? > > > Hi again, > > I've got 2 new questions... > I think the first one had already been answered but i don't know > which keyword to use to search the mailling list archives... > > > How do i use a DLL when i only got the .DLL and the .H? > I think there's a tool to generate the appropriate > .lib or .a to > link with but i don't know which one... :( > > > Is there a WEB site maintaining, converted libs/DLLs of > any kind for > mingwin32? > > > Bye > I had this problem a while back. The way I solved it was as follows. (Thanks to Jeff Sturm for pointing me to the (old) FAQ. The FAQ also has some other methods of accomplishing what you want) Download and extract pexports-041.zip C:\TEMP>pexports foo.dll >foo.def where foo.dll is the DLL that you want to use. C:\TEMP>dlltool --def foo.def --dllname foo.dll --output-lib libfoo.a C:\TEMP>make with a make file as follows >>>> mine.exe : mine.o gcc -mconsole -o mine.exe mine.o -LC:/temp -lfoo mine.o : mine.c makefile foo.h gcc -c -o mine.o mine.c <<<< |
From: <cb...@ll...> - 2001-04-02 20:17:21
|
Hi, Jeff Sturm writes: > No, there is nothing "non-ANSI" about DOS/Windows text mode. Unless you > open a file with "b" text mode is what you get. That's what ANSI/ISO > says. That's not what the fopen man page says: ] The character b has no effect, but is allowed for ISO C ] standard conformance. > > It took me a couple hours (yeah, duh) to figure out to > > substitute "wb" for "w" when a program that behaved correctly > > on a sparc behaved badly on a peecee. > > Use "wb" everywhere and it will work. (Isn't this a FAQ somewhere?) Could be. The man page ought to tell people what the b means in "wb." It was only after I consulted an antique manual for M$ QuickC that I discovered there were unique "text" and "binary" modes, and that there was a non-ANSI "wt." It wasn't until your email that I discovered that "w" defaults to text mode on Solaris as well as on M$. Personally, I don't think it was a bug in my program, I think it was a bug in the documentation on my workstation for fopen. Nothing to do with mingw in any case, sorry for taking everyone's time. And mea culpa re the nonsense subject line. Thanks for the info. Chris |
From: Earnie B. <ear...@ya...> - 2001-04-02 19:02:23
|
Michael Scheibler wrote: > > I need cygwin's bash in order to work properly. I was using mingw in a > separate directory and was resetting my PATH environment variable for > it. > But now I heard that it would be just enough to run cygwin's gcc with > -mno-cygwin to actually have mingw. > I tried it and found out that libmsvcrt.a is not automatically linked > with my binaries. You need to upgrade to a newer version of Cygwin GCC. You should have version gcc-2.95.2-9 or better. > When I compared the two specs-files I saw that in mingw-specs there is a > libmsvcrt.a mentioned while in cygwin's it is not. Is this a bug in > cygwin's distribution? > Cygwin's GCC until recently used libcrtdll.a instead of libmsvcrt.a. I have successfully caused the switch to libmsvcrt.a but only for newer Cygwin releases of GCC. > Now it is all ok, if I manually add msvcrt to my linked libs list. But > there are three different versions in both cygwin/mingw and original > mingw: > libmsvcrt.a, libmsvcrt20.a and libmsvcrt40.a. > Which one is "right" or which one is "best"? > libmsvcrt.a is what should be used. The other two are identical, IIRC. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Jeff S. <js...@de...> - 2001-04-02 17:58:58
|
On Mon, 2 Apr 2001, Christopher Burian wrote: > The former compiles an fopen of type "w" as binary mode, but > the latter compiles type "w" as text mode. Both the Solaris and MS runtimes interpret fopen(..., "w") as a text-mode open. It just so happens that text mode is indistinguishable from binary on Solaris. > Is this a trick to sneak in DOS's non-ANSI "text mode" for those > who might need it without using the illegal "wt" type? No, there is nothing "non-ANSI" about DOS/Windows text mode. Unless you open a file with "b" text mode is what you get. That's what ANSI/ISO says. > Or is it just a bug? It is a bug in your program. > It took me a couple hours (yeah, duh) to figure out to > substitute "wb" for "w" when a program that behaved correctly > on a sparc behaved badly on a peecee. Use "wb" everywhere and it will work. (Isn't this a FAQ somewhere?) -- Jeff Sturm jef...@co... |
From: Christopher B. <cb...@ll...> - 2001-04-02 17:27:09
|
Using ]Reading specs from ]/usr/local/encap/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs ]gcc version 2.95.2 19991024 (release) and ]Reading specs from ]C:\PROGRAMS\DEVTOOLS\MINGW\BIN\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\specs ]gcc version 2.95.2 19991024 (release) The former compiles an fopen of type "w" as binary mode, but the latter compiles type "w" as text mode. Is this a trick to sneak in DOS's non-ANSI "text mode" for those who might need it without using the illegal "wt" type? Or is it just a bug? It took me a couple hours (yeah, duh) to figure out to substitute "wb" for "w" when a program that behaved correctly on a sparc behaved badly on a peecee. Also, is there a "man" package available somewhere on the web? Thanks, Chris Burian |
From: Earnie B. <ear...@ya...> - 2001-04-02 17:18:50
|
Bernard Elsair wrote: > > Hi group ! > > I try to use getlogin() function, declared in sys/unistd.h, with mingw > and while I have success with cygwin, link step fails when I use gcc > -mno-cygwin !!! > > Do I have to link with a special flag or a particular library ? > Is getlogin an ANSI function? Is it supported by the MSVCRT runtime from Microsoft? Since this is a UNIX standard function then MO is that no it isn't ANSI and no it isn't supported by the MSVCRT runtime. If you want UNIX/POSIX functions then you have to use the library that provides them or code it yourself. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: <ji...@ng...> - 2001-04-02 15:49:16
|
Earnie wrote: > Danny Smith wrote: > > > > I believe that stdin, stdoout, stderr are open in text mode by default, > > regardless of _fmode. > > There is an explicit warning in my VC5 reference manual that stdin, > stdout and stderr are affected by this. What/where is your VC5 reference manual? Jim Roy |
From: Earnie B. <ear...@ya...> - 2001-04-02 12:36:32
|
Danny Smith wrote: > > --- Jim Roy <ji...@ng...> wrote: > Earnie wrote: > > > > > > You can have the following code in a separate source/object and add the > > > object to the link step or just add the code to the main() source file. > > > Note: this also affects stdin, stdout and stderr. > > > > > > I believe that stdin, stdoout, stderr are open in text mode by default, > regardless of _fmode. There is an explicit warning in my VC5 reference manual that stdin, stdout and stderr are affected by this. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Earnie B. <ear...@ya...> - 2001-04-02 12:34:54
|
Jim Roy wrote: > > Earnie wrote: > > > > You can have the following code in a separate source/object and add the > > object to the link step or just add the code to the main() source file. > > Note: this also affects stdin, stdout and stderr. > > > > #include <stdlib.h> > > _fmode = _O_BINARY; > > > > This was just what I was looking for, but I can't get it to work. > It just seems to have no effect at all. > Also, _fmode and _O_Binary seem to be in fcntl.h, not stdlib.h > Oh, yes, I forgot that. > ---- test code ---- > > #include <stdlib.h> > #include <fcntl.h> > > int main(int argc, char **argv ) > { > char input[40]; > _fmode = _O_BINARY; ^^^^^^^^^^^^^^^^^^^ This needs to be in the global space before main. > > scanf ( "%s", input ); > printf( "%s\n",input); > > > } > > -------------- built as follows: > > gcc -o jello.exe -mno-cygwin jello.c > > ---- executed on NT > > jello < in > out > > --- in > > nga{jim}253: od -c in > 0000000 a a a a a a 032 b b b b b b \n > > nga{jim}254: od -c out > 0000000 a a a a a a \r \n > > As you can see, the windoz EOF isn't getting thru the scanf, > and printf is adding \r. > What am I missing here? > Try the following. I haven't tested this particular code but I've done it before. #include <stdlib.h> #include <fcntl.h> _fmode = _O_BINARY; int main(int argc, char **argv ) { char input[40]; scanf ( "%s", input ); printf( "%s\n",input); } YMMV, Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |