New unofficial installer for Code::Blocks available for testing!

[Conan Kudo]

I realized something that could help distribute C::B updates better: patching system. As far as I know, Inno Setup does not support web patching, so I am devising an installer with a nightly that could be modified to accept patches from the Code::Blocks site or from a file locally... Still working on getting the filesize down to 13MB as it is for the RC2. While I am working that out, I have a question: Does the nightlies contain anything extra in their binaries that would not be in the final version? Because its worrying me that the lowest I can get it, with the MinGW toolkit included is 23MB.... Although there might be enough benefit with the patching system, I doubt I will even attempt to send in my installer source if I cannot figure out a way to justify that additional 10MB in there.... If I can, and the patching system works, then I will submit my installer source... Otherwise, it probably will remain a secret on my computer forever....

[sethjackson]

Uhhh I think this is planned for the next release.  :? A C::B version of DevPacks or something. Maybe I'm confused here..... 

EDIT:

Or do you mean source code diffs/patches instead of binary "patches".......

[Conan Kudo]

I mean both... The devpak thing is a great idea, but there is certain restrictions, such as the fact that it requires Code::Blocks to be running, so patching the actual program is out of the question, along with the DevPak plugin, etc. My idea uses the installer I am developing to connect to the website, or use a patchfile locally to apply directly to the program or anything else. The advantage of this is that it is impossible to have filelocks on it, and nonadmins can hotpatch C::B right in, while only the HIGH ADMIN can override locks, and its easier in Vista, but difficult in XP. DevPaks are great for plugins, but not for the core or the MinGW toolkit, except for includes, apis, libs, etc. the actual core files would be handled by the patching system... It is also possible to diff source code and have autobuild as well... The advantage of the web patch system is that nightlies could be applied to older nightlies with simply running the installer and telling it to update... Code::Blocks could be hooked to start the autoupdater from a menu item, making it easier to update essential parts of Code::Blocks....

P.S: I'm not really good at C/C++ programming, so I figure I can help out the development in this way...

[idcarlos]

Hi.

NSIS have a plugins to connect to Internet and make patches.
I have made some NSIS instalers to other tools, but never with Internet update.

Code

Code::Blocks could be hooked to start the autoupdater from a menu item, making it easier to update essential parts of Code::Blocks....

Maybe If I have free time, I'll made a .bat to execute this http://csautoupdater.sourceforge.net/. Easy to implement, no need programing, only configuration. But need .NET framework to run.

[sethjackson]

But need .NET framework to run.

I think that is a no go. .NET is not cross-platform.

[Conan Kudo]

Well, my installer is NSIS.... However, I found a plugin for NSIS that allows webupdating simply by running the installer. Since the installer makes a registry key to the location of the file that uninstalls/updates it, it could be run with the update switch to request updates from the website. The code im using takes up 200k of the installer package, not 10MB.... However, I was including the MinGW toolkit with it as well, so there could be justification there, since the MinGW toolkit is 85MB is size, compared to the 70MB originally in the C::B 1.0rc2. I guess that would do it.... Well, i'm still working on the basic stuff right now, such as coding in parts that need to be registered, etc. The MinGW toolkit can be updated from the web updater component.... I'm just being careful right now... When I believe the code could work, then I will submit it... The code at the moment, is in barebones mode, which acts exactly like the existing installer. I plan to add in the other parts in a bit...

[mandrav]

I mean both... The devpak thing is a great idea

Nobody talked about devpaks. We talked about something "similar" to devpaks...

but there is certain restrictions, such as the fact that it requires Code::Blocks to be running, so patching the actual program is out of the question, along with the DevPak plugin, etc.

