As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
My application is in C. I have to add a functionality in my application so that it should be able to upgrade itself according to the latest version. More specifically it should recognize if any newer version is found and get updated with that newer version (according to
the new executable). There may be situations like schema of database may get changed in the newer version. So what provision can I give in my code so that it can recognize the new executable and upgrade itself according to that?
Platform: linux, gcc compiler
So you can update your binary as proposed by #Joachim and #awoodland above. While both are valid, I would err on the side of caution and simply get your package management tool to do the donkey work. Reasons being security and more critically to resolve dependencies. Unfortunately this requires you to maintain packages however given that you probably could get away with a deb file and an rpm file and cover the vast majority this is no biggy.
On the database upgrade side, create a SQL script that backup the db and one (or a series) to update it (adding the appropriate fields etc.)
Have your script create a database version table with the version number date and time of upgrade and the software revision number that performed the upgrade and whether it succeeded or not (anything you can think that is useful. Also make sure it inserts a row into your version table every time you upgrade.
When you start your binary program get it to check the maximum version number against the expected db version to ensure that the binary is compatible with the database version else upgrade.
Extending this further you can upgrade between vastly different versions by having it loop through a set of upgrade scripts. You should keep these as an embedded resource if you want to keep them safe(r) from prying eyes but this should resolve your problem.
Hope this helps, I haven't had my coffee yet but it may point to a solution. Going a step further you could also create an upgrade log table to record how the upgrade went and if any problems were encoutered, to help in those situations that hopefully will never happen.
How about it simply overwrites its own executable, then use fork to create a new process and exec the new executable?
This is not very safe or reliable however, as has been noted. A better solution might be for the program to check a special location for an installer, preferably signed, that is downloaded and run. This installer than has to ask the user for permission to install itself. Much like the Firefox update on Windows.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
TEXT, NTEXT and IMAGE have been deprecated a long time ago and will, eventually, be removed from SQL Server.
However, they are not going to be discontinued right away, not even in the next version of SQL Server, so it's not convenient for my enterprise to transform thousands of columns right away, even if it is using SQL Server 2012.
What arguments can I use to postpone this migration?
I know there are some advantages in using the new types. But I'm strictly looking for reasons not to migrate my data that is already functioning pretty well in the old types.
Reasons for sticking with TEXT, NTEXT and IMAGE instead of (N)VARCHAR(max) and VARBINARY(max)
They currently work
Your code works equally on SQL CE as it does on SQL Server
argument only good for small DBs
There is no current budget to do so
Your company is due to fold/product has a set expiry date before the "deprecated feature" turns to "discontinued"
You don't care about your job
Reasons for NOT sticking
They won't work in future
It will be stressful to everyone when push comes to shove and you have a short timeframe for fixing
You need to code using legacy methods such as TEXTPRT, WRITETEXT, and cast all TEXT/IMAGE to VARCHAR/VARBINARY to do any useful work
Only reason I can think of to not migrate to the new type is that it's easier for the John Assymptoth of today.
If you don't care about the advantages of the new type or the fact that the types you are using will someday be removed, I can't think of a compelling reason to migrate (not that anyone asked but IMHO those are pretty good reasons). The John Assymptoth of the future might not like it though...
Your employer might be a little upset if you move on to greener pastures and the next guy isn't aware of this issue for some reason.
I would suggest you start switching over now. That way you can change one at a time and don't have to change them all at once when this feature is actually discontinued.
You really don't want to be forced into the migration at some later point in time. Your argument now should be that it poses a significant risk to the business to try and change them en-masse; this should be enough to stall the change for the time being. You need to do a proof of concept, figure out how much down time will be needed in total (you'll likely have to break it into batches of changes), create a plan to move to the new data types, and test. And then actually work to move forward. Even the mountain gives way to the river eventually...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Assuming you are trying to sell large business/government software then IE6 will be a fact of life for many years to come. If you are dealing with the UK government, NHS, or local government in the UK then IE6 support is a given.
A lot of customers will not move from IE6 as they have other web apps that will only work on IE6, they are also not willing to install other browsers for control reasons.
However I have come across cases when the customers would install Silverlight on all of their machines. How common is this?
(I am not asking if you like IE6, or if you like Microsoft, Sorry we have to many money in the world as it is today.)
Some people think this is off-topic; however as a programmer I have to decide the best technology to use when asked to create a “web app”. Most users just think of “web app” = “no need to install” and “it runs in the browser window”, so this is an important questions when planning a product.
To my knowledge, that's quite common. The main difference between Silverlight and IE7/8/9, Firefox, Chrome, etc. is that Silverlight, like Flash, is a browser plug-in the user can install by himself.
Most large businesses and government offices have an IT department managing all the machines, and the users aren't allowed to install any setup package by themselves. And if IT says it's gonna be IE6, then it's gonna be IE6, period. No IE7, no Firefox, no nothing.
However, assuming management allows the users access to the Internet, they often leave them in control of what they do with their browser, including installing plug-ins. The users then usually install Flash (essentially so YouTube works) and/or Silverlight.
The trouble is that the issue isn't usually so much "we'll install some things, but only things we think are safe", but more like "we won't install anything". The kind of organisations that are still using IE6 are the kind that are so risk-averse that you'll have a hard time getting them to install anything.
Therefore you're more likely to get satisfaction with Flash than Silverlight. The simple reason being that Flash has been around long enough that it might actually be in place on their systems already, thus negating the "we won't install anything" argument. (if they haven't even got Flash installed already, then good luck getting them to accept Silverlight)
If they are willing to install Silverlight, you might also consider trying them on the Google Frame plug-in for Explorer, which effectively turns MSIE into Chrome, but only for sites that specifically request it. The security imlications for that are pretty much the same as for Silverlight (or Flash for that matter), and if they accept it it'll mean you can write standards compliant HTML to your heart's content.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm a very frequent user of the GNU Autotools (mostly Autoconf, occasionally Libtool). I'm working on a project where portability is going to be a sticking point.. Yet, the rest of the team is just not comfortable working with m4. I got this in my inbox from not one, but four people:
Anyway, perhaps someone could recommend something Python or PHP based? I'm working on the C end of a much larger tree; I can be sure either Python or PHP 5 will be present, as they are prerequisites.
I'm taking the chance of being downvoted but, I must admit, that unfortunately there is no real substitute for autotools. CMake, SCons, bjam are nice but, when it comes to serious work... it is quite clear that autotools are superior, not because CMake can't do the same thing, but because it is just much harder to do so with it.
For example, CMake, the most popular alternative to autotools, has the following drawbacks:
No support of gettext. This may be a real problem when you need to manage a lot of translations and translated source code.
No support for an uninstall target. It is quite unpleasant to find out that you can't uninstall the program you installed.
No automatic build of both shared and static libraries.
Documentation is very limited and bad.
And so on.
There are many other points. Unfortunately, there is no real high quality substitute for autotools. On the other hand, if you develop on Windows and for Visual Studio, then you can't use autotools and you need to choose CMake that provides such tools.
I have heard good things about CMake which tries to solve the same problems. Here is the wikipedia article
I've had good success with SCons. It's built with Python and the build scripts are actually Python scripts themselves, which gives a great deal of expressive power. From the web site:
SCons is an Open Source software construction tool—that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache. In short, SCons is an easier, more reliable and faster way to build software.
There are a lot of different alternative Makefile generators and build systems out there:
CMake
Scons
Waf
Boost Build (aka BJam, C++)
Also available, but not stringently targeted on C/C++:
Premake
Ant (for Java)
Rake (for Ruby)
(Definitely more, I just don't know them all...)
But after listing these all, autotools have the great advantage of not requiring any other dependency for the end-user. A configure script is only generated once by the developer and does not require anything special on the user end, as it is a shell script. The tools listed above have to be installed before anyone can build your source and they even might have dependencies themselves.
How about simply using Make and pkg-config?
Here is a Makefile template to get you started.
Less is more people.
One more auto* replacement - mk-configure. Docs can be found here
I have had a look at CMake, which looks like a good alternative unless you are cross-compiling. If you are doing native compilation, you should try it
There's a python version of make being created at Mozilla - pymake - which presumably supports cross-platform use.
For building C/C++ software from ANT or maven you might be interested in terp. It includes a portable C++ compiler task that works with many C++ compilers on many platforms.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Has anybody any experience in using Gupta (formerly Centura) Team Developer?
If so, what do you think of it in terms of its capability to support the development of mature, scalable, maintainable applications?
Thanks
I have been using the CTD since version 1.1. Currently I'm still using 2.1 PTF4, mainly for doing rich client CRUDs under windows 98-Vista against Centura SQLBase, MS Sql Server or MS Access. I have not upgraded from 2.1 to the newer versions, so I can only talk about the relatively old 2.1 from 2001.(§)
Our applications typically have about 150 form windows, make heavy use of classes (still called "user defined variables" in 2.1) and integrate MS Office. We have no stability issues or memory leaks. The development environment is a bit long in the tooth, though: no intellisense, no smart debugging and practically unusable without a mouse. This may have changed with newer versions.
There is nothing in the nature of CTD that forces you to write un-maintainable code. Using classes and file-includes you can have a good degree of reusability in your code if you designed your code to be reusable, that is. A problem for maintainability may be that CTDs variables and classes do not have access modifiers like "private" or "protected". Also: no interfaces or abstract classes. On the other hand: multiple inheritance.
The "outline structure" of the code takes some getting used to, but I even sometimes miss the outline structure when I get lost in a sprawling C#-file with variable declarations and event handlers all over the place...
The controls for 2.1 where pretty complete but we still had to manually integrate "modern" things like toolbars, datepickers or tab-controls. OTOH it even has a numerical input field out of the box. One of the Unify-Newsletters stated that they added a lot of eye-candy, to let the apps look more up-to-date. The mtable-Extensions for table windows where very helpfull, available here: MTable by MICSTO . Integrating 3rd-party-DLLs (e.g. for integrating a smartcard-reader) is not really fun, especially when they use structs. Oh: and the "Centura Report Builder" is a royal pain in the derierre.
A big pro is the SDK that shipps with the CTD: this makes it very easy to integrate self written tools into the development environment, e.g. for code generation.
Bottom line: We used and still use CTD for scalable and maintainable apps. The learning curve can be a bit steep because of the unusual outline structure and can lead the unwary towards writing "ugly" code: e.g. lots of static functions, lots of code in the "Message Actions" and problems with variable scoping. I think your success with CTD will depend on the nature of the application you want to write: for a rich client CRUD you might almost certainly be better off than with .net, for a web app I honestly don't know.
Keep in mind that all this relates to the 8 year old 2.1 version of CTD. Things may be radically different now. If you can, get an evaluation version.
Edit: Aside from the pros and cons of the language alone, you might want to consider that CTD is a niche. There are not many free tools and I have yet to find a vibrant community (there was a newsgroup, but the server went down after the merger - maybe its still around somwhere). So, googling up help on specific Problems may no be easy.
(§) I did not continue the upgrade path from 2.1 to 5.1 because after the merge with Unify they wanted to make patches available only for subscribers to their support scheme (called GLS). Since I was not going to pay for bugfixes I deceided to continue using 2.1 for our legacy apps and switch to .net for new apps. I think they revised this later on.
I have been working with Team Developer (formerly Centura Builder, SQL Windows, etc.) for 9 years. IMO things have not changed too much from the version 2.1 which Stephan Keller described in his comprehensive answer.
The company I am working for is currently using TD version 5.1 and considering upgrade to TD 5.2 next year. We are developing a business software product, run against Oracle database. The application has more than 500 form windows and several hundred reports.
I think Team Developer scales well to both simple small applications, and larger enterprise application suites with big RDBMS and hundreds of users.
The code outline makes the IDE easy to approach and I think the learning curve will not be that steep. The code editing is possible even without mouse, since there is a number of handy keyboard shortcuts. Of course the window designer needs mouse. There is also a built-in Active Coding Assistant in the newer releases.
The newest releases (5.1 and 5.2) offer some new GUI controls, such as a date/time picker, a grid window (enhancement to the widely used table window) and Rich Text editor. There is also a new tab control. Menus can be shown ribbon-like, though this is not a "real" ribbon bar. Sample screenshots can be found on the Unify web site.
Also new GUI themes were introduced in the 5.x versions of TD, to provide a more modern look and feel for the applications.
There have been a number of stability issues, performance problems and problems with screen painting etc. with the 5.x versions of TD. The older 3.x and 4.x are known of very robust quality, having only a very limited number, if any, stability or other issues. These issues are discussed actively on the Unify Support Forum. Many of these issues are related to database routers (Oracle, MS SQL Server) or Windows API calls. The basic functionality of TD is usually working quite fine.
Also help on specific problems and questions can be reached on the Support Forum. The developer community is maybe small, but quite active.
My Company uses Team Developer for years successfully (most of our Applications are written in 2.0, with some in 5.2 as Web-Applications) and there are plans to change our development to version 6.0.
Coming from a C++ background I first had to find the way into the language (I still miss some features like encapsulation, well-structured error handling1 or scoping of variables2)
But after all, I learned to live with the limitation of the language and with some discipline our applications are relatively easy to maintain. (as a note: We have a set of base applications working together and use the same codebase with some customer-related variations to build individual versions for every customer - bugfixes appear at the common codebase (and is used afterwards for any other project), special modifications at the lokal project files). You just need to set up some basic guidelines for your projects and keep with them as the compiler wouldn't enforce them.
1 You could catch a sql error only at the point it occurs or globally for the whole program.
2 I still sometimes get cases where a mis-spelled variable compiles for something in a completely independent window - or compiler errors for semi-referenced handles sharing the same name but different data types
We used TD for several large apps but due to the lack of resources, the obsolete SAL language and aged runtime we have migrated millions of lines of SAL code and several thousand forms to C# and Visual Studio 2010 using ice tea group gupta/unify migration tool.
We were skeptical at first. But now we have brand new apps, fully integrated with our other .NET assetts with a small fraction of the time needed for a rewrite. And we didn't have to try to understand what all that all code was doing. :) the conversion was nearly perfect!
Forgot to mention that we automatically converted over 1200 report builder reports to crystal reports .NET saving probably a century of boring work.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
There is a lot of buzz about Microsoft Silverlight, especially after the Olympics. Also H264 will be supported in a future version. Where do you think Silverlight will be 1 year from now?
They were saying they were getting 1.5 million downloads per day back in March 2008, and that was before the Olympics and the Democratic National Convention. So, unless my math is off, that's more than 4 people.
I'd expect to see it show up as a recommended Windows update, and possible included with IE8 or something in the future.
At best, in the same place at Flash. Now, how many of you do Flash enterprise applications? Does Google do flash applications? or SalesForce.com? Oracle? or any other major on demand application provider?
In my opinion, even if it kills off Flash, it will still be largely irrelevant for the types of applications we write everyday.
In a year it will still be a minority of content, but the installed base will be large enough that mainstream projects will be considering it as a viable alternative to Flash. Until they survey the pool of available, talented designers familiar with it.
Most .NET developers I work with have been shying away from Silverlight.
Right now it seems more like a novelty than a development platform.
A year from now, the number of people with the runtime installed will still be a fairly small minority!
I suspect that choosing Silverlight will still be a barrier to people using your stuff for a long while to come.
100% more.
(so about 4 people)
Considering NBC has already dropped Silverlight and are using Flash again for NFL telecasts, I don't see a healthy future for Microsoft's platform.
Do they even have any other partners using it? I know WWE was one of their partners but they barely use it on their own website.
EDIT - not sure if it's true or not but this guy says that the decision to go with Flash was the NFL's and not NBC's. Either way still doesn't look good for the MS platform.
I think that as long as the Moonlight project is successful that we'll see Silverlight become significant competition for Flash.
Silverlight is still in its infancy - 1.0 had next to nothing in it. Version 2 is in beta now, and that adds lots of common user controls that developers need to write applications.
They really got a huge bump with the Olympics as far as getting it installed on machines. It will be interesting to see how much developer buy in they can gather. It's a tough sell for front end web people because it's a complete toolset change. I know the midteir/WPF people like it because it's closer to their normal .NET toolset, but they're not usually the ones doing web design.
IMHO, things like HTML5 and Gears are where many people are going to go.
I think that it will grow, but MSFT will need to do more deals like they did with the Olympics. Hooking up with CBS/NCAA on the March Madness broadcasts would be worth whatever millions they could throw at it.
Silverlight 1 Vs Silverlight 2:
Silverlight 2 is expected to be out in the next few months (they used to say in August 2008 until ... August ended. In September they say October.), so MS will probably be promoting Silverlight 2.1 (or whatever upgrade to Silerlight 2) in a year's time, and Silverlight 1.0 will likely have no developer share at all, and no momentum.
Silverlight Vs Javascript-based platforms:
Google Chrome (and the upcoming Firefox 2.1) promise an order of magnitude better performance in JavaScript. We haven't seen the best from them yet. MS will have to improve IE's JavaScript speeds, though who knows when they'll be able to ship that (in IE 9 maybe?).
I think that it will be a few more years yet before the clear winners emerge from the fray.
The installation barrier will be a problem until it ships with Windows by default. But even then developers will only support the established Flash. Considering certain mobile platforms have neither Flash nor Silverlight, it's best to back the one more likely to be ported to all platforms, and that's the dominant Flash.
In the end Javascript + SVG will almost certainly win out over these vendor produced solutions. But within a year I'd be surprised if any significant amount of development is done with Silverlight. Flash has too much momentum and MS is too late to the game with nothing sufficiently compelling.