DGMPGDec .NET???

[Cyberia]

Any plans to convert the DGMPGDec codebase to .NET? You're still using Visual C++ right?

[neuron2]

No and yes, but if you give me the new compiler, that might change.

[Nebob]

What would be the benefit?

[ppera2]

Originally posted by Cyberia
Any plans to convert the DGMPGDec codebase to .NET? You're still using Visual C++ right?

Oh no....
Instead pure exe you need some NET dependent code... Really useful :mad:

[Maximillius]

Yes, please don't do this.

[Cyberia]

I seriously doubt if the user experience would change at all guys. Why the oposition?

[Maximillius]

Originally posted by Cyberia
I seriously doubt if the user experience would change at all guys.

Cause I don't want to download the .NET framwork to use this. Secondly, if it won't change anything, why do it at all?

[Cyberia]

Originally posted by Maximillius
Cause I don't want to download the .NET framwork to use this. Secondly, if it won't change anything, why do it at all? God forbid we use a modern complier that make things easier on the design side.

[Maximillius]

Originally posted by Cyberia
God forbid we use a modern complier that make things easier on the design side.

Why fix something that isn't broken? :)

[Axed]

People will use DGMPGDec no matter what its programmed using. Come on guys, its about 15 meg to download (i think) and i would be suprised if most people dont have it already.

I think the real question is, would neuron2 gain anything out of it? If its worth his time, and saves him work in the long run i think it would be a good idea.

[stax76]

a few words for clarification: The .NET features of the compiler are mainly for interop between managed and old/legacy/native code/API's and for very specialized taskes. I don't see how a application like DGMPGDec could benefit from .NET considering a performance hit can be expected and be it only the time until the CLR loads and prepares the code for native execution.

The current compiler (2003/7.1) is free and there is also a free IDE (SharpDevelop). The beta of the new compiler (2005/8.0) is also free together with the new IDE. These compilers can be used without using the IL backend and without the need of the .NET framework to execute the resulting code.

The .NET features of the compiler were overhauled and renamed from "managed extensions/IJW (It Just Works)" to C++/CLR. I've done a few wrappers with IJW and also played around with C++/CLR (and as well with .NET 2.0 :)) and highly recommend it.

[IgorC]

I had to donwload .Net . It´s still beta (buggy). Now I have a problem with control panel of ADSL.
Size of DG is < 1mb . And now all people will must download 15 MB . There is no scense.

in fact, dotnetfx.exe - 24 mb :sly:

[neuron2]

Personally, I don't see any benefit right now (but that could be from ignorance), and I'm pretty comfortable with VC6, so unless something crops up that can't be done with VC6, I'll just stand pat.

[Doom9]

The only potential benefit I could see is easier integration of dgdecode.dll in 3rd party .NET apps. Other than that, it works just fine the way it is, doesn't it? It would sure be yet another demonstration that .NET works and that you don't really incurr a performance penalty using a non native code, but that's ideological, not practical. And I'm not sure if AviSynth could handle a .NET plugin (dgdecode.dll).

People who are so opposed to downloading a runtime should seriously think about their attitude towards new stuff. In the early days, the 1MB VB runtime was also a considerable download, and so are the MFC DLLs. You don't notice that, but many MFC apps bundle those DLLs, and its something you have to download whether you want it or not. The same also goes for many VB projects. It is highly likely that you already downloaded a .NET framework worth of VB and MFC runtimes ;)

[Nic]

