I saw that a new GUI was being developed in .NET 2.0. I ask that you please rethink this decision. I like that the current GUI runs natively on windows without the need for an additional run time environment. If you must use managed code, please consider something other than .NET.

What's wrong with .NET? ClamWin is already not natively running on Windows. It is using Python for the most part, which is not faster or memory efficient.

That's how I feel as well. It's totally silly to use over 100MB of hard disk space for something as relatively simple as the UI for a virus scanner. And that by no means is meant as an insult to the ClamWin developers -- I'm sure they're doing a fine job, but this does feel like an "if all you have is a hammer..." kind of solution. Above all, if you have to take care of several machines, .NET simply is an extra burden. It would mean more MS patches and updates to check, verify and keep up to date.

I like ClamWin because it's simple and effective. That's the main selling point. If you're looking for something fancy, there are more than enough commercial products to choose from.

Cheers, Bob

There's two separate components to consider:

- The ClamWin Service & real-time scanning driver, which will be loaded into memory at all times on normal use. The priority for these components should be on stability, performance and efficiency. That's why native C++ is used for these components.

- The ClamWin GUI, which is what it says: a user interface needed by the user to monitor and control the behaviour of the service component. It will only be opened occasionally and thus priority is not as much on memory-efficiency as on user-friendliness. Have you ever tried to write (and maintain) a complete GUI in a native language like C++, without using any frameworks ? You would need tons of code just to show a window, and it would be a pain to add new features over time (every new feature could lead to memory leaks or other bugs). That's why most user interfaces are written in some sort of semi-interpreted language and framework like Java/Swing, .NET, or Python. Which one you choose is just a matter of taste, and as ClamWin focuses on Windows users, .NET is IMHO one of the better choices.

regards,
Peter

I am for whatever will enable the developers to get a version 1.0 out to the users as soon as possible that meets professional programming standards. Since the Dot NET GUI is already pretty far along, that should do it. In addition, it might enable the developers to give the user more functionality further down the line.

If you look at all the bloated, inefficient, exploit-riddled software that abounds now, you might decide that a GUI that takes up a few hundred (or more) KB isn't really that important!

Regards,

I agree, this is ClamWin's major advantage.

OK, I see your point, but why not choose Java? it's more mature, stable, and the runtime isn't constantly running as a service in the background like .NET. Additionally, .NET application tend to have a very "cheap" look and feel (at least with the ones I've used), as if they where written by dragging and dropping UI elements on to a canvas. AntiVirus is serious stuff, and I think the GUI should be serious as well.

If you do decide to stay with .NET can you at least offer it as an add-on package and make the primary distribution include only the ClamWin Service with a classic GUI. I think the majority will search for this option.

The actual runtime doesn't run constantly as a service. The runtime is in the form of mscoree.dll which is loaded inside each .NET process. That is what handles loading the assembles and executing them. The ".exe" is really there only in the form of a loader. All the compiled code is loaded from the assembly cache.

The "optimization" service pre-compiles assemblies in the background at a low priority for the most part until they're all done, then it goes away. If you want more information on this see: https://blogs.msdn.com/davidnotario/archive/2005/04/27/412838.aspx




Qt, GTK, MFC, Borland stuff, etc all have gui builders. I'm not sure what applications you've used, but very common .net 1.1 type stuff like https://www.sharpreader.net/srFiltered.png sharpreader looks pretty good.



From what I can tell from your posts, I would form the opinion that you have something against .NET, which is OK. Unfortunately, people coding up the gui don't exactly show up in droves, and all the interfaces that will manage the service and what not, aren't present in the old code base.

All the service is really going to provide is the "real-time" aspect of it. All the actual scanning is done through "clamscan.exe" who's output is piped into the clamwin.exe gui. Sherpya who does the actual porting of the official clamav to windows, also wrote a little gui wrapper around clamscan. It's pretty basic, but you can see it at https://oss.netfarm.it/clamav just look for "ClamAV-GUI".

I've recently picked up C, and have found GTK may be worth learning, so I've been considering making a direct gui interface to libclamav rather than using pipes to redirect the output from clamscan.

Are you sure ? I thought 1.0 would use libclamav.dll directly (that is why the source of libclamav is in the clamwind directory of SVN) ?

anything buy .net please.

What's so bad about .NET? It's not like you'll need to download 100mb of software each time ClamWin updates, and .NET is something you should already have anyway.

Personally I'd be more concerned if Java was used, due to my OCD about the window drawing, but even that isn't such a big deal. It'll still be the same ClamWin.

I have no idea about the advantage/disadvantage of using .NET, but I'm sure WinPE does not have .NET. Been using ClamAV with WinPE to troubleshot infected system.