Is C# Viable?

It recently has come to my attention that C# may not be the best platform for ZDL. It started out as a test to see how quickly I could get a product rolled out. In reality, really fast. The have been hurdles, however. Since I do all my C# dev from Microsoft Visual Studio, and I run Linux, I have to boot into Windows XP just to do some development work. This leads to significant delays in product updates. Then there’s the deal with cross platformness. ZDLSharp works under Mono, sort of. You have to build a recent CVS version to get it to work, that is, the normal version of Mono will not run ZDLSharp. When running under mono, the look and feel is that of Windows 9x, so not particularly pretty.

Others have griped that the requirement for the .NET runtime on the host computer has been a nuisance. People have complained that they’ve tried to take their installation elsewhere on a USB key, only to find out that the host doesn’t have .NET and is locked down to prevent installations. I think the only solution, is to move away from C# altogether, and move to a cross platform library.

Oh Dear

There seems to be a problem with the new ZDLSharp. I wrote some of the code for ZDLSharp 3.0.5.3 on the train on my way to a friend’s place, I also had previously made a backup of all that information. Well it appears I deleted those files on arrival, and started work on 3.0.5.3 again thinking this was the files I had modified, but apparently I was wrong.

Some of the bugsfixes I made for 3.0.5.3 didn’t actually happen. I only fixed one bug, and that was for Mono users. Since the weekend is coming up, I really want to get a new version out ASAP. It has also come to my attention that the source for ZDLSharp hasn’t been released, so I want to put that up on sourceforge, and keep binary releases to my own servers. I think that works best.

Anyways, keep your eyes and ears peeled for new and exciting news!

Prepping for ZDLSharp 3.0.5.3

I’ve made great headway on a couple of the bugs. Unfortunately there’s one that will take some time, so now I’m faced with the decision to either fix it or leave it for another time. I really want to get this version out the door, as it’s taken a long time. Part of the changes I want to implement to fix it are slated for 3.0.6.0. I planning a better configuration backend and doing away with the old ReadINI support. Of course, since a substantial amount of the program is built on this old code, it will take quite a few hours of coding. The current bug is pretty isolated I think.

As for my plans in the wiki for 3.0.6.0, this is what I’m planning:

1. New Update System
• I’ve chosen to do a hybrid between self updating and leaving it alone. I don’t want people to have to open their browser every time just to update
2. Community Functionality
• This feature won’t be in 3.0.6.0 at all. Perhaps in subsequent versions, but it’s not in the pipeline yet.
3. Config File Trampling
• Currently with the readINI() functions, any unknown lines are completely removed. I’m going to change this, plus also keep track of what version wrote the last config file. I recommend that all ZDL ports use this functionality, and warn users if they’re using an old config file. If the user agree’s it’s cool, overwrite it if a better system isn’t implemented. If the user isn’t cool with it, read the config, but do not write it back at the end.

What Happened to ZDLSharp?

So if you’ve been looking for the promised 3.0.6.0 version of ZDLSharp, and feel disheartended by the talk of Triplet, don’t fear!

I promised a few weeks ago that there would be a bugfix 3.0.5.3 version out, however, due to family issues, I was unable to work on ZDLSharp. Now that I’m about to start Exams, I won’t have much time for either Triplet or ZDLSharp. Not to worry! I will be free after the 18th with loads of time until I start work on January 14th. I really want to roll out 3.0.5.3, and then roll out 3.0.6.0 by January 14th. No promises though! There are plenty of bugs to fix up, for both the windows and mono versions. It’s important that these be fixed up quickly, so that we can get to a stable point. There are a few critical blockers, that abolutely need to be released ASAP. Normally, 3.0.6.0 would have been released, skipping 3.0.5.3. One of the features of 3.0.6.0 is the reworked backend, ditching Bio’s old readini functionality. This has proved not to be useful, and very inflexible, introducing compatibility problems. Any new features I introduce in the ini file are erased as soon as an older client opens it. I would like to merge my changes with Risen’s version of ZDL 3.1. I believe it is very important that non-understood entries in the config file stay untouched.

