Free C++ Compilers and KX DSP

Russ · Dec 22, 2005, 03:52 AM

Yes, for any pure Win32 (C++) code you should be able to do that. It would be only a matter of setting up the environment correctly (correct compiler and linker options, etc).

Maddogg6 · Dec 22, 2005, 04:12 AM

Ahh - ok good to know...

Is it just me - or did everyones brain explode :-s

Russ · Dec 22, 2005, 05:32 AM

@LeMury,
I did mange to get it to work using wrapper functions to access the class instead of trying to access the class directly. Of course that is not going to help with the kxapi. (BTW: I was able to use the lib directly instead of creating the libTest.a)

Lex Nahumury · Dec 22, 2005, 07:04 AM

Hmm,...yes, well I managed to resolve the linker errors both with mingw as well as C++Builder
and got it to compile, but the app just can't find the correct entry points in the dll.

Which compiler did you use btw? (i dont mean your MSVC variant)

Russ · Dec 22, 2005, 07:07 AM

I used MingW with Dev C++ (which BTW, seems to be unstable at times).

Russ · Dec 22, 2005, 07:16 AM

I managed to get rid of the linker errors as well (when trying to access the class directly), but I am not sure that what I tried was valid (I posted info about it previously, but then deleted it...). When I looked at some of the files in Dependancy walker, I could see that the entry points were not valid, so I figured it was just fooling the compiler, but not really doing what it was supposed to do.

Lex Nahumury · Dec 22, 2005, 07:40 AM

Yes, I'm afraid that this is not going to work.
(I mean staticly linking exported C++ classes from another compiler)
Only way I know that works for sure is manualy loading, or a helper dll inbetween.

Hmm,.. minGW works stable for me.
I recently (re-)compiled quite some VSTis (which I originaly wrote with MSVC) with mingw,
and I must say it's performance doesn't differ much from VC6.
Only .NET optimizing compiler gave (slightly) better performance.
Not bad for a free compiler I'd say.

[EDIT]
I deviate;
The goal of this all was/is to provide a way, for people who can't afford to buy MSVC,
to use kX SDK writing some stuff.
Basic dialogs and controls are easily written using win32 api or use some free GUI framework. Most people want to 'skin' anyway in which MFC doesn't help a bit imo.

Something in the spirit of; Free driver, free SDK, free plugins,....free compiler???

Russ · Dec 22, 2005, 08:09 AM

Regarding the stability, it could just be the version I am using (Dev-C++ 5.0 beta 9.2 (4.9.9.2) with Mingw/GCC 3.4.2). When I was changing some of the project options (i.e. removing a lib) it would give an error about an access violation (after I click OK), and then (if I choose to continue) would act up on me. Otherwise it was OK. I haven't used it very much, so maybe something just got corrupted, and this type of thing is not common.

Lex Nahumury · Dec 22, 2005, 08:17 AM

Ah yes, Dev-C++ IDE is bit unstable.
But nonetheless still one of the best free ones imo.

Russ · Dec 22, 2005, 10:54 AM

BTW: I do not think this should be an issue with one of the free MS compilers. It might be worth trying with Visual C++ 2005 Express, while it is still available for free. It looks like it will co-exist without problems with other Visual Studio products, so maybe if I have the chance I will take a look. If anyone else tries, post your results.

Lex Nahumury · Dec 22, 2005, 07:04 PM

Yes, that was my original statement a few posts back;

Quote:

Originally Posted by LeMury

The only way to write kX plugins 'for free',
is by using a free MS-compiler (.NET/VS2005 Express/VC SDK)
and provide your own GUI framework.

Ofcourse. 99% that that will work, but most of those 'free' M$ releases expire
after some trial period and take Gigabytes of installation, system updates,
web installs and crap like that.

No. Max.M claimes he successfully linked kxapi with some free compiler,
so it is possible afterall.

Russ · Dec 22, 2005, 09:47 PM

Yeah, I know what you mean. I was looking at the FAQ for Visual C++ 2005 Express, and surprisingly it appears to have no restrictions. The faq stated that it (well all the express products) does not expire, and that are no restrictions on it's use (including developing commercial apps).
http://msdn.microsoft.com/vstudio/ex...q/default.aspx

