Random LOL

In porting an old multi-headed hydra, I found myself cackling.

Somewhere down in the beast's HAL, is an utility function that returns the device name. This is what I found:

if (access("normal device", F_OK) == 0) {

    strcpy(devName, "normal device");

} else if (access("device not used in many years", F_OK) == 0) {

    strcpy("devName", "device not used in many years");

}

And in realizing why the stack trace was in such a simple function, I bust a gut when I noticed the quotes in the lower string copy. Ahh, the joys we inherit ^_^.

Over the years, I’ve screwed with a lot of build systems. Both in the course of my own projects and other people’s, and I’ve come to a conclusion over the past fourteen years.

At best: you can reimplement make poorly. At worst you can reimplment half of autotools, poorly.

That’s pretty much what I’ve seen. Thus as time has gone on, I see it very hard to do better than good old Make. Especially when the GNU version has about five hundred pages worth of voodoo to appease even the worst masterbaters, and the need for autotools is kind of waning IMHO.

Enter ninja.

What I’ve generally found with Ninja is that it’s very simple. Like C: the little bit of syntax you need to remember is a small quantity. Opening a build.ninja file is probably enough to grok what’s going on if you’ve ever used an actual build system that involves editing files.

Likewise answers to questions that tend to make it easier to build a wonky, hellish, broken build monstrosity, tend to be “No, you can’t because that would make this slow”. And let’s face it, if you want much more than a relatively simple Makefile, you’re probably building a case for pain.

Based on the past year, I think ninja will be sitting next to vim and dump in my toolkit of loved and trusty computing companions.

Right, premake4 is one of my favourite ways to build C/C++ stuff but tonight I'm thinking it has a moron involved. You can specify a project as being one of four kinds: ConsoleApp, WindowedApp, SharedLib, StaticLib. The documentation here states that this likely means /SUBSYSTEM:WINDOWS will be passed to link.exe, and indeed it is. That is how you say call WinMain and do any other I'm a GUI app magic for Windows; other wise you get a main and a command  prompt; simply put.

This FAQ entry on the other hand, is just retarded.

I guess like many, this morning I learned that the world recently lost one of it's biggest contributors. I do not mean Steve Jobs, a man with his own important legacy. Dennis MacAlistair Ritchie has died, he was more commonly known as 'DMR' or just 'Dennis Ritchie'. A G+ entry by Rob Pike is the earliest reporting I'm aware of, but I can't say I expect this sad news to be found on TV.

Dennis Ritchie has a place in history that few men have ever achieved, because his work helped change the world. I am a young man compared to the late DMR but I does have an interest in history. If it wasn't for this mans work, I doubt that I could be writing this journal entry, because he helped to enable so many elements that make it possible.

His most famous programming language, C, was so pervasively popular, that I knew of it before I learned to program. My first programming language (C++) was derived from it. A big part of how I fell so deep insane with computers was learning about how C and Unix became self hosting. That  means you could make C and Unix using C and Unix, in laymans terms. Back then that was  almost like revolutionary - today it's like sliced bread. We take it for granted but someone had to help show us the way; then people started to use it everywhere.


Through C, we gained countless programs. Most Unix operating systems are written in C, most other operating systems are written in C or finally grown from one that was. Unix, DOS, Windows, Linux, OSX, your iPod, your iPhone, your iPad, our Android. None of it would exist just like it does. Most of the stuff we do every day involves C programs, be that reading e-mail, playing games, surfing the web. It is even normal for other programming languages to be implemented in C. The defacto standard Perl, Python, and Ruby included. It is so normal that writing a language implementation in itself is not so big anymore. C is so pervasive that it is also inescapable in other languages: their is almost always a way and a need to interface with C code. Hell, today you might even have C code involved in your toaster. It is that important a programming language. If you ever used a computer or an embedded system, you have probably used software written in C, or are old enough to remember what it was like before punch cards.



C is perhaps the single most important language since programmer's stopped writing in raw machine code. In fact, sometime after that we stopped writing in assembly and I know no one who goes lower level than reading the machine code. A common portion of C syntax is practically our linga franca—even if C is not a shared language, the syntax (which grew from prior languages) is also widely used and an alternative to pure pseudo code.

