Pointers problem

[migf1]

That's weird. It compiles and runs fine for me (both on XP 32-bit and 7 64-bit) with v 6.50.

[CommonTater]

Yes.. it is weird...

_tcsncpy is there and it does compile and work...  turns out, its in the tchar.h private header.

But it's not indexed in the help file...

In any case it is clearly labled as "Not Standard C" in which case you cannot expect it to work on any other compiler or run time library... Thus, not portable.

[migf1]

Actually, it does compile & runs fine with both pelles c and mingw32 (the latter means it also works fine with VC++, since they share the same runtime).

PS. Of course it's not a standard C function, it's a win32api specific extension, as is the rest of the context I used it, in the original post.

[CommonTater]

PS. Of course it's not a standard C function, it's a win32api specific extension, as is the rest of the context I used it, in the original post.

Actually not... it's a C++ function that's (apparently) been adopted in to Pelles C... as you point out it works in Mingw since it uses the VC++ runtimes. The actual Windows API documentation does not list it but provides, instead, the functions I linked to.
 
(And now I need an aspirin    )



 

[migf1]

To be precise, it's a Microsoft extension (as are all the TCHAR generic functions, also known as Generic Text Mappings) and that explains why it is also supported in Pelles C

[offtopic]

(And now I need an aspirin    )

:lol:

To be totally honest, programming the Win32 API using C these days is dangerously flirting with... masochism. I admit I'm a bit of a masochist myself, mostly because I love the C language.

But realistically, very few people do it any more... and even more fewer are likely to keep doing it. Most people use .net for such tasks (what a bloatware!), and the rest are using any of the several C++ wrappers available.

Have you ever tried GTK+? Well, it blows the Win32 API away, and it's also a core C GUI framework.

At first it may seem a bit of a pain to set it up for Windows, but it is actually not. Setting up a gcc toolchain to go along with GTK+ may be a bit more challenging, but nothing difficult really.

Anyway, a while back in my effort to refresh my GTK+ skills (after a very long sabbatical ... that translates to 3-4 years :lol:) I wrote a little tic-tac-toe game with GTK+2 on Windows and if my memory serves me well, I was also compiled it with Pelles C (along with mingw32).

I can try to find it and post it, if anyone is interested in having a look at it.

It's a pitty that GTK+3 is not available for Windows though... it is left in v 2.28, while its Posix counterpart is already in v 3.4+ Same thing for Glade

Still, I find it much more fun (and productive) than Win32.

[/offtopic]

[CommonTater]

To be precise, it's a Microsoft extension (as are all the TCHAR generic functions, also known as Generic Text Mappings) and that explains why it is also supported in Pelles C

Ok... what I meant was that it's an extension to C++ ... but the Windows API doesn't mention it. 
In any case, it's not standard Pelles C, C-11 or C-99 so recommending it requires some precaution.

To be totally honest, programming the Win32 API using C these days is dangerously flirting with... masochism. I admit I'm a bit of a masochist myself, mostly because I love the C language.

But realistically, very few people do it any more... and even more fewer are likely to keep doing it. Most people use .net for such tasks (what a bloatware!), and the rest are using any of the several C++ wrappers available.

I'm an electronics tech, trainee and trainer back in the day when you could actually fix stuff... I got really good at it too.  But that's because I'm a "nuts and bolts" sort of person who likes to get right into things at the most basic levels... This of course makes C a natural for me, short of going to pure ASM (which has been contemplated) C is about as close to the metal as I can get... and that suits me just fine.

I have tried C++ with GTK and wsWidgets too.. hated it, just plain hated it...  Now if only I could get my hands on a proper Pascal implementation with x64, unicode and Windows API units...          ... but from what I can find it's not out there.  Free Pascal is as close as it gets and to be honest it's such a dog's breakfast I would need *years* to get it into useable condition.