So you have seen my writings on MySQL on Windows. Most recently regarding MySQL 5.5 and before that on Cluster and 5.1. So, what is the deal? Am I a mean person attacking MySQL? Am I a Windows hater trying to show how badly Windows works? Or maybe a Linux / Unix hater who want to keep those bearded 1970's terminal junkies out of my GUI Windows world?
Actually none of those. My ambition is to point out this that should be addressed in MySQL for Windows to make it more Windows friendly, for Windows users and developers. As MySQL on Windows stands right now,, it is OK for the Linux / Unix user user who also wants to run on Windows, and for those with cross-platform knowledge and ambition who want to run MySQL across the range. And I put myself among those. But I also want the Windows hard-core users to find out about, use and love MySQL. And MySQL sure could do much more in that area, but before that happens, we (yes we. We who are cross platform folks, we who who can take the time to check things out a bit and has somewhat of an understanding of what those rough edges are and we who care about MySQL and it's adoption on ALL platforms).
I really do not think that a Windows user, who is not used to Linux / Unix, whould have to learn some Linux stuff just to use MySQL on Windows. Come on, MySQL is a database system, using the SQL standard and that runs fine on Windows. Yes it DOES! And there are some good Windows integration, like the VS plugin, .NET connector and much more. MySQL 5.5 really does do away with many MySQL on Windows limitations also.
I recently reported some bugs on this matter, really minor bugs, but things that could easily be fixed and that would make MySQL on Windows a bit more polished. One issue I reported was that there are still Perl-scripts distributed with MySQL for Windows, even in 5.5. Now, installing Perl just to use MySQL is bad enough. But the thing is that many Windows users / developers don't even know what a .pl file is, and that a Perl runtime is needed! If MySQL on Windows really needs Perl to be fully functional (I don't think this should be the case. If Oracle can do without Perl, then MySQL should be able to do this also, but this is a different issue), then ship a Perl runtime with MySQL!
The reason I am reporting these minor bugs on MySQL on Windows is not that I dislike or hate this or that technology. I am waaay too old to get that emotional about technology in and of itself. The reason I am doing it is that this is low-hanging fruit on the way to make MySQL work, look and behave really good on Windows.
/Karlsson
6 comments:
I think that some people might interpret recent posts as grumpy but that was offset by your contributions -- bug reports and feedback -- that will improve MySQL on Windows. Just make sure the contribution/grumpy ratio is greater than one.
I hope MySQL on Windows goes big.
I don't use Windows much. When I worked at Oracle I had to debug a few odd problems in the RDBMS on Windows. We had shared access to Windows devel boxes. That was never fun as few of us had Windows debugging skills.
I also witnessed Microsoft take out a huge market (OLAP) with a lower priced offering. Now Oracle can return the favor.
Anders, I think you might have mixed real bugs with frustrations.
I presume some recent changes broke your build scripts. Please accept apologies for the breakage. I tried to explain that those changes are for good reasons.
You mentioned in one of your latest comments to one of your "grumpy" posts that you want MySQL on Windows be as much the same as on Linux as possible, and those changes (install layout) go into the right directions.
That means for example that "lib/opt" and "lib/Embedded/opt" and "lib/Embedded/debug" directories for libraries belong to the bad past, and going forward libraries can be found in "lib".
I have difficulties to see bug in it, it is a bug fix rather than a bug.
If you miss debug shared library I'm going to assume you wish it on all platforms.I see no good reason to maintain it on Windows only, extra IF(WIN32) tend to be fragile and break next time a Linux programmer edits in this area.
Perl stuff is not ideal, but please point me to powerful Windows user (except yourself:)) who would ever come to the idea to use mysql_config, even if it was native executable or was written in JScript/VB/batch/powershell.
Most would not know that it is at all, the rest would have difficulties to intergrate it into Visual Studio solution.
mysql_config just does not fit into how people develop on Windows
The probably best thing to replace mysql_config functionality would be to create and deliver FindMySQL.cmake and encourage people to use CMake. Then they can find libraries and headers everywhere just by using FIND_PACKAGE(MySQL).
wlad!
I'm not really sure I want MySQL to look like Linux on Windows, actually quite the opposite, I want it to be more Windows focuues, without loosiing Linux compatability to an extent (which is a difficult task, I understand).
The reason I came to think of using mysql_config was that maybe, if there was a working Windows version, that would help me overcome the situation where the non-debug libraries were moved, and that I could possibly integrate that with my build sctipt in VS. Which would have been real nice and i would sure have written a blog on how to do that, had it worked.
As for these annoyances being bugs I agree with you, they are annoyances. But annoying features of MySQL might as well be dealt with.
As for debug libraries, that is for two reasons:
- It broke my build script (and without mysql_config, there is no good way to create portable build scripts).
- Having the MySQL debug DLL is really useful when catching certain bugs, and I have shipped the debug MySQL DLL a few times. For example, if you pass a non-properly NULL-terminated string to a mysql function, which then fails in, say, strcmp. Then with a debug build I will see where it broke down in a minidump, where without the debug builds, all I know is that it failed somewhere inside MySQL. Also, I have tracked and debugged the ODBC driver in the same manner.
And true, I can build the debug DLL myself. If it had been missing all the time I wouldn't have complained. But in this case it WAS there in previous releases, and now it is gone. And as it used to be there, I felt that maybe this was a simple mistake in the build, so I better point it out. That's it. No big deal really.
And yes, you are right that even if mysql_config did work as expected on Windows, not a lot of people would know how to use ut in, say, VS. Which is why I saw an opportunity to do that and blog about it :-)
Cheers
/Karlssoon
Hi Anders,
maybe it helps a bit: PDB for optimized libmysql.dll is distributed, so there are debug symbols, and strcmp crash can be found.
For optimized build, I do find myself looking into disassembly in debugger more often than I would want to, primarily for local variables that are optimized away, it is harder to debug than unoptimized build, though still much better than "no-debug-symbols" debugging.
Wlad!
True, the pdb is there. Maybe I should do write a blogpost on how this works. Good idea!
/Karlsson
W zasadzie kiedyś naprawdę interesowałem się hazardem. Chciałem raz zagrać i tyle, żeby zamknąć tę kwestię, ale z całą pewnością mogę powiedzieć, że z hazardem tak się nie dzieje. Albo od razu cię odpychają, albo przyciągają poważnie i przez długi czas. W moim przypadku właśnie zdarzyła się druga opcja. Teraz jest bardzo fajna opcja do grania http://joga.edu.pl// kasyno online przeczytaj o tym bardziej szczegółowo, myślę, że ta opcja jest odpowiednia dla Ciebie, aby sprawdzić, czy lubisz hazard, czy nie.
Post a Comment