Maybe a lot of young programmers don't know C, or skip it. I love it. It is one of the most beautiful languages that I know, despite it's trappings. Perhaps some of the greatest lessons I learned about my craft, was that learned from C. Perhaps another was the humility of it's creator.



Somehow, I doubt his other works will ever be as well known as C, or things he was a big part of (like Unix), but maybe people will study them and see what they can learn from the work of a legendary hacker, like Dennis Ritchie.

Humorous language comparison

Special thanks to Carpet Smoker of Daemon Forums.

This really did make me laugh out loud

"If I had a nickel for every time I've written "for (i = 0; i < N; i++)" in C I'd be a millionaire."

- Mike Vanier

Even more so because for stuff I've in mind to write, involves noting that inescapable fact of C programming :-o.

In looking closer at things, somehow I think that by cica GCC 5.0, either the GNU compiler will have imploded upon it's own weight :-o, or it will become an impressively powerful compiler, in place of an impressively portable one.

The feature set being grown, may even give old MSVCs optimization setup a good run for it's money someday, only the best tools with Visual C++ cost a few thousand dollars and GNUs is given away for free lol.

Me, I would just settle for a generally portable compiler that generates decent code, and complies with the bloody standards... So far I personally like pcc.

An idiosyncrasy no one else gets

Whenever someone asks me how I am, I often phrase 'and how are you?' as '&you ?', which is something usually lost on everyone. In the C programming language, the ampersand is used as an address-of operator used to create a reference of sorts, and is integer to utilising pointers. So litterally 'address-of you ?' makes a very explicitly reference while remaining a syntactically correct substitution of '&' for 'and', in English anyway.

If anyone finds that odd, just try not to think about how Lisp and Perl have impacted my brain over the years lol.

Ugh, it's been a long and unpleasant day! Never the less, I've almost got the MSVC builds sorted to where I want them. Basically why unix builds are shared libraries and windows builds are static libraries, has to do with the respective linkers.


At least on FreeBSD i386, the (GNU) linker doesn't complain about the common and sys modules referencing one another, you could say it has more of a view that the shared lib is a chunk of code and all is fine as long as it all resolves enough in the end. I generally prefer dynamic linking over static, although I have nothing against static libraries internal to a project; when it comes to Windows  however, I'm particularly found of Microsoft's SxS technology.


While the GNU stuff on my laptop is hapy enough to obey, the link tool provided by MSVC however, won't cooperate with that model of behaviour for shared libs (DLLs), only static libraries. Other then the increasingly becoming stuff that belongs together, the common and sys modules were merged into a single 'core' module, and tonight, prepped to better handle compiler specifics as well. Secondary is that, simply put link makes shared libraries a bit more typing then need be. Every other sane OS/Compiler pair I've encountered, has the lovely habit of assuming that you wrote a function in a library, and might want to share it with other programs. Visual C++ on the other hand,  presents several ways of doing it: that all basically amount to telling the linker which things an application may slurp up from it. Basically resorting to writing a ".def" file, or in wrapping up function definitions with a __declspec(export) attributes, and the correct __declspec(export) or __declspec(import) attributes at their declarations.

Microsoft's way of doing things is more flexible, but one might fairly argue that the inverse behavour (e.g. export anything not specially marked) would have been better.


Generally I like MSVC, I think it's better then GCC, if you are willing to put up with the major lack of C99 compliance and lack of stdint.h (I use one written by Paul Hsieh). The main downside is the tools tend to be a bit, eh, stupider then GNU brew, and the best parts of the system are like wise fairly specific to both MSVC and Windows NT. Personally I would enjoy a professional edition of the MS's offerings, because it would net access to their 64-bit C/C++ compiler and much stronger profiling tools, that are simply missing from the express editions.


The sad part, is that Visual Studio is the only software package I have seen Microsoft release in my entire life that, that's worth buying.... lol. Not even their operating systems can say that much, from where I sit.

Building better memory management for high performance wired/wireless networks: Part 1