ZDLSharp and Mono

I was able to compile the nightly build of the Mono 2.0 beta the other day, and actually get ZDLSharp running in Linux! There are also a slew of new bugs found in both the Mono version and the Windows version. I’m hoping to make a change to the release schedule and actually release 3.0.5.3 this weekend, and then start work on 3.0.6.0. I feel the bugs are severe enough I need to make a bug fix release. I invite all Linux users to try out ZDLSharp in Mono. I have a precompiled and packaged tar of mono for extraction to your home directory.

Also, thanks to Siggi who helped me find all kinds of bugs, and making ZDLSharp even better!

And finally, I’ve attached a screenshot of ZDLSharp running on my Ubuntu Gutsy Gibbon.

I want your feedback!

If you’re a ZDLSharp user, please take a look at this page, and tell me what you think! Feel free to write directly into the wiki in a way that isn’t destructive. Alternatively, you can leave your comments on the blog.

Edit: ZDLSharp has had over 310 downloads to date! There’s over 30 installations of 3.0.5.2 to date as well. For more information on ZDLSharp, please visit the ZDLSharp wiki.

ZDLSharp Shift in Focus

I know, I know, ZDLSharp 3.0.5.0 offers a lot of features that you all really want. But first, I need to write some semi-related code. I’ve been starting on ZDL Sidekick, a cross platform console and GUI based ZDLSharp configuration launcher. It doesn’t offer the same GUI features of ZDLSharp, but will be cross platform (wx or console based) to provide everybody with access to ZDLSharp files.

There are some unique challenges that I proposed for ZDLSharp in the future, and required for ZDL Sidekick. Firstly, a non-destructive configuration reader. I’ve already started work on that, and it’s going really smoothly. I’m bringing in a few new features in ZDL Sidekick, like an enhanced ZDL configuration format called Extended ZDL Configuration. I’m going to try my best to provide backwards and forwards compatibility with ZDL, which should prove to be a challenge.

ZDLSharp 3.0.5.0

Tommorow night I should be releasing ZDLSharp 3.0.5.0, although no promises. While it’s been a week or so to do some minor fixes, it’s been a very busy week. I’m going to dedicate a large chunk of time tommorow to finishing of 3.0.5.0.

I’ve launched a new wiki website, at zdlsharp.vectec.net. Check it out, it has all kinds of interesting information, plus roadmaps. If you have any extra information to add, please feel free, or if you have any questions or suggestions, edit the talk/discussion pages.

I bought a $70 C# book a couple weeks ago. Unfortunatly I havn’t had a chance to look at it. Hopefully it’ll give me a few good tips on how to make ZDLSharp your favourite ZDoom program!

ZDLSharp and Mono

I tried to run ZDLSharp with Mono today. Unfortunatly, Mono won’t have support for Winforms until Q3 2007, so Linux users at locked out until then. Sorry!

That being said, once Winforms 2.0 is supported in Mono, I will be doing semi-regular tests in Linux to make sure everything is going fine. I also implemented a primitive Update Manager. Right now it only prompts the user if there’s a new version, but in the future it will be more complex. I have higher priorities with ZDLSharp right now .

ZDLSharp Design Goals

Currently in the pipeline for ZDLSharp, is:

• Add DMFlags generator to the interface
• Finish adding current ZDL features (multiplayer)
• Do code cleanup and refactoring/debugging
• Implement file hashing system
• Start implementation of ZDLNet
• Redesign the interface

Things will pretty much happen in that order. Bio and I will be working hard on ZDLNet, to make it as smooth and user friendly as possible. We’re going to open the actual protocol. The main protocol is going to be a centralized TCP server, and use UDP for connection testing and file transfers between users.

BioHazard adds:

My pipeline is:

• Read up again on network programming.
• Set up project server and backend server.
• Write central server software.
• Write a GTKmm client for ZDLNet. (Yay Linux support!)

I’ll be writing the server software since I have a bunch of servers floating around.
I’m really looking forward to seriously working with Q on a project.