#223 ___lc_codepage_func not available on Windows 2000 and XP SP0

closed-fixed
nobody
crt (85)
5
2015-04-16
2011-05-12
No

Hi,

I'm forwarding this from http://bugs.debian.org/626437.

Executables produced by recent mingw fail on start on win2k and XP sp0
with a message "___lc_codepage_func in DLL msvcrt.dll" .

This regression is introduced in SVN revision 2285:

Author: jon_y
Date: Sun May 2 10:32:30 2010 +0000

use ___lc_codepage_func instead of __lc_codepage to get codepage.

diff --git a/mingw-w64-crt/misc/mb_wc_common.h b/mingw-w64-crt/misc/mb_wc_common.h
index af633b8..50794ea 100644
--- a/mingw-w64-crt/misc/mb_wc_common.h
+++ b/mingw-w64-crt/misc/mb_wc_common.h
@@ -4,11 +4,11 @@
* No warranty is given; refer to the file DISCLAIMER.PD within this package.
*/

-#undef __lc_codepage
-__declspec(dllimport) extern unsigned int __lc_codepage;
+#include <_mingw.h>
+_CRTIMP unsigned int ___lc_codepage_func(void);

static inline
unsigned int get_codepage (void)
{
- return __lc_codepage;
+ return ___lc_codepage_func();
}

The reporter of the Debian bug suggests reverting this patch or using Win32 locale functions instead of __lc_codepage() or ___lc_codepage_func(). I'm guessing using ___lc_codepage_func() only on Windows XP SP1 and later (or whatever version it appeared in, or only on appropriate versions of MSVCRT.DLL) would fix it too...

Regards,

Stephen

Discussion

  • Ozkan Sezer

    Ozkan Sezer - 2011-07-31

    Bug #3382873 (https://sourceforge.net/tracker/index.php?func=detail&aid=3382873&group_id=202880&atid=983354) is marked as a duplicate of this.

     
  • Jim Michaels

    Jim Michaels - 2011-08-24

    I would like to know when this is fixed. I have quite a number of projects (35) which are dependent opon windows 9x functionality, and this is a blocker. thanks.

     
  • Jonathan Yong

    Jonathan Yong - 2011-08-24

    I think the original issue was somebody trying to link with MSVC (or libmsvcrXX.a) code and __lc_codepage was missing. I can't remember all the details.

     
  • Ozkan Sezer

    Ozkan Sezer - 2011-08-25
    • status: open --> closed-fixed
     
  • Ozkan Sezer

    Ozkan Sezer - 2011-08-25

    This is fixed in the v1.0 branch as of rev. 4360, and in the trunk and v2.0 branch as of rev. 4353. Closing as fixed.

     
  • Jim Michaels

    Jim Michaels - 2011-08-27

    http://msdn.microsoft.com/en-us/library/dd373763%28VS.85%29.aspx

    you mean this?

    according to msdn 2000 I have (sometimes better than web version), windows 9x does not support SetThreadLocale().

    so is mingw-w64 a windows NT-family only compiler? or is there another way around this for 9x compilation? people who use my apps want 9x/me.

    the VC++ MAKELCID macro and MAKELANGID on the other hand, DOES work on 9x/me.
    The following are ActiveX. Sometimes it's the only way to get things done. there are things done with ActiveX that are not done with C++ or win32. If you need an overview of ActiveX, read "Understanding ActiveX and OLE" by Microsoft Press. Microsoft used to give developer's classes on writing ActiveX/OLE controls, and you would learn a LOT but the class is expensive. piece of cake to write a GUIDGen tool. but doing ATL on mingw-w64? I don't know. no MIDL compiler!

    IMultiLanguage::GetCodePageInfo Method
    IMultiLanguage2::GetCodePageInfo Method
    IMultiLanguage2::GetCodePageDescription Method
    IActiveIMMIME::GetCodePageA Method
    IActiveIMMApp::GetCodePageA Method
    IActiveIME::GetCodePageA Method

     
  • Ozkan Sezer

    Ozkan Sezer - 2011-08-27

    > according to msdn 2000 I have (sometimes better than web version),
    > windows 9x does not support SetThreadLocale(). [...]

    I don't understand what is being asked here but the issue has been fixed already in all branches. As to w9x support, it is not guaranteed AFAIK, but others would know better.

     
  • Jim Michaels

    Jim Michaels - 2011-08-28

    sorry, I was a too late in answering. thank you for the fix. much appreciated. win9x support where possible would be excellent. at some point win9x should go away, but people are still using it for ginourmous printers and such and they can't switch to a new OS. (and windows vista and up can fuzz the quality of images and audio and video if HW is not right)

     
  • Jim Michaels

    Jim Michaels - 2011-11-20

    there is another dependency. I don't know if it's still there, but I just
    ran my df program on windows 98 compiled with auto 32 20110812, and I got
    this:

    Error Starting Program
    The LIBSTDC++-6.DLL is linked to missing export MSVCRT.DLL:_fstat64

     
  • Jonathan Yong

    Jonathan Yong - 2011-11-20

    Windows 98 was never a supported target or host.

     
  • Jim Michaels

    Jim Michaels - 2011-11-20

    I need the windows 98 support.
    there are still windows 98 machines around. so what am I supposed to use to compile programs for them?

     
  • Jim Michaels

    Jim Michaels - 2011-11-20

    actually, I need 32-bit executables that can run on windows 9x, and I need 64-bit executables that run just fine on whatever 64-bit boxen.

     
  • Jonathan Yong

    Jonathan Yong - 2011-11-20

    Use old versions of mingw.org, at least 2-3 years ago to be safe (gcc-3.4.5/gcc-4.2.1 era).

    Later versions already use tls, though it has some fallback for win9x, you can try your luck with them too.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks