Thread: Unicode C runtime lib in VS2008

Sure, you can use "wide" mode in C. It may not be 100% UNICODE, but it works fairly well at least.
There are usually a wide and ansi type of each function in the C runtime, and VC++ implements them, so there's no trouble there.

Nothing is perfect, nor is the "wide" implementation of C, which is a form of unicode.
However, wide chars in Windows are interchangeable with native API. Wide versions of the APIs expect Wide strings from C, so they do work.
However, the wide characters are not 100% unicode, because they are 2-byte fixed length strings. If they do not work out well for you, you can always find a unicode implementation on the web.
Such things are possible with pure C, and thus would be portable.

I don't know if they're extensions or not...
The best option would be to try it out with another compiler, I would think. Code::Blocks + mingw should be as as install & compile and see. Although, again, I am unsure if the mingw port actually supports any wide implementation...
Someone else more knowledgeable on this topic will have to provide those answers.

Originally Posted by Opariti

OK for the wchar & co. First I wonder if the associated I/O functions are standard C RTL or they are Microsoft extensions. Second, I didn't try any web downloadable library to put into VS2008 ressources/references so far; would that work, I mean isn't Microsoft making life hard for such add-ins?
Anyway, your established reputation brought me to a point of decision, unless somebody else comes-up with another view. Many thanks!

But if you are writing for Win Mobile, why are you worried about portability?

Elysia: Yes, gcc uses the MS Standard library for most things, so anything that Visual Studio can do, the gcc compiler should be able to do - with a few exceptions of pragmas for linking and such things.

--
Mats

Um, don't know if this question is related to the OP's, but is there an option in M$ VC++ 2008 Express to adhere to ANSI C99?

I am getting alot of warnings from the compiler about fscanf, fopen etc being unsafe, and to use fscanf_s, fopen_s etc, which I think are M$ own implementations.

Thanks.

MS C compiler isn't quite C99 compliant, and there is no switch for specifying that you want MS's version of C99 - you can get C89 standard by specifiying "ansi" somewhere, I'm pretty sure.

Define _CRT_SECURE_NO_DEPRECATE to avoid those "use fscanf_s" instead messages.

--
Mats

Originally Posted by matsp

MS C compiler isn't quite C99 compliant, and there is no switch for specifying that you want MS's version of C99 - you can get C89 standard by specifiying "ansi" somewhere, I'm pretty sure.

Define _CRT_SECURE_NO_DEPRECATE to avoid those "use fscanf_s" instead messages.

--
Mats

If you mean this : http://msdn.microsoft.com/en-us/library/0k0w269d.aspx
I do not see where it is specified what ANSI C version is used when /Za switch is On

Visual C++ does adhere to C90. Only it does not support C99.
The compiler also has some general extensions, which again, can be disabled using the option vart mentioned.
I can only assume that to the demographic MS's compiler is targeted at have no need for C99.

No, VS includes nothing from GCC.

Originally Posted by Opariti

@Mats: I use the same engine whatever is the host: server or PDA. When you say is it about the Win32 APIs? I'd strongly disagree. If it's about C - RTL then that was the issue here, about its (in)ability to handle Unicode. If gcc includes the MS library my question was backwards: does VS include 100% of Unicode set of gcc?

I don't understand which part of my post you are objecting to. gcc-mingw uses MS library code for the C library.

The following is a dumpbin /exports listing from a.exe, which I compiled with gcc:
Dump of file a.exe

Code:

File Type: EXECUTABLE IMAGE

  Section contains the following imports:

    KERNEL32.dll
                4050CC Import Address Table
                405054 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                   1  AddAtomA
                  9C  ExitProcess
                  B0  FindAtomA
                  DD  GetAtomNameA
                 2E3  SetUnhandledExceptionFilter

    msvcrt.dll
                4050E8 Import Address Table
                405070 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                  23  _getch

    msvcrt.dll
                4050F4 Import Address Table
                40507C Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                  27  __getmainargs
                  3C  __p__environ
                  3E  __p__fmode
                  50  __set_app_type
                  6F  _assert
                  79  _cexit
                  E9  _iob
                 15E  _onexit
                 184  _setmode
                 215  abort
                 21C  atexit
                 23F  free
                 272  malloc
                 27A  memset
                 27F  printf
                 290  signal
                 297  strcat
                 29F  strlen

  Summary

        1000 .bss
        1000 .data
        1000 .idata
        1000 .rdata
        1000 .text

As you can see, mvcrt.dll is the runtime library used by gcc - so any C runtime library dependent function will be the same whether you compile the code with gcc or MS compiler. [Although I think gcc may use an older version of the VC library, but if you really want to, I'm sure you can rebuild gcc-mingw to use a later version].

You could, if you really wanted to, port glibc [I'm sure there is a port already] to Windows, and use glibc with gcc too - but that's not what gcc-mingw does.

Of course, another Windows port of gcc may not use the same concept of which library.

--
Mats