08 Nov, 2013, Davion wrote in the 1st comment:
Votes: 0
I've been spending the last couple hours trying to get a python module to compile on windows with the lack of VS2008 (tricky business.) While trying to accomplish this, I've stumbled a cross something that might be of interest to some. http://www.mingw.org/ is a fork of the popular cygwin. With a little wizardy (xset path to minigw\bin) I was able to get a pretty natural gcc/make from the command line. I couldn't get anything to compile, mostly because what I was using has a whole bunch of preprocessor stuff for OS's. And this is at a time when I'm guessing _WIN64 and maybe even _WIN32 wasn't around :D.

Anyways, besides all that. If I fiddled with the preprocessors, I'd be able to compile ROM natively on windows, which I think is pretty cool ;).
09 Nov, 2013, donky wrote in the 2nd comment:
Votes: 0
Mingw is pretty good. The main problem I've had with it, is symlinks in git repositories. Windows git doesn't handle these, so you get some sort of nonsense like an empty file or something in place of every link. This renders the whole repository useless. Maybe that is more a git and windows problem, than a mingw problem though.
10 Nov, 2013, Rarva.Riendf wrote in the 3rd comment:
Votes: 0
>Anyways, besides all that. If I fiddled with the preprocessors, I'd be able to compile ROM natively on windows, which I think is pretty cool ;).

ROM compiles fine with cygwin, what was your problem with it ? I used to do it before I had a better computer. (using a virtual machine was dog slow).
A problem I had by compiling with cygwin on windows is it was initializing variable with zero though. Kinda annoying to detect bugs.
10 Nov, 2013, Vigud wrote in the 4th comment:
Votes: 0
Because it's not an easy thing to do, indicates care for portability and can be seen as an achievement.
10 Nov, 2013, Tyche wrote in the 5th comment:
Votes: 0
donky said:
Mingw is pretty good. The main problem I've had with it, is symlinks in git repositories. Windows git doesn't handle these, so you get some sort of nonsense like an empty file or something in place of every link. This renders the whole repository useless. Maybe that is more a git and windows problem, than a mingw problem though.

If you're using a windows git that was compiled with mingw/msys, then that would be a problem.
You probably need to make the application call the Windows API CreateSymbolicLink() in that case.
Under cygwin, setting the enviroment to CYGWIN="winsymlinks:nativestrict" should allow only native NTFS symlinks to be created.
The only caveat is that you cannot create a symlink to a non-existent directory or file.

Rarva.Riendf said:
>A problem I had by compiling with cygwin on windows is it was initializing variable with zero though. Kinda annoying to detect bugs.

We've discussed this before. I showed that both Windows (including cygwin) and Linux both zero-out newly acquired memory pages.
http://www.mudbytes.net/index.php?a=topi...
10 Nov, 2013, quixadhal wrote in the 6th comment:
Votes: 0
Actually, I don't think something compiled with Mingw or Cygwin can really be called "compiled natively on windows". Those are both using unix compatibility layers that have to be installed, right?

For it to compile natively, it needs to compile using a standard widows tool (such as visual studio express), which will use the standard VC++ libraries. That said, I don't think there are a LOT of changes you'd need to do to make that happen, just a few things in the socket handling, and perhaps in the signal handling.
10 Nov, 2013, Tyche wrote in the 7th comment:
Votes: 0
quixadhal said:
Actually, I don't think something compiled with Mingw or Cygwin can really be called "compiled natively on windows". Those are both using unix compatibility layers that have to be installed, right?

For it to compile natively, it needs to compile using a standard widows tool (such as visual studio express), which will use the standard VC++ libraries. That said, I don't think there are a LOT of changes you'd need to do to make that happen, just a few things in the socket handling, and perhaps in the signal handling.

The last I checked, which was several years ago, MinGW used Windows sockets and signals routines.
That is you had to pretty much make the same changes to a Linux application's signal and socket handling with MinGW, that you would if you were using VC++.

The difference is MinGW is a minimal posix facade and doesn't require any supporting libraries, Cygwin is a posix emulator and does require the cygwin.dll.
For socket routines, MinGW used Winsock directly. Winsock itself implements posixy function mappings with some differences, so there's already a facade present in the sockets API (ex: select() maps to WSASelect(), etc.). The cygwin.dll contains tables that map file/socket handles to file descriptors, so it behaves just like posix.

The MSVC runtime libraries already implement posixy type facades themselves. For instance, there are no such thing as signals under Windows, only exceptions. So you get a rather minimal set of "fake" signals that can be mapped to windows exceptions, when in many cases it's much better to use Windows structured exceptions.

Which is "native" code? I would suggest all of them, CYgwin, MinGW, VC++ compile to "native" code. My perception of the term "native" versus "non-native" code, is that code that requires a VM as opposed to a real processor to execute is "non-native" code. For example Python, Ruby and Java compile to non-native code. Of course the difference between real and virtual machines has become quite blurred these days. YMMV
10 Nov, 2013, quixadhal wrote in the 8th comment:
Votes: 0
*shrug*

To me, native code doesn't require a support library to provide services that already exist in the OS. So, perhaps MinGW is native while Cygwin is not.

Not really on the same topic, but I do think you'd get more mileage out of making any given MUD compile in Visual Studio, since people on windows will likely be happier and more productive using the native windows development environment.

Also, Visual Studio Express is free to download and use. It lacks some of the high-end refactoring tools, but otherwise there's no reason NOT to use if it you're working in windows (beyond personal preference, of course).
10 Nov, 2013, Vigud wrote in the 9th comment:
Votes: 0
Quote
Not really on the same topic, but I do think you'd get more mileage out of making any given MUD compile in Visual Studio, since people on windows will likely be happier and more productive using the native windows development environment.
Yes, and our mud used to compile in Visual Studio and Pelles C, until I applied a patch from Tyche without understanding the deal with ftime / _ftime etc. I still roll my eyes when I think about it.
11 Nov, 2013, Davion wrote in the 10th comment:
Votes: 0
Rarva.Riendf said:
ROM compiles fine with cygwin, what was your problem with it ? I used to do it before I had a better computer. (using a virtual machine was dog slow).
A problem I had by compiling with cygwin on windows is it was initializing variable with zero though. Kinda annoying to detect bugs.


It appears to be treating the code as being compiled native to windows, so you actually have to use preprocessors _WIN32 and _WIN64. So I'd assume it's using the VS libs. When you compile with cygwin it treats it as a unix system.
0.0/10