Another downer is that DVD2AVI uses MMX code to make certain things quicker (i.e. iDCT). I doubt bytecode duplicates of assembly routines are as quick as their mmx/sse counterparts. (unless there is a way to use assembly in .net that I don't know)

Personally, there isn't much of an advantage. I wouldn't mind trying to write a clean C# d2v creator however (i.e. takes in vob files and spits out a d2v file).

-Nic

[stax76]

iirc then assembly code cannot be compiled to IL so these parts would remain native

[ppera2]

Well, I DL-ed NET framework 1.1 (23 MB) and installed it.
I watched message 'remaining time: 0 seconds' over 1 minute and it works now!! What a big achievement in year 2005...
As I expected it is resident in RAM (they are too lazy to make dynamic loadable service).
Usual... few clicks, and it will be removed from autorun. So much from me...

[Leak]

Originally posted by ppera2
As I expected it is resident in RAM (they are too lazy to make dynamic loadable service).
Usual... few clicks, and it will be removed from autorun. So much from me...

If you're talking about the "ASP .NET State Service" - that one is only needed if you're running IIS, so why it's even started if there's no IIS I can't even begin to fathom.

Anyhow, everything else is loaded when you start a .NET application, so other than this it'll take no additional memory until it's used...

np: Markus Guentner - Regensburg 3 (Regensburg)

[Doom9]

What a big achievement in year 2005...I know that's not nice, but it's not always possible to give a progress indication.. you'll actually see what is being done.. run those registration commands on your own to find out there's no way to know beforehand how long it takes. Progress bars are something really nasty for programmers and force them to essentially make up some kind of progress estimation on your own. And those things you make up don't always pan out. If you run one operation that can take between 1 second and one minute, how are you supposed to give the user a proper estimate? Truth is you can't.

As I expected it is resident in RAM Uh, I've been using it for 2 years now but I must be blind as I neither registered an increased amount of RAM usage after installation, and the ram used up by any .NET app is freed upon closing that app. Please point out the service/process that is eating up your memory.

few clicks, and it will be removed from autorunOnce again huh? Autorun where?

And as far as the ASP .NET State Service goes.. that one is installed but never run unless you have IIS.

[KpeX]

DGMPGDec currently emulates quite well under *nix with wine. If it was ported to .NET this would be significantly more difficult to accomplish (although probably possible with mono or something along those lines).

[jstelly]

I wouldn't suggest moving the decoding code to .NET, but exposing the DGIndex functionality as DLL exports so that I could write a C# P/Invoke wrapper for the decoding process would be great. It would mean I would be able to start the decoding and hopefully get progress updates via an API instead of having to spawn a process that I get no feedback from and that shows the DGIndex window.

That said, without knowing how much of the code is C/C++ vs. assembly (if any), the C/C++ native compiler for VS.NET 2K3 is much better than the one in VC6 so just compiling the binary in VS 2K3 without CLR support would surely yield better optimizations. Or compiling with VS.NET 2K5 you can compile to 64-bit binaries (assuming the code ports cleanly to 64-bit).

[Doom9]

when speaking of compilers, the Intel C++ compiler comes to mind as well.. it tends to be faster than Microsoft's compiler, and it integrates into Visual Studio. But I really don't have any complaints about speed.

[ppera2]

Originally posted by Doom9
....
Uh, I've been using it for 2 years now but I must be blind as I neither registered an increased amount of RAM usage after installation, and the ram used up by any .NET app is freed upon closing that app. Please point out the service/process that is eating up your memory.
Once again huh? Autorun where?



I must admit that I'm full with prejudices about MS software. I always considered their programs as inefficient, resource hungry etc. Progress indicator is not something specially important, but I will send some greeting card to Bill Gates when I will see that MS will make once one which will not stop for longer time :)

After installing NET 1.1 I 'invoked' task manager and observed new task, about 5 MB memory comsumption. I killed it without much thinking. Autorun where? : Msconfig - Automatic Run. There was some command line starter, but I can't tell exact what, I'm currently not on that computer where I installed it.
I even tried to install here, but here nothing appeared in autorun. (progress indicator acted same :) )

[Doom9]

@ppera2: well, not everything MS makes is bad.. if you compare Win95 with W2K/XP we've come a long way.

And I'm sure if you know a way to make that .NET installation progress bar better, you'll find somebody to listen. But having some experience with progress bars, I have my doubts that this could be improved.

Msconfig - Automatic RunAnd what is being run? As you said.. tried on another machine and there's nothing so you are too quick to jump to conclusions ;)

[stax76]

@ppera2

or do it like me, learn to live with bloat. :) I've installed my OS October 2003, by now basically it's a mess :D

[ppera2]

Originally posted by Doom9
@ppera2: well, not everything MS makes is bad.. if you compare Win95 with W2K/XP we've come a long way.
...
And what is being run? As you said.. tried on another machine and there's nothing so you are too quick to jump to conclusions ;)

Win XP still has typical M$ problems: too much cosmetics, oriented to very inexperienced users, too much memory usage etc. Reasons are partially in 'conspiration' with hardware manufacturers, partially in bad concept - XP is in fact most volnurable Windows until now. Any small hardware failure may cause system crash, what may require new, fresh installation. Too sensitive on hardware changes...

Installation is not always same on all machines. In may case, children installed some Newdot stuff couple days earlier, without telling me, and I thought that it's from Dotnet :)

[jstelly]

Originally posted by ppera2
Win XP still has typical M$ problems: too much cosmetics, oriented to very inexperienced users, too much memory usage etc.

Can't argue with that.

Originally posted by ppera2
Reasons are partially in 'conspiration' with hardware manufacturers, partially in bad concept - XP is in fact most volnurable Windows until now.

But that's completely untrue. The Windows 9X OSes can't hold a candle to the stability or security of W2K or XP and Windows 3.1 was a nightmare if you want to go back that far. I think I'm safe to say that every release of Windows has been a solid improvement on the version before it (Except for Windows ME which was pretty horrible). The Linux 1.0 kernel was no walk in the park, but it would be foolish for someone to discount a 2.6 kernel system based on their bad experiences with 1.0.

Originally posted by ppera2
Any small hardware failure may cause system crash, what may require new, fresh installation.

Since I'm guessing by this point that you're a Linux fan, can you point out a specific type of hardware failure that Windows can't recover from that Linux can? Before this question is taken the wrong way, it's fine to be a Linux fan, I have an affection for Gentoo that should probably land me in therapy sessions.

Originally posted by ppera2
Too sensitive on hardware changes...

As opposed to having to rebuild your kernel when you make a hardware change? What exactly do you mean by this?

I'm not trying to be argumentative here. There are quite a few valid reasons to dislike Microsoft or their products, and everyone is entitled to their opinions. But I think most of the items you list in your post are based in a strong bias that has more to do with emotion than logic (no offense intended, we all have them).

[neuron2]

We've degenerated into an off-topic Microsoft vs. Linux thread, so thread closed.