Did you try that tool (coff2omf) that Max M. mentioned with C++ Builder?

Lex Nahumury · Dec 23, 2005, 12:21 AM

>>Did you try that tool (coff2omf) that Max M. mentioned with C++ Builder?
Yep. IMPLIB too (and about every other tool out there), but the result is the same
as with mingw; it compiles, but the entry points can not be found.

Are you sure VC2005 express doesn't expire?
My previous 2003 express did.

Russ · Dec 23, 2005, 04:01 AM

I can only go by the info I saw, so I really can't say for sure, but that seems to be the case for the downloadable version.

i.e. From the announcement in the MS Forum:
https://forums.microsoft.com/MSDN/Sh...26606&SiteID=1

Quote:

Until November 7, 2006, we are promotionally discounting the downloadable versions of Express to free. This doesn’t mean that the product turns off after a year, but rather that as long as you download the product before November 7, 2006, you can get it for free and you can use it forever.

Russ · Dec 23, 2005, 05:58 PM

@LeMury,

I have a few questions about creating a plugin using an alternative (non kxgui) GUI. You said you were able to do this (using platform SDK code), right? (or did you just mean that you have no problem creating GUI's using the win32 api framework, but you have not tried doing so with a plugin?)

If so...

Did you remove kxgui.lib from your linker options, and the kxgui related headers (from stdafx) when you did it? (i.e. just to be certain that you weren't using any functions that referenced kxgui elements)

Where (as in what plugin function or event) did you create your window (considering we cannot use create_cp as it uses references to kxgui stuff)?

What did you use for the parent window?

Are there any GUI related notications that you needed to send yourself (i.e. tweak window was closed by the user, etc)?

Were there any hacks/workarounds that you found to be necessary?

I am just looking for any info that you may remember about it that could help save time for me and others when when trying to create a plugin this way. And of course, if anyone else has any info about this, please share it with us.

Thanks,
-Russ

Russ · Dec 23, 2005, 06:18 PM

Does anyone know what actually is happenning in CKXPluginGUI::create() ?

That seems to be the function that keeps us from being able to use newer version of the MFC libs with kxgui (although there could be more, I am not sure as it cannot get past that function (something is looking for a window handle before it has one)). If we knew exactly what that function is doing, then maybe would could do it manually ourselves in a way that would work with the newer MFC libs.

Maddogg6 · Dec 23, 2005, 09:10 PM

I (of course..) cant answer this... but for fun I did a complete search (all files and folders including hidden and system ones) of my HDD for ANY text containing that function call - zero search results... this I thought was strange, I expected at least 1 result.

Russ · Dec 23, 2005, 10:46 PM

That it is because the function is not written like that.
CKXPluginGUI::create() basically means the create() function in the CKXPluginGUI class.
If you look in kxplugingui.h you will see the class CKXPluginGUI, and you will see that one of it's functions is create().

Lex Nahumury · Dec 24, 2005, 06:30 AM

Quote:

Originally Posted by Russ

@LeMury,

I have a few questions about creating a plugin using an alternative (non kxgui) GUI. You said you were able to do this (using platform SDK code), right? (or did you just mean that you have no problem creating GUI's using the win32 api framework, but you have not tried doing so with a plugin?)

If so...

Did you remove kxgui.lib from your linker options, and the kxgui related headers (from stdafx) when you did it? (i.e. just to be certain that you weren't using any functions that referenced kxgui elements)

Where (as in what plugin function or event) did you create your window (considering we cannot use create_cp as it uses references to kxgui stuff)?

What did you use for the parent window?

Are there any GUI related notications that you needed to send yourself (i.e. tweak window was closed by the user, etc)?

Were there any hacks/workarounds that you found to be necessary?

I am just looking for any info that you may remember about it that could help save time for me and others when when trying to create a plugin this way. And of course, if anyone else has any info about this, please share it with us.

Thanks,
-Russ

Well, if you study kxplugin.h, you'll see that kX provides
a way for custom Dialog through generic abstract iKXPluginGUI class.

Simply derive your custom Dialog class from iKXPluginGUI (not from CKXPluginGUI),
and implement it's methods;
void init_gui()
void show_gui()
void hide_gui()
void close_gui()
int extended_gui(int command,dword p1=0,dword p2=0)

In plugin, create_cp(kDialog *parent, kFile *mf) is called on 'Tweak',
and 'news' an instance of your Dialog class.
Cast and use the kDialog *parent pointer which is passed to your Dialog's constructor.
Tip: On return, create_cp() keeps a pointer in cp for reference.

The rest is a matter of programming.

In stdafx.h remove all refs to MFC and kxgui.
Include "windows.h".
Keep the kGUI forward declarations in kxapi.h ofcourse.
Don't link to kxgui.lib.

Yes, I use plain win32api to create the dialog and controls.
Release builds are also possible.

/LeMury

Lex Nahumury · Dec 24, 2005, 07:02 AM

add:
Ofcourse instead of using win32api as I do,
you are free to use whatever gui framework you want.
You might just as well use some newer MFC-version.
The trick is; not using kxgui..!

Russ · Dec 24, 2005, 07:44 AM

Thanks LeMury, that is good to know. I had thought that kDialog was defined in kxgui.lib and that we could not use create_cp because of this, (I really hadn't thought it through completley). Release builds sound nice too (I hadn't thought about that, but that makes sense because we no longer need to use the debug version of the mfc .dll's). Good stuff, Thanks again.

Russ · Dec 27, 2005, 06:10 PM

A few more things:

I noticed that 'kDialog * parent' is always NULL, so I am not sure what the point of using (casting it to HWND) it is (as opposed to just setting the parent window to NULL). This would also would mean that we should not use the WS_CHILD style for our window.

The extended_gui event: 'PLUGINGUI_SET_POSITION', always uses 0,0 when you first open the plugin window after it is loaded, which places it at the top left corner of the screen instead of centered (like it is with regular tweak windows). ('PLUGINGUI_CENTER' does not appear to be used when the window is first opened).

I am still not sure what we are supposed to do when the window is closed by the user.
i.e.
Using a basic Win32 window class.

In iKXPluginGUI we add a pointer to the window class.
In 'create_cp' we create a new instance of our iKXPluginGUI.
In 'init_gui' we create a new instance of our window class, and create the window.
In 'close_gui' we destroy the window (and delete the window object), and then delete the iKXPluginGUI object.

How should we handle WM_CLOSE of the window class so that kX knows that the window was closed, and the iKXPluginGUI object is destroyed properly, etc? I have tried a few different ways of handling this, and did not have much success in getting it to work properly.

Lex Nahumury · Dec 28, 2005, 04:07 AM

I'm using 3534 so there may be some diff, but try;

In your message handler.......
case WM_DESTROY:
plugin->cp=0;
break;

and..
void myGUI::close_gui()
{
DestroyWindow(hWnd);
delete this;
};

/LeMury

Russ · Dec 28, 2005, 10:42 AM

Quote:

Originally Posted by LeMury

plugin->cp=0;

That is what I was missing. Thanks again.

-Russ

Lex Nahumury · Dec 28, 2005, 02:43 PM

Quote:

Originally Posted by Russ

That is what I was missing. Thanks again.

Yeah np.
I wish Max.M would finaly comment on the -different compiler C++ ABI- issue.

So far I still don't see how anyone can implicitly link to kaxpi.dll with a non MS compiler.
The C++ ABIs between diff compilers are simply not compatible and there is no bintool that can fix that.

Oh well, maybe it's a 'Big Secret'.

/LeMury

Maddogg6 · Dec 28, 2005, 03:34 PM

I have (I think is simple) a question...

Is the evidence of KX using a custom GUI engine revealed by the fancy 'OK' and 'Cancel' buttons and such?

I guess it just seems ALOT of hassle just to have fancy buttons in the GUI... Somthing I could certainly live without...

[*hopes theres more to it than that*]

Max M. · Dec 28, 2005, 03:45 PM

I apologize for my tactless remark, i was not intent. Yep, i had used msvc libs/dlls with borland/mingw compilers but that wasn't kxapi. There's no "big secret" - in fact, besides name mangling (i still believe it can be overcome) - another more important issue is present - calling convention (msvc's "thiscall" being used as default for kxapi absolutely differs with other compilers).

/m