Building better memory management for high performance wired/wireless networks: Part 1: "The authors describe a variable pool memory management scheme that has been implemented for LTE and WiMAX protocol stacks and has exhibited excellent performance, especially when compared to traditional fixed-pool implementations.






"

Maybe I'm a freako, but I find these this article set to be intensely interesting.

In my travels, I've read plenty of miles of code, including more then a few programs that go as far as memory pools, and even writing a real memory allocator for all practical intents and purposes. This ranges from programs simpler then most (non UNIX) users would think trivial, all the way to more "Complex" systems. In fact, I've even spent time spelunking kernel virtual memory and file system code, which can be a truly interesting set of experiences in their own right.

In working on Stargella, I've wondered whether or not using such techniques would be a viable method of improving the games performance, but for this point in time, everything relies on the C library to work wonders where dynamic memory is needed. While I can see potential savings from adapting a more elaborate memory management schema, it's rare that I'm kicking something around, that really warrants the extra time for creating and debugging code for it, over just rolling with the local libc brew. Of course being the code monkey I am, I always keep an open mind for what the future may bring in the way of change.

Although I will use malloc() quite freely in coding, I also look at it like a reload in a CQB situation: if you're reloading, you're not able to engage more threats, and that (at least for me in SAS) is often the slowest element to an aggressive and dynamic advance. On the other hand though, I generally expect the operating system to provide a decent memory allocator for most tasks, rather then a brain damaged one \o/. Ways to minimize the cost of allocating memory however, is something that I always consider a plus.

Hmmm :-)

Bug smashing on the stack, hehe

Ok, I've spent some time longer then expected working on my games net code, mostly because I both needed one nights sleep this week, and wanted proper IPv4/IPv6 support going on. Sunday I basically finished principal work on the net module, and completed a pair of test cases: a really simple client and server program. After that went smooth, I had planned to complete the finishing touches.

The problem: the server example segfaulted. Now those who know me, I consider it a plight upon my honour as a programmer, for any code that I've written to crash without due cause (i.e. not my fault). So I spent work on Monday taking a break: refining code quality and then porting it from unix to windows. During the nights final testing runs after that however, I had not solved the mysterious crash yet, and got the same results. I switched over to my laptop and recompiled with debugging symbols, only to find that my program worked as normal, only dying with a segmentation violation once main() had completed, and the programs shutdown now "Beyond" my control.

My first thought of course, was "Fuck, I've probably screwed my stack"^[1], a quick Google suggested I was right. I also noted that turning on GCCs stack protection option prevented the crash, so did manually adding a pointer to about 5 bytes of extra character data to the stack. Everything to me, looked like the the return address from main was being clobbered, or imagine invoking a buggy function that tries to return to somewhere other then where you called it from. Before going to bed, I narrowed it down to the interface for accept(). Further testing showed that omitting the request for data and just claiming the new socket descriptor, caused the crash to end but still, some funky problems with an invalid socket. Inspection of the operation also showed that the changes were well within the buffers boundary, yet it as still causing the crash. So I finished the remaining stuff (i.e. free()ing memory) and went to bed.

Having failed to figure it out this afternoon, and starting to get quite drowsy, I played a trump card and installed Valgrind. It's one of those uber sexy tools you dream of like driving a Ferrari, but don't always find a way to get a hold of lol. For developers in general, I would say that Valgrind is the closet thing to a killer app for Linux developers, as you are ever going to get. In my problem case however, Valgrind wasn't able to reveal the source of the problem, only that the problem was indeed, writing to memory it I shouldn't be screwing with \o/.

So putting down Valgrind and GDB, and turning to my favourite debugging tool: the human mind. It was like someone threw on the lights, once I saw the problem. Man, it's wonderful what a good nights sleep can do!


