How to create a simple program that behave like a Nios IDE?

rmatsick and cooi23,

I'm experiancing similar problems to what cooi23 alluded to with console vs. windows applications.

cooi23, did you ever solve that? It looks there is a difference in the full function names. If I do a dumpbin on the obj file for the console application, the full names of the functions begin with with __cdecl. those are the ones that work. dumping the obj file for the windows application show the function names starting with __clrcall. I believe that's why it won't link. It's looking for a different name than the dll/lib provides.

I haven't found a way to make it work yet. the project that works is set up for "No Common Language Runtime support". The windows application is set for "Pure MSIL Common Language Runtime Support (/clr:pure)". I think this is the driving factor, but I haven't figured out how to force the windows app to use the __cdecl naming.

any input?

jeffa and cooi23,

You are using a completely different version of MSVC++ than what I have. You are probably using the newest with .net would be my guess. I do not know what the inclusion of .net really ever brought to the table, but that is not a topic of discussion which is applicable to an Altera knowledge blog.

As I have said before, I am not a Windows programmer. In fact, I despise the Windows OS. It is nothing more than hacked-up layer upon layer of fixed mistakes over the years which needs to support as many flavors of hardware as there is electromagnetic spectrum. Each time a 'new' version is released, it inevitably consumes more and more resources. This is not efficient, nor is it a wise business model.

With that rant out of the way, I did a search on the __clrcall directive and found this:

**Microsoft Specific**

"Specifies that a function can only be called from managed code. Use __clrcall for all virtual functions that will only be called from managed code. However this calling convention cannot be used for functions that will be called from native code."

This implies that this is to be used with virtual functions. Virtual functions (methods) are only used with C++ in derived classes when you want to over-ride the base class method functionality. It also says that it is to be used "with managed code". This also implies that a some sort of code repository system is in place such as CVS or MS SourceSafe would be my guess.

Finally, it says, "cannot be used for functions what will be called from native code". Obviously, this is precisely what we are doing! Furthermore, the code is written in C, and not C++, so that blows the virtual function issue out of the water as well.

I think that as jeffa has eluded, it comes down to preference or project setting that is using __clrcall instead of __cdecl when linking. You should be looking for first before attempting other fixes.

It has been my experience that problems with the linker are inevitably always a setting problem.

In case anyone else runs into this problem, I thought I'd share what I've figured out so far. This is probably stuff that an experianced windows programmer would know...but I'm not one of those :D

It appears that when you are making a windows application in MS visual studio you need to compile with "Pure MSIL Common Language Runtime Support (/clrpure)". However, you can force the compiler to use the decorated name you want. In this case, the DLL contains decorated names using __cdecl. The solution is go into the header file (my_jtag_atlanitic.h) and place __cdecl in from of all the function names. This will force the comiler to use the name that you want. so the original header file looked like this:

typedef struct JTAGATLANTIC JTAGATLANTIC;

JTAGATLANTIC * jtagatlantic_open(const char * chain, int device_index, int link_instance, const char * app_name);

enum JATL_ERROR jtagatlantic_get_error(const char * * other_info);

void jtagatlantic_close(JTAGATLANTIC * link);

int jtagatlantic_write(JTAGATLANTIC * link, const char * data, unsigned int count);

int jtagatlantic_flush(JTAGATLANTIC * link);

int jtagatlantic_read(JTAGATLANTIC * link, char * buffer, unsigned int buffsize);

this will result in lots of linker errors as specifided in a previous post. we can add the __cdecl modifier in front of the function names as follows:

typedef struct JTAGATLANTIC JTAGATLANTIC;

JTAGATLANTIC * __cdecl jtagatlantic_open(const char * chain, int device_index, int link_instance, const char * app_name);

enum JATL_ERROR __cdecl jtagatlantic_get_error(const char * * other_info);

void __cdecl jtagatlantic_close(JTAGATLANTIC * link);

int __cdecl jtagatlantic_write(JTAGATLANTIC * link, const char * data, unsigned int count);

int __cdecl jtagatlantic_flush(JTAGATLANTIC * link);

int __cdecl jtagatlantic_read(JTAGATLANTIC * link, char * buffer, unsigned int buffsize);

this modification makes the compiler use the names that match with what's in the DLL.

I still get the following compiler warnings:

warning LNK4248: unresolved typeref token (01000014) for 'JATL_ERROR'; image may not run

warning LNK4248: unresolved typeref token (01000015) for 'JTAGATLANTIC'; image may not run

these sound a little scary, but the application seems to run fine. The Jtag link is established when I bring it up. I've hit another problem that is crashing my program before I can actually send or receive data, but I don't think it's related to this. I'll update the forum when I get that far.

I had to search around on MSDN for figure this out. I think this link had most of the explanation:

http://msdn.microsoft.com/en-us/library/ms173253.aspx

jeffa,

That's really not a solution if you continue to have warnings. I would try to find an older version of MSVC++. I am using v6.0. I did not need to do any of the things that you had described and it compiled and linked just fine without any errors or warnings, and I am using the get_error function without issue. I still suspect that there are system settings not properly addressed in your version of MSVC++. But then again, this is an Altera knowledge blog and not a MSVC++ knowledge blog.

Good luck with it.

I am using Visual Studio 2013. I had a name-mangling issue with the functions in jtag_atlantic.dll. C and C++ mangle the names in DLLs in different ways. To get this to work, I had to open my project settings and on the C/C++ Advanced tab, set the Compile As option to "Compile as C++ Code (/TP)".

I expect that's the same as adding the /TP compiler option to the command line for the compiler.

Once I did that, and made sure that the return type of jtagatlantic_get_error in my header file was enum JATL_ERROR, everything compiled and linked correctly.