Designing the next generation of CDRfe

(last updated 17.August.2008)

I've finally found some free time to think about the next version of CDRfe. This is one of my favorite own programs, but in time I realized that this way of creating C++ closed source software will lead us nowhere. So I'm thinking about designing the next generation of CDRtools frontend. The planning is on really early stage (like some thoughts on a single sheet of paper) and I decide this time to involve the community. I realize this will take much more time than designing it by myself, but I believe the outcome worth it! So here are my general ideas about it:

• We'll start codding from scratch (will use only knowledge gathered in CDRfe development, but not a single line of code)
• We'll use some platform independent language like Java which will allow using CDRfe on other OS-es too.
• Next generation version will combine VisualISO with CDRfe into a single program.
• I'm planning to include remote recording functionality. This is when you have a single recorder and many clients
  
• The new project will be an open source and I'll be very careful with licenses this time when it comes to using external source code and/or libraries
• We might also select a better name of the project. If you have an idea please post a comment or send me an e-mail.
  

Now I'll go deeper into the technical part:

I'm planning to use a Rich client platform instead of doing everything on my own. The best candidates are: Eclipse, Netbeans and Mozilla. If you have other ideas, please post a comment or drop me an e-mail at demosten@gmail.com. At the moment my favorite is Eclipse. Advantages of using such a platform are: you have much work done and tested and we could concentrate on the actual functionality instead of for example user interface. So the software could be delivered faster and better tested. Disadvantage I can think of is that it will be much bigger and in general slower.

I need your help! I'm looking for:

• Fresh ideas what to include inside the next generation version as functionality, usability, code libraries etc.
  
• Codding help. I'll need it at moment a concrete Rich client platform and programming language is selected and the work could start. The project will be hosted probably on sourseforge.net and will have a repository and so on.
  
• Designer's help: this version should look great :)

If you can help please do it! Post a comment here or drop me an e-mail at demosten@gmail.com. I'll update this post in time so come and check it from time to time.

MinGW and Unicode support?

Recently I've been working on a program called RuntimeTester. And since it is a small and simple C++ program working in Win32 environment, I decided to port it to different C++ compilers. The original was written using Microsoft Visual C++ 2008, it has a free version which I believe is using the same optimizing compiler, but my idea was to give a chance to some free compilers and check the results. So I tried the following compilers: MinGW (compiler version 3.4.5), OpenWatcom 1.7a and Digital Mars C++ 8.42n. I've created simple batch files to run the compilers and convert a single source file to a single executable file. All went without problems. And then I remembered my idea was to make it Unicode (I've used "tchar.h" functionality in the source code). I made a copy of my batch files and added both _UNICODE and UNICODE macros, then ran the compilers. Open Watcom and Digital Mars C++ went without a problem but MinGW gave me a strange message stating: "undefined reference to `WinMain@16'". Since I'm using "_tmain(...)" a quick check at MinGW's tchar.h showed the following code when _UNICODE is defined:

/*  for porting from other Windows compilers */
#if 0  /* no  wide startup module */
#define _tmain      wmain
#define _tWinMain   wWinMain
#define _tenviron   _wenviron
#define __targv     __wargv
#endif

I did some Google around and found some ideas about how to fix it. I also found some solutions that worked in the past but not working with the new versions so I did a quick and dirty fix to my code using ANSI startup for MinGW in all environments. Here is how the main(...) function looks like:

#ifdef __GNUC__
int main(int argc, char **a_argv)
#else // !__GNUC__
int _tmain(int argc, TCHAR **argv)
#endif // __GNUC__

{
// some variables defined here
// ...

#ifdef __GNUC__
TCHAR **argv;
#ifdef UNICODE
    // MinGW doesn't support wmain() directly (shame on its CRT!)
    int a_argc;
    argv = CommandLineToArgvW(GetCommandLineW(), &a_argc);
#else // !UNICODE
    argv = a_argv;
#endif // UNICODE
#endif // __GNUC__

This is quite strange. Why there is no support for Unicode startup code in MinGW? I don't believe this is too hard to achieve! Here is a patch done in 2003. Looks like it never made it to the official build: http://osdir.com/ml/gnu.mingw.patches/2003-05/msg00001.html .

You can get the program and play with it if you like. There is more info about it inside the readme.txt file.