Hello,

I noticed since when I used to do a bit of coding before, there is a new C standard, C11.

I am using MinGW on Windows 10, which to my understanding is still C99 standard. Just out of interest, I have a couple of questions regarding;

What compilers are you using for coding in C on Windows for C11 standard? Are you using C11 at all?

Just FYI, I would be using it through the Code::Blocks IDE. I am not fond of MSVS.

And...

How is the compatibility / usability of A5 with C11? Is A5 still the latest distribution of Allegro? I read that SDL, for example (not that I use it), is soon to be dropping "support" of MinGW.

Sorry for these questions, I'm only just getting back into the loop, and beg for your patience, please.

Thanks in advance...

I have always used C and I compile all my programs with -std=gnu11, I compile with MinGW using Code::Blocks as my IDE. I recommend using the gnu11 version of C11 as it also includes certain useful gnu extensions, which I honestly can't remember what they are at this moment, but I do recall needing -std=gnu11 instead of -std=c11 for some reason.

I use the following version of MinGW-W64 available here: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-posix/dwarf/

My Deluxe Pacman 1 and 2 games were both compiled with C11 and Allegro 4 and 5, actually, I compiled Allegro 5 myself using the C11 setting (gnu11) without problems.

OK, thank you for the information!

Regarding the Allegro A5 distribution; at my stage right now I would rather download the Windows binaries. Back in the day when I was on Linux I used to build it, but at the moment I am worried I might mess up the build (until I regain a little more experience).

Which should I obtain here?

Win Binaries

I am assuming the file;

allegro-i686-w64-mingw32-gcc-7.2.0-posix-dwarf-static-5.2.4.1.zip

...would be the right one for me.

Thanks again, for the clarification.

So the one I need is this one;

allegro-x86_64-w64-mingw32-gcc-7.2.0-posix-seh-static-5.2.4.1.zip

A very small, additional confusion was born from this, though, so my apologies for the insistence.

I was assuming that the "static" in the file name meant that the Allegro library had been built statically for the binary, not that it would build the programs you created with Allegro statically. I thought that the option to build statically or dynamically remained yours using the flag;

-static

This raised yet another question for me. I've been looking around trying to clarify it myself, but I'm only be making this worse if I don't ask (I want to get it right).

Is there any reason I should not use this file?

allegro-5.2.4.0.zip

In other words, why are some of those binaries MinGW specific?

Again, sorry for being a pain!

Thanks in advance.

No. I won't. I use GNU compilers, period. My projects are built for gnu compilers. If you try building it using something else, than I will want to know how in hell you got a hold of my source code? There's no shortage of gnu compilers, but hey, knock yourself out dreaming up problems that will never happen.

It's not entirely unreasonable for Microsoft to build MSVC for Linux in the near future. They're being forced to support Linux for Web and various other ventures. They're starting to surrender on the OS front and focus more on software. I'll keep holding out though. They won't do it willingly, but they'll submit by force. That said, it'll probably require community involvement to pull it closer to the standard (unless they just replace the compiler with a free option that's already closer). Since my job requires ASP.NET/MVC use the VsVim extension to make the environment Vim-like in ways. It still requires way too much mouse involvement. For example, finding and switching files. There are also benefits to its "intelisense" when it works. There are a handful of features that I use that can be useful, but generally tripping over the IDE overrides them in general. You still don't need it. It doesn't do anything so well that you need it. They might well find that there's less and less of a market for it going forward, and developers are forced to stop being babies and learn to code "for real". Well, we can dream.

They already have, sort of. We've been using it for 6 months: https://blogs.msdn.microsoft.com/vcblog/2017/04/11/linux-development-with-c-in-visual-studio/

Basically it's an extension to Visual Studio 2015/2017 that replaces cl.exe with gcc on a remote linux system (or gcc in that weird Linux subsystem thing in Windows 10). It also uses gdb/gdb-server as a debugging engine (but still retains the typical Visual Studio debugger UI)

It is definitely not as clean as just straight up developing on Linux using vim + makefile, however 4 out of 5 members of my team had absolutely no experience with gcc / development in linux ... so the VC++ for Linux development was a good way to ease them into it. I'm 100% confident that we would have wound up using either Netbeans or Eclipse to develop our Linux application, both of which (in my opinion at least) suck as C++ IDEs compared to Visual Studio.