Many data structures in Stargella are intentionally designed so that they can be allocated on the stack or heap as needed, in order to conserve on unnecessary dynamic memory allocation overhead, in so far as is possible. So the example server/client code, of course allocated its per socket data structures right inside main(). Because there is no real promise of source level compatibility between systems, the networking module is implemented as a header file, having function prototypes and a data structure representing a socket; which contains an opaque pointer to implementation specific details, itself defined in unix.c and windows.c, along with the actual implementations of the network functions. Because of that,the behaviour of accept() can't be emulated. Net_Accept() takes two pointers as parameters, first to a socket that has been through Net_Listen(), and secondly to another socket that will be initialised with the new connection, and Net_Accept() then returns an appropriate boolean value.



All the stuff interesting to the operating systems sockets API, is accessed through that aforementioned  pointer, e.g s->sock->whatever. What was the big all flugging problem? The mock up of Net_Accept(), was originally written to just return the file descriptor from accept(), allowing me to make sure that Net_Listen() actually worked correctly. Then I adjusted it to handle setting up the data of the new socket, in order to test the IPv4/IPv6 indifference and rewrite the client/server examples using Net_Send() and Net_Recv(), and that's when the crashes started.


I forgot to allocate memory for the sub structure before writing to the fields in it, resulting in some nasty results. When I say that I don't mind manual memory management, I forget to mention, that programming while deprived of sleep, is never a good idea, with or without garbage collection ^_^.



Now that the net code is virtually complete, I can hook it into my Raven Shield server admin tool, which will make sure to iron out any missing kinks, before it gets committed to my game. Hehehe.

My games net module is almost complete under unix, and in theory should be able to handle both IPv4 and IPv6 communication fine; not that I have much to test the latter with. Windows support will need a bit more tweaking, and then it'll be possible to plug it into my Raven Shield admin quiet easily.

Pardoning interruptions, I've spent about 6 hours of my day working in straight C, followed by about 15-20 minutes for a little rest. For some sickening reason, my weekends almost always fall into the category of working all day, eating dinner, then working until dawn lol.


Doing things in C, I find more time consuming then more dynamic languages, chiefly because of how much testing I (try to) do, coupled with how much lower-level stuff one has to keep in mind. Having to deal with memory management issues, is not a problem for me, although I do admit that garbage collected languages can be very enjoyable. To be honest, I find the portability problems of doing anything interesting, to be a greater drawback then managing memory; e.g. by design Python is not very portable in comparison to C, but it more then portable enough for anything you're likely to bump into on a PC, and can do 'more' with less bother, for an acceptable level of portability. They are very different languages at heart, and their designs reflect it strongly. A lot of people (including myself) call Cs portability a myth, and it is in the sense of what most people want (especially me), I doubt is possible without a more modern rendition of the language (NOT Java or C++). Where C truly excels at portability, well I reckon you'll just have to study more assembly language to understand the value of it.


Now if only I had something better to do, then spend all my time behind a computer screen, monkeying around with GCC on one side, and MSVC on the other 8=).

A little size of fun.

Generally, I'm rather finicky about making assumptions about the sizes of types, and even conversions between signed and unsigned types. Although I occasionally skirt dangerous gronud, such as feeding a function pointer into a object pointer, and expect to be able to cast the void* back to the function pointer (basically implementation defined by C, but required by POSIX), I also tend to make notes of when (fully aware) I do things that are non portable, but not necessarily obvious. At least in the example case I just mentioned, I didn't know that was dangerous ground until I reviewed code under -pendantic, and scratched my head at the required warning message.

Normally I take things in stride, and just cringe when I see, "Portable" software doing stupid things like using unsigned int where they mean uint32_t, or the (flawed) assumption that a pointer to xyz will be as large as an object of xyz. So I thought I'd just take a look see here, and then wrote a program to display it in bits rather then bytes, since most of the folks I know will better get the picture that way :-o.

Also being a practical man, I kind of like to know what is off the edge of the map, just in case I some day have to jump off \o/.


Here is a simple program to solve my curiosity:

 #include 
