You may as well ship vmware in your redistributable as well, and tell them to install a full win98 system on linux to run your app, because it's almost as bad. BTW, unlike wine widgets that mono uses, I'm going to make sure my widget set actually looks like windows imagine that. I know they were planning on dumping mono and using GTK directly, but that will not provide true UI emulation either. I'm doing this directly over x, providing the fonts, color paletes, and drawing the menus. This is no cheap hotwiring to an existing library for forms. It's going to take a long time to get right.

From your link is the following quote, In the example above the resulting binary is a healty 7.5 megabyte file, This is no better than bundling the jvm with your .jar. This has been done for years now. If you can't tell the difference between a thin abstraction layer as a shared object library and a 2 line src binary that is dependant on a large runtime that must be lugged around with it where ever it's run, then I'm afraid I don't want to continue this discussion, here or elsewhere as you put it. Then you have the fact that mono does all pinvokes and winforms and drawing in win32 api calls over the wine emulation layer, so if you want anything that runs on a desktop, count on at least 30 extra megs in your rpm or linux install shield. Only a windows developer that is desperate to ship on linux, even if it's done super badly would see this as a good solution. It's not.

http://channel9.msdn.com/ShowPost.aspx?PostID=30488 P.S. -- There WILL be native versions of the Longhorn API. Looks like you won't have to use C# to use the new longhorn API afterall. Maybe my years of complaining about it on GDN payed off. Maybe I'm just lucky. At any rate, Mono on linux is about as useful as perl or bash right now, and even there. I want to stick this in an about 500KB .so file like MFC is on win so people can redistribute the runtime with their RPM's or windows install sheild, just like an MFC merge module. .NET and mono on linux is a huge runtime, that must be installed before the actual program is installed. That is the huge difference there. It is the same difference between requiring that mfc42.dll be installed and that the entire .NET framework be installed to run your program. I think that my library will be of some use to people when it has enough api to be usable. My goal right now is to run the examples from the petzold book over my X abstraction layer.

any news on this? Anybody want to help me work on my winGDI abstraction over Xlib? I'm starting my class framework

Hi, I don't care what they expect, I'm mainly doing it for myself. GTKmm is ok, but it's not as good as Win32 for me. Yes, I plan on reimplementing it closely to win32 for what I do of it. I think QT is horrible because it's so expensive then all the default projects in KDevelop are using their libraries. I use eclipse CDT now with G++ and the intel compiler and I like it better.

http://cvs.sourceforge.net/viewcvs.py/vcf/vcf/src/vcf/ApplicationKit/X11Window.cpp?view=markup[^] Ok, I see that this class is most likely your implementation of a CWnd with a couple of methods here and there. void X11Window::setMinimized( const bool& minimized ) { } ... void X11Window::setIconImage( Image* icon ) { } Quite alot of methods missing and unimplemented, I gather you probably gave up on this. This could be helpful seeing how you did things, but it's not really the way I'd ideally like to implement WinGDI over X, so I'm not going to build on it. I thank you very much for it though, I'm sure it will be useful when I'm coding it, if I get stuck, though I have the X protocol reference book as well, and I'll be looking at that to build my implementation. I can really see where you're going with this library and why you may not have had time to implement win over x, but I really have no time table, and I'm ready to waste a good chunk of time on this to get it right. The one person that gets it right will unlock linux and unix to many windows developers that simply don't want to learn GTKmm or your toolkit or any other toolkit for that matter. QT is horrible in my opinion and it costs a fortune for a single developer license. I will not use KDE nor do i use most QT based applications, aside from my ATI control panel that they made with QT for some unknown reason.

Thanks, but I'm currently reading through the o'reilly XLib library(programming manual series) and I'm aware of the client/server nature of Xlib and it's other limitations. I don't expect xlib to be comparable to win32 or winGDI, I intend to implement what I want of win32 on Xlib. There are ways around alot if not all of the problems you listed. Text can be passed as pointers to a short array instead of a char array, ect... Window hndl = XCreateSimpleWindow(...) Window can by typedef'd to HWND in a pseudo windows.h ext... and I can store it in a .so that people will eventually be able to include. MFC is not even on my radar right now. Basically, first of all I want to emulate most of the functionality in the petzold programming windows book over x as my library and it's header(s) That is my first challenge. And no, I don't want to make it 100% compatible where you can take win source and compile with g++ with my library under pkg-config --libs I only want to expose the API for GDI and windows, not the other stuff, that can stay linux/unix. I want to make it more comfortable for myself and perhaps other win programmers or ex win programmers to make linux UI software. I don't want to make a one touch library that recompiles win code to lin with no modifications. If I am successful doing what I'm going to code now, I will move on to try to put "my favorite aspects" of MFC on top of it in another .so shared lib. I have no intention of doing winAPI verbatim. Thanks for the good advise though, I saved it in my project notes.

where's the linux version? http://sourceforge.net/pm/task.php?group_project_id=12937&group_id=6796&func=browse[^] I see alot of 0%'s on the task manager for the abstraction you're doing over GTK?? Are you doing this over GTK for C or GTKmm for C++ OO implementation? I'm working on a WinGDI over Xlib without the GTK middle man myself.