You are 100% correct. The IDE remains on Windows. The binaries that are produced remain on the Linux system and are indistinguishable from binaries produced with make-files using equivalent gcc flags. However I still find it an interesting combination of the Visual C++ IDE with gcc as a compiler.

Back to bamccaig's original point though, in recent years Microsoft has released a version of Visual Studio for MacOS. Basically it's just for cross platform development of mobile/web applications, however there are two fairly recent announcements from the Microsoft world that I believe could stir up enough interest to warrant a full blown port of MSVS to Linux and OSX.

#1: Microsoft recently announced they will be releasing their own 'Linux' operating system. Reading their press release about it they basically admit that Windows is not really suited (/cough too bloated /cough) for the various lightweight hardware configurations of 'IoT' devices and the Linux kernel was much more suitable for them to build a platform around.

#2: .NET Core 3 will support Desktop Applications (including WinForms). (Albeit I agree that this doesn't really have anything to do with MSVC, however if they release a full blown C# IDE for Linux.

Actually, I don't know. Even if Microsoft does wind up shipping these two products (I'm pretty sure the .NET Core 3 thing will definitely happen) I don't know if there'd be enough of an influx of new developers to the Linux platform clamoring for a full blown Visual Studio port.

Linus would never intentionally sabotage his own ecosystem and legacy just for a couple of bucks from Microsoft. Remember when he gave nVidia the finger?

Well, he literally gave the finger to nVidia for benefiting from Linux without giving back to the open-source nVidia drivers.

As much as I hate DRM, I'm not actually opposed to allowing binary drivers and DRM. Like, if having DRM lets Netflix run on Linux, so be it. Even though it's likely easy to bypass, it's about appeasing stupid heads. (The same reason many AAA companies have DRM--their publisher FORCES them to use it while 99% of game programmers are gamers and gamers hate when DRM explodes in their face.) And binary drivers, many companies still have a conservative / historical / ancient mindset of "I wrote it, therefor I should be the only one that benefits from it."

There's also the very REAL issue of whoever is the platform leader, has MILLIONS in IP (and even more in hidden, non-public IP), that they don't want people simply copying. As much as nVidia is a big bunch of dicks for not contributing back to open source, they also have a reasonable premise for keeping their fastest drivers a secret. There are dozens of real Chinese companies that would (and do) reverse-engineer nVidia's products and are completely un-sueable because of their government. So while I wouldn't be surprised that their secrets DO get reverse engineered, there's the question of EASE of reverse engineering.

Likewise, Wifi on Linux is DRM protected ... ish. Why? Because of all the government regulations that if they made it completely open, then anyone on Linux could switch their wifi gear's channel region-code. And if they do that, people could very easily start using illegal radio spectrums and the news and idiots in government won't see "300 separate people abuse a tool" they'll see "Linux enables abusers".

Further, keeping that binary mode for wifi has encouraged many more developers to support Linux. I remember 2005 when literally NOBODY had !@$!@$ing Wifi support. You got it installed and... congrats... you could Linux it for almost nothing. Because there were no drivers.

Thanks, Edgar Reynaldo.

Yeah, it has all clicked again. In fact, I have a very vague recollection that if you wanted to statically link, you could go ahead and rebuild the whole Allegro library from the source alongside your project with the static link option. I might be wrong, but if I'm not mistaken it was either Elias or Tomasu who helped me with something like that on the IRC chat, back then.

Of course, it was Linux, then. I'm yet to look into how CMake, or its equivalents, work on Windows.

And thinking of that, perhaps I should install a Linux OS on my present rig, too, so I can work on both, again.

Thanks again!

Upon my return to hobby programming a very short while ago, I thought I might try starting with C#, on MSVS Community. The whole thing was a very, very bad experience in which everything seemed to be along these lines;

"For this, you need to install this MS component, and for that, this other MS component, which needs this and this other MS...." etcetera.

I wish I could figure out how to strip all of it out as if it had never been there without doing a Windows reinstall.

The long and short of it was I was doing absolutely no coding. I was nearly put off, until I remembered Code::Blocks and a gcc version for Windows (which even without Code::Blocks works fine off command line, which I'm comfortable with).

And of course, Allegro...

I do think I will come down on the side of the dynamically linked binary, though, for the moment. Windows is rather "proud"(?) of its dll's for development (don't ask me to expand on that, it is just an impression I get), IIRC, and in any case, I won't be "distributing" any projects (for the time being) that need to be static, really.