#include 
#include 
#include 
int
main(void) {

    printf("sizeof(char)\t= %u-bits\n", sizeof(char)*CHAR_BIT);
    printf("sizeof(char*)\t= %u-bits\n", sizeof(char*)*CHAR_BIT);
    printf("sizeof(wchar_t)\t= %u-bits\n", sizeof(wchar_t)*CHAR_BIT);
    printf("sizeof(wchar_t*)\t= %u-bits\n", sizeof(wchar_t*)*CHAR_BIT);
    printf("sizeof(short int)\t= %u-bits\n", sizeof(short int)*CHAR_BIT);
    printf("sizeof(short int*)\t= %u-bits\n", sizeof(short int*)*CHAR_BIT);
    printf("sizeof(int)\t= %u-bits\n", sizeof(int)*CHAR_BIT);
    printf("sizeof(int*)\t= %u-bits\n", sizeof(int*)*CHAR_BIT);
    printf("sizeof(long)\t= %u-bits\n", sizeof(long)*CHAR_BIT);
    printf("sizeof(long*)\t= %u-bits\n", sizeof(long*)*CHAR_BIT);
    printf("sizeof(long long)\t= %u-bits\n", sizeof(long long)*CHAR_BIT);
    printf("sizeof(long long*)\t= %u-bits\n", sizeof(long long*)*CHAR_BIT);
    printf("sizeof(size_t)\t= %u-bits\n", sizeof(size_t)*CHAR_BIT);
    printf("sizeof(size_t*)\t= %u-bits\n", sizeof(size_t*)*CHAR_BIT);
    printf("sizeof(float)\t= %u-bits\n", sizeof(float)*CHAR_BIT);
    printf("sizeof(float*)\t= %u-bits\n", sizeof(float*)*CHAR_BIT);
    printf("sizeof(double)\t= %u-bits\n", sizeof(double)*CHAR_BIT);
    printf("sizeof(double*)\t= %u-bits\n", sizeof(double*)*CHAR_BIT);
    printf("sizeof(long double)\t= %u-bits\n", sizeof(long double)*CHAR_BIT);
    printf("sizeof(long double*)\t= %u-bits\n", sizeof(long double*)*CHAR_BIT);
    printf("sizeof(ptrdiff_t)\t= %u-bits\n", sizeof(ptrdiff_t)*CHAR_BIT);
    printf("sizeof(ptrdiff_t*)\t= %u-bits\n", sizeof(ptrdiff_t*)*CHAR_BIT);
    printf("sizeof(intptr_t)\t= %u-bits\n", sizeof(intptr_t)*CHAR_BIT);
    printf("sizeof(intptr_t*)\t= %u-bits\n", sizeof(intptr_t*)*CHAR_BIT);

    return 0;
}

The C standard defines CHAR_BIT in limits.h, as being the number of bits  for the smallest object that is not a bit field, roughly meaning that CHAR_BIT = number of bits in a byte, for all practical intents and purposes. Like wise, the sizeof operator is defined as returning the size of its operand in bytes, as an implementation defined unsigned integer value having the type size_t, from stddef.h. For the fuckos out there, the standard also says that a char object is large enough to store any character of the basic execution set (A-Z, a-z, 0-9, space, plus the required punctuation and control characters—roughly a character set of 99 symbols that fit within a single byte), and that those characters will have a non negative value while doing it. It also declares that sizeof(char) == 1. From this we can infer that sizeof(x) * CHAR_BIT should be the size of x in bits, and that 'x' is basically as good as off the edge of the map, for any x that you can't make on my grandmothers type writer.


Having the size of each type followed by a pointer to it displayed, is mostly done to emphasis that a pointer to a size, means dick all about the size of the pointer. You'll notice an interesting connection between pointer size and your hardware however. Gee, that just doesn't sound right, LOL.




Some examples:


Run on FreeBSD 8.0-STABLE i386:

sizeof(char)    = 8-bits
sizeof(char*)   = 32-bits
sizeof(wchar_t) = 32-bits
sizeof(wchar_t*)        = 32-bits
sizeof(short int)       = 16-bits
sizeof(short int*)      = 32-bits
sizeof(int)     = 32-bits
sizeof(int*)    = 32-bits
sizeof(long)    = 32-bits
sizeof(long*)   = 32-bits
sizeof(long long)       = 64-bits
sizeof(long long*)      = 32-bits
sizeof(size_t)  = 32-bits
sizeof(size_t*) = 32-bits
sizeof(float)   = 32-bits
sizeof(float*)  = 32-bits
sizeof(double)  = 64-bits
sizeof(double*) = 32-bits
sizeof(long double)     = 96-bits
sizeof(long double*)    = 32-bits
sizeof(ptrdiff_t)       = 32-bits
sizeof(ptrdiff_t*)      = 32-bits
sizeof(intptr_t)        = 32-bits
sizeof(intptr_t*)       = 32-bits

