Unicode C runtime lib in VS2008

Hi gents!
I have a generic question.
I'm using Visual Studio 2008 and its VC++ compiler to develop C language applications. I've always looked for using the C Run time Library for code portability reasons. Since I needed to implement into an imposed UNICODE environment I had to migrate all ANSI statements to win32 library. So the code portability blows-up ...
Now the question: is there any way I can go back to the "pure C" but in UNICODE mode without getting tight to Win32, while alsays using the VC++ compiler?
Thanks for your hints.

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.

Thanks! "Fairly well" isn't enough to bring my C code into Win Mobile 6 which uses in native mode a subset of win32.

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.

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!

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.

Quote:

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

Quote:

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.

@Mats: I use the same engine whatever is the host: server or PDA. When you say

Quote:

anything that Visual Studio can do, the gcc compiler should be able to do

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?

No, VS includes nothing from GCC.

Quote:

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

Mats, I like this :

Quote:

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.

. I'll dig into since this would be great! For the rest (msvcrt.dll/strlen is not unicode btw ...) I may not have been clear in my initial post. But, amazing, while the others came to the issue, you pop-up a very interesting opening! Thanks.

Quote:

Originally Posted by Opariti

Mats, I like this : . I'll dig into since this would be great! For the rest (msvcrt.dll/strlen is not unicode btw ...) I may not have been clear in my initial post. But, amazing, while the others came to the issue, you pop-up a very interesting opening! Thanks.

Sure. strlen is not unicode, nor is strcpy, strcat, etc. You need to use wcslen, and wcscpy, wcwcat, etc, etc.

--
Mats

Quote:

Originally Posted by matsp

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

Sorry to bring up this thread again.

Here's a warning I got:

Code:

warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

I tried:

Code:

#define _CRT_SECURE_NO_WARNINGS

but that didn't work.

I used the online(vc++ 2008) help, and it says to "simply define _CRT_SECURE_NO_WARNINGS", with no instructions of how to go about it.

I did some research on the internet, and it appears I need to edit property sheets, but the VC++ 2008 Express instructions for property sheets don't match what I see on the screen(and don't match the options that are available). Perhaps it is for another version of VC++.

#define has to happen before #include.

Quote:

Originally Posted by tabstop

#define has to happen before #include.

Yep, that did the trick. Thanks. :)

You may also want to consider using the more secure functions, as well.
True, not as portable, but they are safer. Well, that can be debatable, but at least they help find bugs.
Mostly, simple wrappers can be built for these functions for compilers that do not support these.