New features request

[Loexa]

Hi, I use WinCDEmu about 3 months yet and it seems to me very useful. I think it would be excellent if there was possibility to mount images like CUE+APE, CUE+FLAC etc. It could be a special appeal of this program.
Thank you for WinCDEmu.

[support]

That could be nice, however, CUE+APE & etc formats require special decoding module, multi-track mode & etc. Basically, to add this single feature, the source code size would be increased 5 times, that is not the way of WinCDEmu.
I cannot say that this feature will never be added, however, unfortunately, it won’t happen in the nearest future.
P.S. You can use various other free software for APE/FLAC decoding, such as Winamp plugins.

[Anonymous]

Windows 7 Compatibility:

Driver is not signed. (as far as I can tell is the only problem)

Windows requires a digitally signed driver
A driver that lacks a valid digital signature, or was altered after it was signed, can’t be installed on 64-bit editions of Windows. You will only see this message if you try to install such a driver on a 64-bit edition of Windows.

[support]

Signing drivers via Microsoft is quite an expensive affair. So, as soon, as the project is free, you are welcome to search Internet for different workarounds for unsigned driver installations.

[Anonymous]

For future versions support for MDS/MDF and NRG images would be nice.

Thanks for this very usefull utility.

Heinz

[HotShot]

Hi and congratulations for this wonderful piece of software, simple, efficient and uncluttered. Works fine under Win7 Home Premium RTM.
Are there any plans to support more formats, e.g. NRG (whose specs seem unfortunately closed), or even ISZ (a simple compressed iso format whose specs are publicly available and already implemented in other software such as Winmount, Alcohol etc.).
That would make a nice addition 😉 Keep up the good work, will donate ASAP…

[Anonymous]

@hg wrote:

For future versions support for MDS/MDF and NRG images would be nice.

project developers could probably check the Cdemu project out and port some usefull features here. In ideal case would be to port “libmirage” to Windows and use it:
http://cdemu.sourceforge.net/pkg_libmirage.php

Besides to wanted MSD/MDF and NRG image formats it supports:
* B6T: BlindWrite 5/6 file format
* C2D: WinOnCD file format
* CCD: CloneCD image format
* CDI: DiscJuggler file format
* CIF: Easy CD Creator format
* DAA: PowerISO direct access archives (unencrypted)
* TOC: Cdrdao’s TOC/BIN image format

[support]

I’ve checked out libmirage. Unfortunately, this is one of those libs claiming “we are stuck in 80s, we don’t admit C++ exists, so we’ll implement all its features in raw C, manually and horribly”. Involving manual pointer table initialization instead of virtual functions, various stuff like “GObject” and “gint” instead of standard types and so on. I will consider adding support to, at least, MDS/MDF and NRG in future releases, however, I doubt I’ll even try porting this made-to-be-unportable library.

[Anonymous]

1) There is a problem with linking C++ dynamic libraries compiled with one compiler to applications compiled by another compiler. Refer to http://www.mingw.org/wiki/MixingCompilers

2) Shared modules written in C are supported everywhere. Name a language or a framework, and if it can use dynamic modules, they are probably C.

3) You can write a C++ wrapper around a C library ( http://phonon.kde.org/ , http://www.gtkmm.org/ and others) and be happy. Writing a C wrapper around a C++ library (that is, a wrapper that is written in C++, but exposes C API for applications written in C) is difficult, even if you have an object model (such as GObject) at hand.

These are real problems with C++ and portability. Of course, i could start another holywar by telling you just how much C++ sux as an objective language, but that is hardly appropriate.

So, the point is, if you’re writing something to be widespread and used by everyone (that is, a library), C is your best bet (and GLib/GObject is your best bet if you need C with OOP support). Which is why libmirage is as it is, i guess. So, i would like to wish you luck in fighting your prejudice, and will hope that libmirage will be used to its full extent.

P.S. Oh, and AFAIR the size of the ‘standard types’ is machine-dependent (that is, poorly portable). And if you’re referring to stdint, it’s from C99 (C language standard, not C++), and not supported by msvc last time i’ve checked.

[support]

There is a problem with linking C++ dynamic libraries compiled with one compiler to applications compiled by another compiler

Can you name a frequently used case, when you really need to mix code compiled with different compilers? IMHO, it’s like “cars don’t fly to the moon, so let’s not use cars at all”. AFAIK, all modern GCC versions use the same calling conversions. And all VC stuff as well. And, if you are really picky about this, just force your functions to be stdcall and be happy 😉

Name a language or a framework and if it can use dynamic modules, they are probably C.

COM, .Net, Java… KDE, at least

These are real problems with C++ and portability.

In rare cases, and only with several platform-specific subsets of C++, such as exceptions. And, frankly, I would rather port a modern version of GCC to a problematic platform (as I did for http://mspgcc4.sourceforge.net/, than do all the optimization, inlining and other stuff manually every time.

Of course, i could start another holywar by telling you just how much C++ sux as an objective language, but that is hardly appropriate

I don’t need a “perfectly object-oriented language”. I need a language allowing me to solve my problems with the minimum effort provided that my expectations about portability and performance are met. I really don’t care whether it is 19% of 91% object oriented…

So, the point is, if you’re writing something to be widespread and used by everyone (that is, a library), C is your best bet

Hmm. I guess, KDE, Visual Studio and lots of COM-based Windows applications are just not widespread enough… 😀 No, seriously, the modern world is so heterogeneous, that you can find ‘widespread’ examples for almost anything. No, really. I know people that use this: http://en.wikipedia.org/wiki/MUMPS. Surely, claiming it to be widespread.

AFAIR the size of the ‘standard types’ is machine-dependent (that is, poorly portable).

So, for the tiny probability to run your stuff on a 70s mainframe with 7-bit char, you will really agree to make your program model more complex? No, really, have you ever seen a PC running something else than x86 or x64? I know that ‘perfect portability’ is a good point, however, when it comes with a cost of making things messier…

So, i would like to wish you luck in fighting your prejudice, and will hope that libmirage will be used to its full extent.

My prejudice is that I will not spend K hours on solving a problem, if I can solve it in K/2 hours using a modern language and a modern compiler. After I add support for some of custom formats (NRG and MDF, most likely), we can compare the size of the code doing the same stuff using C and C++ (and even compare code performance, if you wish).
Once again, the problem is to distinguish between abstract terms like “purely object-oriented language” and “absolute portability” and an exact problem statement. Implementing a set of CD format parsers does not require link-time compatibility with code compiled by other tools. It does not require non-8-bit chars and exotic-sized integers. For fixed-size binary structures inside image files, uint32_t and similar types are completely appropriate. So, talking about an abstract program potentially portable in every combination to every computer in time and space, your arguments seem reasonable. Provided the real use cases from real world, I don’t agree with any of them.

[support]

Just an update about mixing code. The only practical case of using different compilers is writing plugins to existing apps. However, this involves polymorhpic approach (you implement existing interface without the program knowing internal details of your plugin) and is nicely done using C++ interfaces (that do not have problem with compiler interoperability).
Anyway, mixing compilers has nothing to do with kernel-mode code (besides, it’s Linux, not Windows, that requires recompiling the drivers for each kernel version 😆 ), so this argument does not seem to be reasonable related to the discussed problem.

[Author]

Posts