Author Topic: What the hell windows! y u so buh!  (Read 809 times)

Offline Ryex

  • Arctic Bird of Programming
  • Global Moderator
  • Chaos Ultimate
  • ****
  • Posts: 5128
  • LV: 197
  • Gender: Male
  • Wants to write a compiler for fun
    • View Profile
What the hell windows! y u so buh!
« on: May 11, 2015, 12:54:27 AM »
Sorry, but I need to rant.

as I mentioned the other day I'm working on a sane build system for welder that lets me run one command and walk away.
I've been trying to do this off an on for ages to tell the truth but I've never had the right tools. I've been using combinations of batch/bash scripts and python scripts stealing code form projects like py2exe and other frease utils.

I finally said "fuck it" and decided to do it all in python. after all python's distutils library allows people to build c and c++ extensions to python form source, it can;t be that hard to use that can it?

oh I was a fool.

you see while the python community is generally great about documentation is there one this they are terrible at it's documentation the more obscure internals . distutils is one of thouse internals.

you see most people only ever need to access ONE function form distutils and then only if they are build a setup.py script to install to install a python library. apparently it never occurred that they have this nice compiler interface built and someone someday might want to use it.

just to put this into perspective, one of the hacks I had to make to get some parts to work was to APPEND TO THE sys.argv LIST because there was no other way to access the functionality.

then when I went to go access their compiler interface I was all happy at first because I looked and the docs pearled to be in place. little did I know that not only were they WRONG is some places but they were also incomplete. I had to resort to digging into the std library and read the code before I was able to find anything usable.

but really all that wasn't that bad I've worked with plenty of undocumented libraries before (*cough*april*cough*)

what really got me was then as suggested by the title was microshits vague and cryptic development tools. there is a good reason Visual Studio is absolutely necessary for development on windows. because if you actually had to use the command line tools as is common on every other OS ever you would never be able to get anything done.

Sometimes I wonder if other windows devs realize just how bizarre the development ecosystem on windows is.

No other OS to my knowledge has a concept of resource scripts or manifests as a core part of it's binaries (ok, perhaps android has manifests fore permission and stuff but then it uses java so its' already out on a limb of the strange development tree)

in case anyone else is lost, on windows if you want to tac some resources to a binarry like and exe or a dll, for example the icon most exe's have. you write up a resource script to declare them compleat with a header file for defining the resource ID's ect. then you run that script through the rc.exe resource compiler to get a .res object which you link with all your other .obj's to get your binary.

if you in a unix os if you want to do the same thing you compile and link your binary like normal and then make an archive of your resources (tar, zip, whatever) and literally tac it on with cat.

Code: (bash) [Select]
cat myresources.tar >> mybinary
the archive it literally just written to the end of the binary. why couldn't you be simple like that eh windows!? simple to good for you?

it gets worse

windows binaries usually (but not all the time) require a manifest that... hell I'm not sure what all it's supposed to do, I know you can use it to define UAC permissions and you can do something that has to do with CRT's but why they are needed I haven't a clue. any way. these manifest are written up in XML, yes, you read that right, fucking XML. They either sit along side the binary or get embedded with the mt.exe tool.

and here we come to the peek of my day's frustrations.

you see I'm writing up the python script to do all this shit for me, I pass an extra flag to the linker to get it to generate a manifest for me (thank god for that), and everything looks good. so I gave it a run. and lo and behold! mt.exe fails, return a generic error code with a message that reads "could not load manifest".

of course I don't know what went wrong because I can't even look at the call made to mt.exe, pythons distutills hides that form me be default
so I spend an hour digging around in the source trying to find how to print out different logging levels, come to find out that they use a costume log module not pythons logging module eventhouse there is a not at the top of the file "will eventually replace with logging module", and if you bother to go into the repository and look up the blame on that line you find it was written several years ago and never touched again (WHY?).
oh, then they eschew convention and reverse the verbose levels (7 least verbose 0 is most, the fuck?).
so finally it's printing shit out for be to try and debug this vague and cryptic mt.exe error. some MSDN corss-refrencing latter and I come to find out that the command being used is just fine, all paths are correct, ever file referenced exists, all the options are formatted correctly.  research on the error message tells me that the problem could be anything from the file doesn;t exist, to bad line endings in the manifest (feh, ya sure the linker is generating a file with incorrect line endings) to incorrect xml!

out of curiosity I past the generated XML into an XML validator, it passes.

finally after two more hours of fiddling with various options and repeating the generated compilation and link commands by hand I go into visual studio and build it there. then I went and diffed the manifests generated by my script and by VS.

there was one difference. one of the values that had quotes around it in my manifest did not in the VS manifest. my linker option being passed through the script was being escaped and written into the manifest by thhe linker as is.


TL;DR
Microshit was so lazy when writing their CMD tools that they couldn't be bothered to differentiate the error for being unable to parse the XML in a manifest from the error for the file not existing, let along tell me WHY it couldn't parse the XML like any other sane compiler.

EDIT: anyway, finished the build script. so much easier now.
« Last Edit: May 11, 2015, 06:26:29 AM by Ryex »
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.

DropBox, the best free file syncing service there is.
(click to show/hide)

Offline Blizzard

  • This sexy
  • Administrator
  • has over 9000 posts
  • *****
  • Posts: 19903
  • LV: 642
  • Gender: Male
  • Magic midgets.
    • View Profile
    • You're already on it. (-_-')
Re: What the hell windows! y u so buh!
« Reply #1 on: May 11, 2015, 07:21:16 AM »
God, I hate that needless manifest shit for Windows as well. Remember to turn on DPI Awareness there, BTW.
I agree that VS is bothersome to use from CMD. While MSBuild sine VS2010 is a great concept, they overcomplicated things and never really thought of everything properly working in CMD. It's like they think no one ever uses VS like that.
Check out Daygames and our games:

King of Booze      King of Booze: Never Ever      Pet Bots
Drinking Game for Android      Never have I ever for Android      Pet Bots for Android
Drinking Game for iOS      Never have I ever for iOS      Pet Bots for iOS
Drinking Game on Steam


Quote from: winkio
I do not speak to bricks, either as individuals or in wall form.

Quote from: Barney Stinson
When I get sad, I stop being sad and be awesome instead. True story.