Whether the new system will be a plugin or a stand-alone app is not decided yet.
Besides, even if it is a plugin, who says it can't update C::B if it's running? (yes, I 've done it before)

PharaohAtem:
We appreciate that you want to help, but I think what you 're trying to do will be of no use.

• about MinGW, you should know that it's not certain that the next release will include it.
• You seem to forget that C::B is cross-platform. Functionality that is offered for a single platform only (windows in your case) will not be accepted, ever (unless it's a plugin).
  
• I don't see a reason for a "patching system". The actual download is small enough (2-5 Megs) even for dialup users. It would only complicate things and, most importantly, would add one more possible point-of-failure.

If you think I misunderstood what you 're trying to say, please clarify.
I just don't want you investing your precious time to something futile...

[Conan Kudo]

Well, anyways, I don't think I can get the point across, so I will just not ever post it... However, I will work on it for my own purposes of learning the structure of C::B. It is quite true that it would only be for Windows, but my patching idea could be crossplatform! Someone would just have to write something that can handle the patches and verify them in a similar fashion to the way my installer would have done it... Anyone who understands what I am talking about may be able to know the benefits of it... Also, it may not be neccessary to have MinGW included in the web installer stub that is also created, which takes the latest versions of the program and pulls MinGW from the MinGW folder somewhere on the C::B site if it was implemented, or we would have to use similar coding of the MinGW installer to download the MinGW toolkit also... Although mine takes the approach of being able to hotpatch even running... I'm saying that updating C::B while it is running is out of the question because sometimes there are file locks, but you proved that you can do it? What the installer would do is "save state" then close C::B and update, and "restore state" afterwards...

[Game_Ender]

This is where windows is behind the times.  On Linux and OS X you don't have to worry about "file locks" because there are none.  You could have CB patch itself and then when it reloads it will be using the new versions of the files.  Basically on *nix systems when you replace an in use file that file is kept in a hidden state for any programs that are currently using it, but any new attempt to access that file will result in the new file be used.  Much better than the heavy handed locking method windows takes.  There might be a way around this on windows but I am not sure.

[Conan Kudo]

It is called state saving hotpatching. It has been around in *nix platforms for years, and Windows has to emulate it with certain types of installers... However, Windows Vista will have native support for state saving hotpatching. It is part of the Windows Installer 4.0 package system... NSIS does have systems to do hotpatching, but state saving hotpatching takes a lot of work to make it work properly. The installer I designed is going to be written with such support eventually, but *nix hotpatching style is already a part of the plugin that I am using. It also allows web updating, which may be a good idea to eventually implement. I can also build a web version which downloads the latest MinGW toolkit and builds an installer to wrap the toolkit in, and runs the installer. This way, Code::Blocks site bandwidth could be saved a little by using the MinGW repositories to grab files to build and start the C::B installer. It turns out that MinGW takes up nearly 95MB of space, so I have justification for that extra 10MB. However, I can easily remove the MinGW part of it and create web download of the toolkit, if it is going to be a real issue. Inno does not plan to have these features, so I made my installer script using NSIS from scratch because the conversion program for Inno to NSIS is not complete. It would not be necessary to make such a system in *nix platforms, so something like Code::Packs could be used on *nix platforms to update the core without causing problems, because problems with inprogram patching can occur without knowing it on Windows. Take for instance, RealPlayer. Its core has to shut down RealPlayer FIRST before updating, and even then, you have to "update" using the full installation procedure. My system would not require full install procedure, but it would do what RealPlayer does...

[mandrav]

...

A bit off-topic, but you really should learn to press this big key at the right of your keyboard (usually having a left-pointing arrow <- and/or the letters "Return").
It would make your posts much more readable...

[Conan Kudo]

Sorry! It is a force of habit :?
Anyway, if you really believe that my system that I am developing is worthless to the Code::Blocks community, consider this: Windows Vista will enhance filelocking to the point where only installation programs registered may be able to modify program files, in order to keep spyware out. This feature is a part of Windows Defender for Vista, and is in prototype stages now. It will not be incorporated into Windows XP until it reaches final version.

[thomas]

Hmm... I think you still don't get the point. You're talking about features that Windows Vista may possibly have some day (or may as well not). It's nice if Vista will (maybe) have this or that feature, but nobody is interested in it. We're not programming for Vista. The same is true for NSIS. Indeed, NSIS is a mighty fine installer, but it does not support Linux (or any other OS). Thus, it is absolutely out of the way to use it for such a purpose - we would have to invent a separate solution for non-Windows systems.

Patching sounds like a good idea at first, but it has its shortcomings. I have been experimenting on this in the past. Using Larsson/Sadakane style suffix sorting, it is indeed possible create diff files for nightly builds which are typically on the order of 200 kB. However, a usable solution implies a massive amount of development and administrative work and it reduces reliability. Furthermore, it is only really interesting for someone who downloads each and every nightly build.
The problem is that differencing becomes less attractive the more differences are found, obviously. Thus, it works best if you build your difference files from one release to the next. That, however, means that you have to download and apply the whole chain of updates in sequence to update to current. The chain is as strong as the weakest link.

If, on the other hand, you build diffs relative to certain milestone releases, differencing loses a lot of its potency, and you still have to work out a reliable system to retrieve the correct base revision (which is a full-sized download).

Who is going to answer to the 50 users that failed to successfully apply a patch every day?
The complexity is not in relation to the benefits. It is a lot easier and cheaper to provide complete packages (even more so as bandwidth is not a concern).

Finally, whether or not there will be a all-in-one pack in the future is not certain yet (as Yiannis already said). It is quite possible that we will rather separate things that don't really belong together.

[takeshimiya]

Fully agreed with thomas.
Binary diffs can be nice, but that would be in a long term future (btw, I've used xdelta/bdiff before, it's good stuff).
Let's give the Firefox example, until 1.5 version the updates in reality was a full 4MB installer, which was ok (altrough people with dial up perhaps don't think the same). But as Firefox reached a mature state and perhaps the developers got more stability in the file-changes (and time), the feature was done.

As been said, binary diffs between milestones, or even nightly builds would not be worth the effort.
The only (perhaps) case where it makes real sense is in Security Updates and Hot Fixes (just downloading the update Firefox 1.0.6 to 1.0.7 which was 4MB was a lot -to 56k users- to say the least).

Not on the short-term todo list.

[Conan Kudo]

Alright, I have finished my beta5 of my installer, and I decided to release it today, and it is available for 7 days. It contains Code::Blocks 1.0 April 1st nightly.  By the time the seven days are up, I hope to have a new version, which will contain the latest nightly... Well, here it is!

Link: Installer updated - Click here to go to post with newest build!

Featureset:

• Code::Blocks transparent logo at startup
• Code::Blocks banner logo made by using new C::B logo
• Variable directory paths and start menu folders
• Solid LZMA compression, effective on large sized distributions
• Componentization of C::B nightly based on RC2
• Quick, speedy installation
• Code::Blocks application logo used as icon for installer

Problems/Planned Features/Unfortunate Side-effects:

• MSI-like functionality being written in, rewrite required
• InstallShield-style look, ultrahigh solid LZMA compression
• Repair functionality, allows repairing of installation if corrupt; requires total rewrite of script
• Componentized uninstallation, requires total rewrite of script
• MinGW included, either by web or within package, within package required for componentized uninstallation
• Splash is dithered to 256 colours, working on getting it to work properly
• NEW Components selection space is too small, additional space will be added with the new installer look
• NEW System key identifies wrong program as Codeblocks, fix in place, will be used in next release
• NEW Installer incorrectly identifies all Windows OSes as Windows 2000, permitting installation of unicode version; investigating
• Due to overwhelming opposition, hotpatching will NOT be included

THIS IS NOT THE OFFICIAL INSTALLER OF Code::Blocks!!! I just need some people to try it beforehand.