PureBasic Forums - English

as i know it's not possible to compile that code to 11KB stand alone exe with vb! by using .net framework, sure it will be 20MB+11KB! by the way every tools have their own pros and negs. but remember that no one care about that 20MB .net framework until their programs work.

yoxola wrote:Oneday I saw that MS stated .NET apps can works on any platform(maybe I'm wrong or the topic mislead me), but eventually it's not, .NET is just another bloated M$ product, VB Runtime is annoying enough and now they have the new big runtimes(as .NET 2.0 seems not compatible with 1.1), must worse than java for me(at least JRE can be found for many platforms)

PB is ideal for create stand alone apps IMHO, and generate very small executable, the v4 is even more powerful so I will stick with PB(and Blitz)

http://www.mono-project.com/Main_Page

-------------------------------

PureBasic also requires a 'bloathed' win32 kernel library
This topic is so biased..
While i dislike VB.NET at this time, i certainly do not dislike the .NET strategy.
If the mono project growes up or billy has invented .NET support for other os's (doubtfull) you'll most likely change your perspective on this (?)

In fact you should like the .NET system objects.
Much more stuff then through plain win32api.
.NET is simply the new winapi, o well, just stay behind, i'll grab the $$$ for you

Edwin Knoppert wrote:This topic is so biased..

Anyone here remember Spear and Wolfenstein? The graphic rendering was phanominal considering it was designed to run on a 25 megahertz processor - not the 2500 megahertz processors that are common today. Nor did they have the advantage of the high end graphics cards of today with 128MB onboard memory, etc, etc. Put either one of these games on an old 50Mhz machine and you can't play because it goes too fast. 2500Mhz????!!! Game over

Consider now with processors 100 times the speed of that era and the amount of additional rendering that could be achieved using the same technology as Wolfenstein. It's plain to see the same rendering potential existed without introducing any need for the bloated overhead found in all their succesors.

54MB for Quake II and Wolfenstein only 3.2MB

NO. We are not bias. We are knowlegable on the events that have lead us up to the point where we are today. The only bias here is a factor of greed and laziness. Those who employ bloated resources to forge their products have no interest in "earning" the title of programmer. They use those products because it saves them time and makes the faster buck therein forcing their users to constantly upgrade when it should not be necessary to do so. It cost them nothing when they force their users to upgrade. Whereas a true programmer strives to make the most of the base standards and afford the user all the glory without the additional cost of unnecessary upgrades.

VB.Net - - Now I need another 23MB of hard drive space just so I can put a window up on my screen with a button on it that does absolutely nothing!

Lazy bums professing to be programmers producing bloated software cost us all money that need not be sacrificed. They are not programmers - - they are scammers taking money out of your pocket. Fine you say. Jump on the wagon. Do as they do. We wont respect you either (not as a programmer since you are just anohter lazy greedy bum like Bill Gates).

> VB.Net - - Now I need another 23MB of hard drive space just so I can put
> a window up on my screen with a button on it that does absolutely nothing!

Well said! That's the reality of the situation. No bias here; just cold facts.

Randy Walker wrote:VB.Net - - Now I need another 23MB of hard drive space just so I can put a window up on my screen with a button on it that does absolutely nothing!

I'm not typically one to defend Microsoft but isn't there some nice functionality that that 23MB provides?

> I'm not typically one to defend Microsoft but isn't there some nice
> functionality that that 23MB provides?

That's not the point. Your app still requires the 23 MB even if you're not
making use of any extra nice functionality. That's what BloatWare is all
about, and why it's bad. PureBasic, on the other hand, (generally) only
compiles exactly what you use, and nothing more. That's why it has so
many libs -- only the used libs are compiled into your app. And that's
why we get happy whenever Fred announces that he has "split" a lib,
because it means a smaller exe from the same source code, with the
next PureBasic update.

If PureBasic were like VB.NET, it would be like having all the PureBasic
libs as one big single lib (currently 7.31 MB), and requiring that single lib
with every exe that you create. Oh, the horror! Fred is doing it right.

A few cents to say:

1.Mono is even not a MS official thing, maybe MS doesn't like this.

2.In current Windows(Win32 env.) what's the .NET can do and PE can't? Visual Studio 2003/2006 is simply a Sugar Coat of the .NET editor, there's tons of soultions out here to choose from.

3.Now there're many Cross Platform Compilers, why Linuxers/Macers should to run a weird thing which isn't even real native?

4.There's no "good" or "bad", it's simply MS is promoting .NET, if you are really so thirsty to "Get Managed by MS", feel free to follow them.

PB wrote:That's not the point. Your app still requires the 23 MB even if you're not making use of any extra nice functionality.

I guess it all depends on your perspective and timing. I'm looking at .NET (WinFX) as the new "Win32" ... the new Windows API for the future. That's how Microsoft sees it. Just like Win32 was at one time the new API vs. Win16. There's a period of transition. Eventually, as time moves on, new versions of Windows are released and the old ones fade away, and .NET will be ubiquitous - it will already exist on all Windows machines, much like Win32 is today. All new Windows API functionality will be developed in .NET. Win32 will still exist to provide some functionality and for backward compatibility but not moved forward as .NET is the new API.

If all the functionality Win32 provides today didn't already exist then it would have to be compiled into the executable, resulting in a larger executable. Much of what PureBasic does is just make calls into functionality that is available natively in the Win32 API.

So when you create a .NET executable, if you only utilize .NET-provided functionality then your executable will be very small as well.

http://www.ondotnet.com/pub/a/dotnet/20 ... maxdepth=0

> I'm looking at .NET as the new "Win32" ... the new Windows API for the future

If that's how it's going to end up being, then fair enough. But at the moment,
it's just another API on top of the Win32 API, with apps coded in .NET requiring
it to be installed. If such apps don't use any of the .NET functionality, then coding
in it is a stupid waste of resources -- it'd be like running an app under an emulator.

But if Win32 totally disappears and Windows SuperDuperVersion uses ONLY
.NET for its apps, then yes, that's fine by me. But not right now.

Eventually on Windows in the future, apps will be developed with .NET/WinFX and not Win32, much for the same reason apps today are developed using Win32 and not Win16.

In other words, you're fine to stick with Win32 today but someday, you will have to move on to .NET/WinFX... (but I suspect Fred will do much of that work for you! )

PB wrote:> I'm not typically one to defend Microsoft but isn't there some nice functionality that that 23MB provides?

That's not the point. Your app still requires the 23 MB even if you're not
making use of any extra nice functionality. That's what BloatWare is all
about, and why it's bad...

... Fred is doing it right.

Besides the blatent disregard for the cost to you and everyone else as consumers, did happen you notice your good friend Bill Gates also decided to "re-define" the nature of your .exe extentions? What the hell is that about Bill ... you big ... (Errrrgh!!!).

PB wrote:> I'm looking at .NET as the new "Win32" ... the new Windows API for the future

If that's how it's going to end up being, then fair enough. But at the moment, it's just another API on top of the Win32 API, with apps coded in .NET requiring it to be installed. ...

Is it really so? Is .NET on top of Win32?

Long time ago (maybe 1 or 2 years) I saw a presentation on the net about the working api blocks in upcoming Windows versions.

And afaik ms coded all the gui and gfx stuff new, not on top of Win32.
For "older" Win32 apps there would be a interface that resembles the current Win32 API, but this interface would sit ontop of the new gui/gfx code.

Would be interesting to know more.

USCode wrote:Eventually on Windows in the future, apps will be developed with .NET/WinFX and not Win32, much for the same reason apps today are developed using Win32 and not Win16.

In other words, you're fine to stick with Win32 today but someday, you will have to move on to .NET/WinFX... (but I suspect Fred will do much of that work for you! )

Why not make a sticky topic under general discusssion where pb users place links to information regarding the upcoming Windows API.

This way all users that have interest in it, and Fred & Co. too, can accumulate all points of interest.

Somewhere on the net I saw an article explaining how to use .net dlls with plain c++ (not .net but native code).
So it's possible to avoid .net managed code that runs through a virtual machine...

> Is it really so? Is .NET on top of Win32?

Of course. If you do a clean Win 2K install, and then want to run a .NET app,
you need to install the whole 23 MB .NET runtime just to run that app; so,
that's what I mean by "on top of Win32", because Win32 is still accessible.
Maybe it was just a bad phrase I used?

PB wrote:> Is it really so? Is .NET on top of Win32?

Of course. If you do a clean Win 2K install, and then want to run a .NET app,
you need to install the whole 23 MB .NET runtime just to run that app; so,
that's what I mean by "on top of Win32", because Win32 is still accessible.
Maybe it was just a bad phrase I used?

Well there is a difference if .NET sits side by side with Win32 or if it sits on top of it.

In any case the question is how long the Win32 API will be supported...