I code on both with C, C++ and java, and let me tell you, the API and frameworks are shockingly similar. Socket programming, as you could see in the class I posted is very much like winsock. GDI is very much like Gnome GDI, and MFC is similar to GTKmm. Glade and Glade2 is similar to the RAD forms tool in visual studio, and the unix curses library is similar to conio.h from the win library. pthread library for POSIX threads is almost exactly like the windows C++ threading model with beginthread(&address, pvoid); and the rest of the win API, it's very similar to POSIX, but not quite. This happens alot between win and linux, similar constructs, but not exactly. Then there are also differences between the two platforms, like the compilers and tools most people use. I think if anything people would see how similar the 2 systems are as far as libraries to interface with C++. I'm not talking about stuff like COM or OLE, but rather win32.

C++ isn't portable when it does anything beyond console and file IO to communicate with the operating system. This was the whole purpose behind POSIX, which microsoft windows would not adopt. Mono is just as platform specific as linux or unix C++ in a way with different extensions and implementations on linux than win, so why only mono and not regular C++ class libraries with *nix standard headers?

what about normal C++ ? Is mono favored because it's interpreted bytecode like java? Or is there also a section with reusable C++ classes for linux and unix? I'm talking about classes you can just toss in your project folder, add to the makefile, include and use, like the ones for MFC on here.

linux and unix programming is way more than just STL. C++ itself can't really communicate with the system besides doing console and file io like C. So if you want to do UI, sockets, window managers or other stuff people expect out of a modern day linux or unix program, you have to include some headers and link some libraries that aren't in the standard C or C++ library. And that's where I think the possible problem arises unless a specific section is created.

/* #################### here is a repost of my post on the other ############## #################### forum that was seemingly in the wrong place ############## */ Pretty soon I won't be using win anymore to code, and I really like code project, and I was wondering if you could put partisan politics aside and make a linux/unix section for reusable C++ classes? Here is a sample of what I mean geturl.cpp http://www.lookingglass3d.com/cp/geturl.cpp.txt geturl.h http://www.lookingglass3d.com/cp/geturl.h.txt tried to link but the links were regex'd :/ As you can see making something simple like a reusable http get class is not any harder on *nix than win. Sure it doesn't have methods for cookies, get and post, but this is just an example I whipped up quickly for use here. *nix C++ is no less reusable or OO than Win C++ and It really would be a positive thing to have an online cataloged library of it here. Thanks for your time.

done and done, hopefully we'll hear back on this?

What if my examples use GTKmm or pthread lib -lpthread for POSIX threading? POSIX isn't supported on Win, what about other *nix library dependant classes? what about console stuff with curses or the linux ncurses? Stuff with xlib? could there be a section?

but the headers? Will they censor the headers out of it? Look at the headers I used in my linsock example, would these be edited out of my articles? #include #include #include #include #include #include What about other *nix headers for various api?

Pretty soon I won't be using win anymore to code, and I really like code project, and I was wondering if you could put partisan politics aside and make a linux/unix section for reusable C++ classes? Here is a sample of what I mean geturl.cpp http://www.lookingglass3d.com/cp/geturl.cpp.txt geturl.h http://www.lookingglass3d.com/cp/geturl.h.txt tried to link but the links were regex'd :/ As you can see making something simple like a reusable http get class is not any harder on *nix than win. Sure it doesn't have methods for cookies, get and post, but this is just an example I whipped up quickly for use here. *nix C++ is no less reusable or OO than Win C++ and It really would be a positive thing to have an online cataloged library of it here. Thanks for your time.

"Well for starters...it's written in PHP and JavaScript, so it's kinda hard to keep it closed source" Google "ioncube", of course you can make your own php encoder module with C, so if you don't want to pay the ioncube fee, you can pickup the orielly book on php and look up the modules section

can you explain this to me? What the heck does it matter if your code library is in a .NET PE or in a dll or in a .so or in COM or corba? I think the person who's post you answered is right. I've had to recompile C code for unix on linux that was written in the 80's on GCC, and all I had to change were the old style C declarations. I can still and do compile java code from JDK 1.1.8 on 1.5 with netbeans. All this stuff is bologna, it's another way to sell more books, and more IDE's and more stuff you don't really need. I'm through chasing the doggy's tail. Tell me one thing you can write a library for in .NET with IL wrapped metadata COM that you can't with regular WinAPI or MFC or Linux? Just one thing please? You can package any code as any type of reusable library, period. Sure .NET makes the code available to be linked by many languages, but that doesn't change the fact that you could do that with COM or Corba. These are the same old libraries we saw on Java and MFC repackaged as .NET IL code and labeled as "brand new" No thanks. I'm changing to linux, plus I can extend my java code into looking glass, which is actually something different on the Desktop for a change. Yes I run looking glass from the cvs on sun.com and yes I like it. I learned java before C++ many moons ago, and I never gave it up for MS's managed code, because I knew better. I was hoping they would extend the pillars of longhorn into normal C++ and MFC but they didn't and now they're cancelling the library all together. I think it's time for me to move on to something that doesn't change faster than I change my socks. I got burned on WFC a few years ago too, the msdn docs disappeared overnight on that one, it was like a great magician's disappearing act.

would IBM and sun be among them? just kidding. I get your point, it's costly, but I'd rather go this route and have lasting extensible code for my own development needs. I know this may not work for everybody and I'm not saying it should. The dropping of MFC was the final straw for me though.