What Version of VS

[Julio Jerez]

I am having a great deal of problems building the project for VS 2003
now that I am using external Libraries some of these libraries requires a tremendous amount of Maintenance just to make then work with other library when Link then as static libraries.
(It is fine if they are use as DLL) some of them simple do not build with VS 2003 without making series modifications.

So as much as I like VS 2003 (in my opinion the best Version Visual Studio ever released)
So starting with 2.17 I believe I will have it drop VS 2003 builds.

I may try to recreate the project from scratch later, but unless there is an Automatic tool than can convert VS projects from 2008 to 2003 this will take some effort to do, especially with libraries as big as WxWidget and Collada.

Does anyone know of a tool that can convert VS projects from one version to another?

SomE time I wonder if I should just make a Make file

[PJani]

I think the cmake will do the trick

[Julio Jerez]

I thought of CMake but WxWidget does not have a CMake project and it is quite tricky to make a Project File for WxWidge because it have some copiler rules than Make configuration headers at compiler time.

later when I am further alone I will see if I can use CMake

[martinsm]

I guess VS2003 will still be able to use dll builds of Newton, even if it is built with VS2009. So I don't see it as a big problem.

[Julio Jerez]

yes the library can be use with any version of Visual Studio.

But I any case after I am more advanced I will get by hand dirty and try Cmake to see if I can make a one fix all project and stop this fiddling with project files every time I make a change.
But for now I have pleanty to do.

I really like VS 2003, I dot know why but things were simpler them. Besude I payed lots of money for it back them.

[Stucuk]

I guess VS2003 will still be able to use dll builds of Newton, even if it is built with VS2009. So I don't see it as a big problem.

Any programming language that supports DLL's would be able to use it. Non-C++ programming languages work fine with VS<InsertVersionHere> DLL's so all VS's should be able to. Majority of projects would use external DLL's anyway (I.E for loading texture formats) so distributing a DLL with a project shouldn't be a problem.

[Carli]

so distributing a DLL with a project shouldn't be a problem.

but not with c++.

C++ needs the signatures twice:
once in the header
and once for the linker.

but i know there are some tools to generate the linker information from the header.
Freepascal does that automatically, delphi links the dll directly.

An other way would be dynamic linking via LoadLibrary() and GetProcAddress() (Windows API)

[Stucuk]

An other way would be dynamic linking via LoadLibrary() and GetProcAddress() (Windows API)

That was my point. Any language that supports DLL's can link to them using the Windows API at the very least, so there should be no problems using a 2009 dll with 2003.

[Carli]

An other way would be dynamic linking via LoadLibrary() and GetProcAddress() (Windows API)

That was my point. Any language that supports DLL's can link to them using the Windows API at the very least, so there should be no problems using a 2009 dll with 2003.

you don't know c++

[Stucuk]

I may not be fluent in C++ but i know it has access to the Windows API. The only difference you can have between Procedures is what type they are (CDECL, etc). C++ should be able to support all types. Most you would have to do is add the CDECL/etc bit to your code. But i doubt 2003 and 2009 use different procedure types by default.

[Carli]

The problem is not the calling conventions,
C/C++ does not know dynamic linking. So it does know .dll, too. So you need to fake a static library (.lib) that loads a dynamic library (.dll). An API developer has to provide a .lib for every build system in the world: GCC and each version of VisualStudio.

[Stucuk]

Eh? If you are creating a windows application you can use the windows API.

[Carli]

You can also load a library loader that has preprocessor directives for win and unix to load a ".dll" or ".so" and link the functions with platform dependend api calls, but thats not so easy like pascals "external" declaration.

[thedmd]

C/C++ as language have no knowledge about environment on which it is running. At least in perfect world, that's the reason why dynamic linking facilities are not present. It is possible to link dynamically using platform dependent API. Standardization Committee tends to create supporting libraries rather than extending language, so maybe someone write general linking library. While this is not a trivial task and there is no need for one I doubt it eventually will be created.

Delphi/Pascal integrate several facilities in language, dynamic linking is one of those. Those (almost always) pretty looking external declarations are translated to native platform API calls.

Back to the original problem. I think that there is no need to compile Newton Editor in every possible compiler. Main need I think is for Newton itself, so library can be compiled using various compilers. All tools in SDK may compile under a few of them. Porting issues can be addressed, after tools prove their usability and community claim to require them under specified platform.

In may opinion Newton should be separated from Editor (I mean all wxWidget and Collada stuff). The main reason is those tools take huge amount of space if compared to Newton itself. More, if Newton as a library (with JointLibrary) will be released in separate package no one will complain about fact that SDK tools doesn't compile under some specific platform/compiler set. Then SDK tools may be released as a separate package with some initial requirements. If changes in Newton don't break ABI, same tools may be used with newer Newton versions.

This are my thoughts about Newton. Maybe Julio will find them useful in some parts.

[JernejL]

In my opinion, the newton simulation library and physics editor & editor file loader should be completely standalone pieces of software, ideally linked dynamically.. it is the most hassle-free way to deal with modular pieces of software, as long as interface doesn't change a lot in the future.