and FreeBSD 8.0-RELEASE amd64:

sizeof(char)    = 8-bits
sizeof(char*)   = 64-bits
sizeof(wchar_t) = 32-bits
sizeof(wchar_t*)        = 64-bits
sizeof(short int)       = 16-bits
sizeof(short int*)      = 64-bits
sizeof(int)     = 32-bits
sizeof(int*)    = 64-bits
sizeof(long)    = 64-bits
sizeof(long*)   = 64-bits
sizeof(long long)       = 64-bits
sizeof(long long*)      = 64-bits
sizeof(size_t)  = 64-bits
sizeof(size_t*) = 64-bits
sizeof(float)   = 32-bits
sizeof(float*)  = 64-bits
sizeof(double)  = 64-bits
sizeof(double*) = 64-bits
sizeof(long double)     = 128-bits
sizeof(long double*)    = 64-bits
sizeof(ptrdiff_t)       = 64-bits
sizeof(ptrdiff_t*)      = 64-bits
sizeof(intptr_t)        = 64-bits
sizeof(intptr_t*)       = 64-bits

I also have access to 32-bit versions of Windows NT and OpenBSD running on Pentium 4-grade hardware, but don't feel like booting the wintel tonight, I'm to comfortable with Dixie hehe. Perhaps I will run the program on other systems and implementations, for the sake of testing, and add it to this entry as a comment.

Here's my notes from installing JPEG-7 on Windows

Take note: I install libraries into C:\DevFiles\Libraries\What\; with compiler specific files dumped under sub folders, e.g. C:\DevFiles\Libraries\zlib\msvc\zdll.lib and C:\DevFiles\Libraries\zlib\mingw\libzdll.a. Like wise, I leave a README.TXT file in the root, noting anything I will need to remember when it comes to using the library.

# build for Visual C++ 2008 / 9.0
> unzip "path\to\jpegsr7.zip"
# I want it in jpeg\src for safe keeping
> mkdir jpeg
> move jpeg-7 jpeg\src
# use the corresponding .vcX files for version
> copy makeasln.vc9 apps.sln
> copy makejsln.vc9 jpeg.sln
> copy makewvcp.vc9 wrjpgcom.vcproj
> copy maketvcp.vc9 jpegtran.vcproj
> copy makervcp.vc9 rdjpgcom.vcproj
> copy makedvcp.vc9 djpeg.vcproj
> copy makecvcp.vc9 cjpeg.vcproj
> copy makejvcp.vc9 jpeg.vcproj
> copy jconfig.vc jconfig.h
# I'm using vcbuild, since I read .vcproj files in vim; you may want the IDE
> vcbuild /nologo jpeg.sln "Release|Win32"
 ...
> vcbuild /nologo apps.sln "Release|Win32"
# I put compiler specific files in a suitable folder
> mkdir ..\msvc
> copy Release\jpeg.lib ..\msvc
# jconfig.h is compiler specific, so we dump it in our compiler directory
> copy jconfig.h ..\msvc\
> del jconfig.h

# build for MinGW/MSys
$ pushd /C/DevFiles/Libraries/jpeg/ 
$ pushd src
# works for most packages
$ ./configure  --prefix=/C/DevFiles/Libraries/jpeg/ --exec-prefix=/C/DevFiles/L
ibraries/jpeg/mingw/
$ make
$ make install
# move jconfig out of independent include and into compiler specific dir
$ mv ../include/jconfig.h 

Now copy jerror.h, jinclude.h, jmorecfg.h, jpegint.h, and jpeglib.h into ../include/. Those are the portable headers, that won't very based on compiler (MinGW/MSVC).


