|
Not always true.
I'm linking MFC statically with executable and have no problem with distributing.
It's better to have 800 kb .exe than have 500 kb + 300 kb of troubles.
rrrado
|
|
|
|
|
This thread also applies to your thread above:
Static linking; now what Micrsoft Should do is provide a C++ class library that would C++ programmers develop using .net but allow them to link statically using granular linking (ie. link on references to the .net classes). Just a thought but it will never happen.
I've said this all along, a lot of harden Windows programmers will never make the switch to .net, a lot of Windows programmers are switching to WTL, lets face it MFC is about to die, not soon but definitely in the long run. It's a good idea for MFC programmers to learn something new like WTL and ATL, STL or face a work shortage in the coming years.
Me, will I do still code in MFC, but I've use to WTL/ATL/STL, and .net, I learning the core .net stuff because the Winforms very easy to pick up, I want to have an avantage over the VB programmer who will just migrate to .net.
Lastly, you'll find moving to C# and Winforms really easy if you're a seasoned Windows Programmer.
My two pennies worth!
|
|
|
|
|
Being a veteran C/C++ developer, I don't feel the need for the training wheels of .Net, nor do I need them to be more productive. As far as web development goes, that's why we developed our C++ web app server. Blows away everything as far as performance goes, and let's me work with things that I am used to. So, why switch to .Net? Or another language, for that matter.
onwards and upwards...
|
|
|
|
|
.NET is a 20MB+ redist! We'll never sell this idea to our customers - at least not for a few years. At least with MFC you can statically link - and with WTL (my framework of choice) you don't have any real dependency woes.
When I am king, you will be first against the wall.
|
|
|
|
|
Robert Edward Caldecott wrote:
.NET is a 20MB+ redist! We'll never sell this idea to our customers
A lot depends on your customers and how you sell your software. If it is a CD based product then you have no problem. Internet distribution is a bit of a problem of course. I'm very surprised the .NET framework hasn't turned up in a service pack yet.
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
I think MS is not allowed to do that anymore because of the anti-trust case. I may be wrong though... It may be that they are not allowed to bundle it as an IE update.
John
|
|
|
|
|
John M. Drescher wrote:
I think MS is not allowed to do that anymore because of the anti-trust case. I may be wrong though... It may be that they are not allowed to bundle it as an IE update.
Wasn't that why .NET was developed in the first place(*): To intermingle operating system and end-user application to the maximum as long as they where still allowed? Remember, back when they started with .NET there was a motion to cut MS into pieces.
(*)
Of course, the second reason was to change the quite outdated and complicated C-based WindowsAPI into a clean, OOP-style Interface. (Only that this will lead to two existing API for many years.)
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
kcs wrote:
If you had a C++ or VB app you still had to make sure the clients had the same version of the C++ and/or VB run-times, not to mention data access
As far as the C++ app goes, this is incorrect. You do not have to make sure the same version is present. Rather you build your installation to include the redist runtimes that you built with. The install should only install the runtimes, if these runtimes do not exist.
I won't comment on VB as I have always stayed away from using it. 
Chris Meech
"what makes CP different is the people and sense of community, things people will only discover if they join up and join in." Christian Graus Nov 14, 2002.
"And when you need to hire a programmer to do mostly VB programming, it's not good enough to hire a VB programmer, because they will get completely stuck in tar every time the VB abstraction leaks." Joel on Software Nov 11, 2002.
|
|
|
|
|
No you don't, as other said, in C++ you can statically link everything and have a self-contained executable.
For VB, you do have to redistribute DLLs, but you don't have to instal them on the system - they can live in the same folder as your app. They aren't quite 20 meg, either, they're more like 4 or 5. But that is yet another reason NOT to use VB 6 or below.
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
Navin wrote:
For VB, you do have to redistribute DLLs, but you don't have to instal them on the system - they can live in the same folder as your app.
Yes you do not have to install them, but they are still part of the install program. Also, things like MDAC are installed where MS wants them (all over the place).
They aren't quite 20 meg, either, they're more like 4 or 5. But that is yet another reason NOT to use VB 6 or below.
As I said in my post, what I was comparing was VB and data access. Otherwise it is not an apples to apples comparison. the .NET framework has so much more than the VB runtimes so comaring the VB runtimes (or the C runtimes for that matter) is really not a valid comaprison in my mind.
Could be wrong, but AFAIK when using C++ and data access, but you would need to install MDAC also.
I guess what I am saying is if your install is 10MB already, what is another 10MB between friends
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
