Printable View
Yes. Do not take my simplified explanation to mean that I don't know what I'm talking about. There are further complexities involving the export keyword, but in general, template libraries are distributed as (original or obfuscated) source code.Quote:
Originally Posted by Joeman
I would not go further than a quick mention of Microsoft's XNA framework in that argument. I'm still very interested in an answer to my questions here regarding code security.Quote:
Originally Posted by Arjay
what is a dll then? and i said like on page 2 for a reason. maybe like on page 3 then it is there
.NET is not supposed to be a framework for developing operating systems. You certainly cannot develop an OS in VB6, so I don't see the point of this argument...Quote:
Originally Posted by RealityIsForLocos
You don't appear to understand how C++ templates work.Quote:
Originally Posted by Joeman
There's a reason that the old C string routines like strcpy were distributed in a dll, with a .lib file and a header. To use, C++ devs need to include the .lib file and header in there projects.
Whereas templated classes like std::string are only distributed in a header. To use, C++ devs only need to include a header.
There's a good reason why this is so.
But we don't need to get off topic discussing C++ templates.
My mistake on that. I know you can't hide your template code from developers since it has to stay in the header file, but you can compile it with the project and give the app to the users. I wasn't thinking very clear on the topic of linkage lol. Now back to why vb6.0 and not vb.net. Now since the template code isn't a worry since it is in native code, you don't have to worry about the header file anymore
Yes I know that but I was showing that the .net is very limiting and their are better programming languages out there if you are considering using the .net.
Please refrain from personal insults.
Actually it already exists, has been shipping for about 3 months, and is installed in over 100,000 devices already.Quote:
Originally Posted by RealityIsForLocos
Now your talking.. Why is it a strong thinking that .NET is not sutable for games.. Here is a Game in VB.NET, low resources, high speed.Quote:
Originally Posted by Arjay
Yes it may be a simple game, however it's a game. And it works.. The same was done in VB6 , and soon there will be more, I've already found a few reasonable games done in .NET....
That line of thinking does not work, so far, my findings are that the graphic core code in .NET is slightly faster than VB6..
Does this include win32 API calls? I think it would be interesting to write some simple loop which calls a GDI function several times, both for VB6 and .net, and see how they compare.Quote:
Originally Posted by GremlinSA
not quite the same. with GDI you can create the graphics image, and display it when you're done. i know it can be done using double-buffering in vb6, but requires a lot more code
I'm not sure I follow you. Are you saying that the .net graphics which GremlinSA referred to aren't direct GDI API calls? Either way, It would be interesting to see which is faster - VB6 or .net.Quote:
Originally Posted by dglienna
FYI:
Quote:
Private Message: Re: Samples
Today, 12:35 PM
WizBang
Super Moderator
Power Poster Join Date: Dec 2001, Posts: 5,676
Reputation:
Re: Samples
--------------------------------------------------------------------------------
Sounds Good. I'd recommend posting this decision in the thread so everyone following it won't be left thinking you chickened out or something.
Quote:
Originally Posted by TheCPUWizard
I have not forgottren them.
However based upon further thought and some practical issues, I have decided to upgrade the "project" to a full article and some sample code.
Since this will be published, and attacks actually invited, I am altering the techniques away from my "standard" approach for self-preservation reasons (since we have all agreed that any protction scheme CAN be broken).
Hopefully it will be finished beofre I leave on summer holiday on July 16th....
As soon as i can get some time, i'll try put together proper samples in VB6 and VB.NET to test the theory.. My observations were based on the simple asteroids game from the article, I cheated in the .NET ver, I did a VB6 upgrade on the project to get it in .NET .. and then from there, i could just fix all the 'Problems' ..Quote:
Originally Posted by WizBang
I found that alot of the code was no longer needed as the graphics methods used in .NET differ greatly from the VB6 methods..
Also all the API graphics methods are now tied into the graphics object, how this affects speed is also a question..
Quote:
Originally Posted by GremlinSA
Gremmy, You have just hit on something I would have NEVER considered.
"Upgraded" applications will definately perform poorly compared to their originals in most circumstances.
This is akin to taking a "C" program and making it compile under a "C++" compiler, and then calling it a good Object Oriented Program. :sick: :thumbd:
Code needs to be architected for the target environment from the ground up. The structure of a .NET program is radically different than a VB6.0 program (or a native C++ program).
This is akin to constructing a building you using one technology (eg. Steel), but following the contruction methods of another technology (e.g. Wood).