and here's my notes file:

MinGW -> static link as normal
MinGW -> Use import library libjpeg.dll.a for dynamic linking with libjpeg-7.dll
MinGW -> Last build JPEG-7 on 2009-12-24

MSVC -> Can only static link agaisnt jpeg.lib; must use /MD
MSVC -> also add msvc/ to include path, for jconfig.h
MSVC -> Last build JPEG-7 on 2009-12-23

In all cases, add include + compiler folders to your include path.

Hahaha, here I am wondering ok, what the hell is wrong with

if (statement that will return false)
    DEBUG(...);
    do action;

and then I noticed, uncommenting the DEBUG() macro a few minutes ago changed the dohicky.



This is exactly why whenever I've written a 'style' file for any of the projects I've done (and in fact, usually follow) a note that it should *always* be if () { } and never if () just for this reason!!!


Ok, I'm so freaking stupid... I should just get some sleep and code when I can pay attention (and remember my old tool Perl).

GCC spitting error: stray '\1' in program (etc)

Ok, so I am wondering why the bloody heck I'm getting messages like main.o:x:y: error: stray '\1' in program and related errors * near infinity whilst nitting object files into an executable .

Note to self: never allow your Makefile to say g++ -x c++ foo.o ... -o program !!!!


I don't know what is worse....


(EDIT: actually this reminds me, a friend said it sounded like an encoding error; and in retrospec it looks like GCC was interpreting main.o as a C++ file because of the -x flag lol)

The Simpler Direct-media Library (SDL) has proven more impressive then originally anticipated. I've downloaded the MinGW (GCC) and MSVC (V8.0/2005) development libraries along with the source code: much to my surprise, the Borland and Watcom compilers are also supported. While I'm using GCC for the unix side of things, I fully intend to make use of Microsofts compiler for the windows builds. My desktop system also has the OpenWatcom compilers installed on the Windows partition, never have used them, but they are available (I them installed ages ago, mainly out respect for the old watcom-c compiler). Since I need the DirectX SDK to compile SDL from source on Win32, and it is like a 512 meg download, it'll have to wait a while lol. The binaries available are from MSVC8, so I really woul dprefer compiling SDL from source: not to mention feel more comfortable using the combination for projects, knowing it built well.... hehe.


I've been taking the effort to study the Visual Studio-style build system in preparation, it will get the job done. My desktop has the Express Editions of Visual C++ (V9.0/2008), C#, and Basic installed; along with MinGW and OpenWatcom, but I avoid C/C++ development under Windows as much as possible -- just not a comfortable environment. If I ever opened a shop, I would probably nab a few copies of Visual Studio proper, and just use it for building stuff ^_^.


I'm accustomed to having an entire operating system as my integrated development environment, so I do not care much for traditional IDEs, they are just not my bag. Visual Studio (particularly the more professional oriented versions) however are one of the best as far as such things go; and perhaps the only Microsoft product that I have ever met, and did not *hate* eventually. The various Visual {lang} Express Editions are also sufficient for many things; I have them setup because it was the quick route of getting something that might come in handy later, and I have no need to buy VS Standard or Professional.


GCC for Unix and Visual C++ Express for Windows, will do fine for SDL, but I have yet to decide on an XML parser... The only XML parsing I've ever done in C++, has been done though the Qt toolkit. Normally, I would expect to use libxml++ for this, but using libxml under MSVC might be more annoying them I am willing to tolerate at compile/link time. Another option I reckon, would be to try out Xerces-C++.


All development is basically going to be done on a FreeBSD machine, as that *is* my concept of an IDE lol. The only interest I have in Visual C++, is to get the most 'bang' out of the Win32 builds. So with luck, I will never have to bugger with the S.O.B. beyond getting my project built, hehe.

one way to pass the time

http://cm.bell-labs.com/cm/cs/who/dmr/

what can I say, I love studying the past lol.

You know you code to much when....

you can read this code without a compiler

even worse, when you enjoyed reading it.... haha !!!

A C programmer can write C in any language, until he gets lazy and remembers Perls regular expressions still work at four thirty in the morning.