I would love to offer a JavaScript attempt - although it would have to fake a DB since it's all browser.Quote:
Originally Posted by Schmidt
Printable View
I would love to offer a JavaScript attempt - although it would have to fake a DB since it's all browser.Quote:
Originally Posted by Schmidt
That would be great - and when you read the requirements really carefully - the Base-Data isQuote:
Originally Posted by szlamany
a simple ASCII-TextFile (which requires parsing into "more efficient InMemory-structures",
which will then in turn allow for a better FullText-Search, to be able to serve requests faster
to the client-side).
So, no real "persisting DB" allowed in this scenario... on the server-end exists "read-only-
access to the FileSystem" (think: "CD-ROM which contains only the Bible-Textfile")...
And for those who already start with a http-based Browser/Webserver-solution (any WebServer
allowed... Node.js, Apache, IIS, Mongoose - homegrown ones) - the (additional) design-
requirement could be, that one will earn "extra-points" for ease of movement (amount of
reusable code) to a perhaps better performing "non-http-based" solution (serving a normal GUI
over WCF for example) - and vice versa for the guys who start the other way around ...
Olaf
"Mort" is less a description of programming skill than a description of what a programmer does and how he goes about it. More of a role than a skill level.Quote:
Originally Posted by Shaggy Hiker
Mort may be writing code as an adjunct of his "real job," whanging out quick solutions in the absence of greater resources that could be applied to more engineered or crafted solutions. He might be a front line coder primarily doing maintenance work on existing software. It's a case of simple economics: some roles require low costs and quick results more than they do great expertise and care.
You don't need a horticulturalist with 10 years of practical experience to mow a lawn, so it isn't worth paying one to do it. He may get bored and do a crappy job too. That's why you see those carnies driving trucks around hauling mowers on trailers. For all we know some of them have advanced degrees and a ton of experience but got laid off and are just doing what work they can find, or maybe they've decided to slow down and get off the treadmill.
I think "Mort" describes what you do and not necessarily what you are capable of.
Yeah, I really like that description, dilettante. That's why Mort doesn't "go away", and why sneering or blaming this or that language for Mort's existence isn't very productive.
If someone rubbed a magic lamp and used their wish to gain the ability to educate every developer to Knuth's level and beyond, everyone would write great, clean code. But the need for boring CRUD apps (and not all CRUD apps are boring) wouldn't go away. Now someone fit for writing the code for self-driving cars has to "stoop" to writing those CRUD apps. That's not really an effective use of resources.
So really, we should be sort of glad people are out there to fill Mort's role. They fill jobs a lot of us would be bored to tears taking. Unfortunately, it's not widely known when a manager should take a Mort off the job and put in someone that can clean up the mess. That's when non-Morts feel pain and curse Mort's existence.
I like for people doing Mort jobs to aspire to more, but not everyone can cut it. If we want to "fix" things, maybe our efforts are better spent educating the people that hire Morts about choosing the right developer for the job. Either way, VB6 and VB didn't create Morts. They just made it easier to find a person that was willing to do Mort's job.
Sorry I missed that post. I headed into the woods on that day and just got back. Considering the impressive amount of writing from then until now, I decided not to read all the posts that I missed.Quote:
Originally Posted by Schmidt
The suggestion is a really good one for a coding contest. It isn't terribly difficult, nor is it trivial, and it does manage to avoid being about math tricks. Unfortunately, I also think it's liable to be DOA just like (most of) the other coding contest suggestions. I'd like to see it come about...but I barely have enough time to waste posting on VBF already, and I would expect that others feel the same way.
However, the more I think about it, the more I think that your idea has merit beyond just voluntary work on a forum coding contest. It isn't my field to be studying coding efficiency, but I wouldn't be surprised to find that some company like MS, Google, or some such, might be interested in funding a true study of coding efficiency in various languages, and that problem seems like one that could be done. The one change I would suggest would be that the document being searched might be something that was large and a total snoozer, such as the Congressional Record, rather than a more controversial text like the bible. After all, with the Congressional Record: Nobody would already know what was in there and nobody would know what was NOT in there.
Well, thought so too...Quote:
Originally Posted by Shaggy Hiker
It's targetting more the "LOB- and Enterprise-Development for the Win-Platform", which I think
most of the VB* and C# professionals have quite some experience with...
As for "Dead-On-Arrival" (in the contest-forum) - since I was making the suggestion,
you can count on that I'll provide a VB6-based solution.
A Javascript-based approach seems already to be considered by szlamany (I'd suggest Node.js to implement the
serverpart in his case, and for the 8 stresstest-threads in the BrowserClient there'd be WebWorkers since HTML5).
So the only thing missing is the commitment of one (or a few) .NET-developers who'd like to invest
"a day or two" as well, to make that already a worthwhile "thing to study and refer to", when finished
(not only for the sake of comparison between languages or development-platforms, but within a given
language/platform also for folks who will profit from a well-implemented "wireframe" for this kind of problem).
Just looked at the thing - but it's quite a complex animal "structure-wise" - not that easy toQuote:
Originally Posted by Shaggy Hiker
rummage around in (and to define *what* to parse or index for Full-Text-Search and -retrieval).
The explanation for the "Bible-parsing" I was able to do basically in a single sentence.
(I gave a Link to a Zip-File along with the structure-def: Books/Chapters/Verses -
any given Verse then being considered a "Document-Node" - to search, and deliver
when a match was found (in one or more Verse-Snippets).
Here is the start of the Raw-Data in the ~5MB Bible12.txt-file:
...and so on... Each "Verse-Document-Node-Paragraph" already beginning with a Prefix-ID,Code:Book 01 Genesis
01:001:001 In the beginning God created the heaven and the earth.
01:001:002 And the earth was without form, and void; and darkness was
upon the face of the deep. And the Spirit of ...
which describes BookNr:ChapterNr:VerseNr - and any new Book in the Text-Document will start
with the same HeaderLine-Format as seen above with "Book 01 [couple of SpaceChars] Genesis".
So the parsing-part is not really difficult to do or understand - just a bit above "beginner-level".
What remains for the server-part is only, to "catalogue" the words (related to the Verse-IDs)
in a FullText-Index (but there's Libs for this part) - and to provide concurrent access over
sockets for the Client-part.
So, for the sake of an easier to understand "task-description", I'd stick with the Bible-Text...
Also cannot see, what'd be "controversial" about it (when used only as a "bundle of words" in quite
the right size and structure, still managable in potential "solution-zips" when they are posted).
As many other nerds I'm a non-believer, but however - it's a nice task - so why not imagine
that "a customer asked for it", threatening you even with a well-paid contract... ;)
Olaf
Yeah, I see your point there. The Congressional Record is a mess.
I got thinking a bit more about the contest as a comparative study. It would be a sociology study, which makes me queasy, but it would require two different studies. After all, the coding contest isn't any kind of comparison between languages. It COULD be a comparison between languages, but only if the sample size is so large that you can tease language differences out from the confounding factors. With just a few submissions from different people you'd really be looking at a comparison of their effort, ingenuity, and language comprehension (programming language, of course). A trivial implementation would be essentially a RegEx of the file. The performance would be horrible regardless of the language, but the code would be very simple. Such a submission would show little about the language. A slightly more complicated version would be chunking the file and using multiple RegEx on different threads/tasks, which would show a bit about languages (JS doesn't directly multithread, nor does VB6 easily), but would still be a pretty poor solution. More complex indexing and heuristical seaches would be more complex and would show more about the dedication to the problem of the developer(s) than the languages.
So, the first study would just be to come up with various approaches, which is what the coding contest does. From that pool, a second study would be to choose one of the approaches and implement that in each language. That would compare languages more than algorithms, though there would have to be some flexibility in the rules because you wouldn't be able to say, "store this in a Dictionary." Instead, it would have to be more like, "store this as key value pairs by whatever means you choose."
I wouldn't theorize that much about it.Quote:
Originally Posted by Shaggy Hiker
It's a relative simple task, which might come in as a well-formulated, clear description in
exactly the way I layed it out in my post #730 also from a customer, who'd be even
willing to pay for such a solution. (which in the end could be a bit larger even, but
the customer wants to decide which way to go, from concrete demo-implementations
which come in from "all the bidders").
We program and develop, to provide such solutions - and we use certain tools to develop them -
and most of us have specialized in using a concrete tool, which has proven worthwhile
to provide such solutions for "typical tasks in a given field" (here, a typical "multiuser-
office scenario").
What I simply want to see is, how well certain tools really do "in the field",
when confronted with such a concrete task (a customer-request, which could lead
to a well-paid contract).
There's nothing "social" about it - just developers and their tools, applied to (always
the same) problem.
Sure, the solutions (when they come in) will reflect different skill-levels - but when a
certain solution outperforms all others by quite some degree in "measurable regards" as e.g..:
- deployability (ease of installation on different systems)
- lines of code used
- general design (extensibility and structuring of above code)
- performance (here measurable over the achieved requests per second)
- GUI-design (usability and general appearance)
Then questions could be raised, why all the other provided solutions were doing that
badly in comparison.
If it is due to the skill-level, then - by all means - a more skilled developer (who's using the
same tool) should be able to step up and point out the mistakes which were made in applying
certain stuff to the one(s) who posted this not really competitive solution (or he could
send in a better one himself, to underline what the tool he's using is really capable of).
So in the end - when we keep this contest "open" over a longer time, we should see
the effects of this kind of self-correcting "leveling-out" of the different solutions.
I fail to see why something like that shouldn't be worthwhile.
Let's assume for the moment, that VB6-solutions are indeed "better" in providing concrete
and practical solutions than their .NET-based equivalents (which, in the end, they aren't -
they will just look a bit different...).
But then, when the next .NET-guy comes along in a thread like this stating that:
"my tool of choice is more capable than yours, it's time to move on" - one could simply
point him to the accumulated solutions - and ask him to give proof for that statement
(since the results were telling otherwise, so far...).
He could then choose one of the already existing .NET-solutions (to save time) - and simply
show everybody, "how it's done better". If he fails to do so, then he was either wrong in
making his statement - or he didn't have the skills (yet) to come up with a better solution.
If it's the developers skills which were lacking - why should other developers listen to specuations
of somebody who has still some climbing to do on his own personal learning-curve?
That's my simple line of argumentation - dont' speculate, don't theorize - just formulate
a concrete "customer-task" and show the code which "solves this exact problem".
Other users of the same tool who think that you solved it inefficiently, will step in soon enough.
As for Javascript-Threading... this is not that difficult to do - WebWorkers are an established
entity for a few years already - the coding-efforts are comparable to other languages -
this mandelbrot-worker here (original folder: http://people.canonical.com/~jamesh/fractal/)
has rougly the same volume as the code in a VB6-ThreadClass, also calculating a "single Row of Pixels":Code:self.onmessage = function (event) {
var data = event.data;
var c_i = data.i;
var max_iter = data.max_iter;
var escape = data.escape * data.escape;
data.values = [];
for (var i = 0; i < data.width; i++) {
var c_r = data.r_min + (data.r_max - data.r_min) * i / data.width;
var z_r = 0, z_i = 0;
for (iter = 0; z_r*z_r + z_i*z_i < escape && iter < max_iter; iter++) {
// z -> z^2 + c
var tmp = z_r*z_r - z_i*z_i + c_r;
z_i = 2 * z_r * z_i + c_i;
z_r = tmp;
}
if (iter == max_iter) {
iter = -1;
}
data.values.push(iter);
}
self.postMessage(data);
}
So, also with Javascript one could fulfill all the requirements of the task I layed outCode:Public Function CalcRow(ByVal RowIdx As Long, ByVal RowWidth As Long, _
ByVal MX As Double, ByVal MY As Double, _
ByVal xStep As Double, ByVal yStep As Double)
Dim x As Double, cx As Double, cy As Double
cy = (RowIdx) * yStep + MY
For x = 0 To RowWidth - 1
cx = x * xStep + MX
pRow(x) = LUT(MBColorIdx(cx, cy) Mod ColorCount)
Next x
CalcRow = Array(VarPtr(pRow(0)), RowIdx)
End Function
Private Function MBColorIdx(cx#, cy#) As Long
Dim it As Long, x2 As Double, y2 As Double, xx As Double, yy As Double
xx = cx: yy = cy
Do
x2 = xx * xx
y2 = yy * yy
If (x2 + y2) >= 4 Then MBColorIdx = it: Exit Function
yy = 2 * xx * yy + cy
xx = x2 - y2 + cx
it = it + 1
Loop While it < MaxIterations
End Function
without jumping through hoops.
Olaf
I certainly think it is worthwhile, but I doubt that a coding contest for a problem like that would show anything at all about the tools used. After all, if submission A used a straight RegEx solution, but submission B made use of some clever caching and indexing, B will be larger, but could be MUCH faster. Considering that we tend to find solutions by inspiration (prior to some point we only believe that an answer exists, after that point we have a good solution in mind....we've probably all experienced that state change in our minds), a great deal of the difference in solutions may have nothing to do with skill or tools, but inspiration...which may be due to experience, so it may be a measure of skill, but that isn't clear.
We are both considering a means to test variations between tools, which would be the ideal outcome, but the differences between people would be pretty stark in the initial round. However, if person A provides a solution in VB6 and it is faster than that provided by person B in VB.NET, then the two algorithms could be compared. If the algorithm used by A is superior to that used by B, then B could take the algorithm from solution A and re-write in .NET. At that point, you are comparing the implementation between the two languages of the same algorithm.
So, I would say that the first round would be to try out different algorithms, while the second round...if it even happened....would be able to compare the languages more directly. I'm frankly pessimistic about people putting that much into it, though. As you noted, there is some interest, so it could happen, but I'm still pessimistic.
EDIT: I am working on devices that don't have lots of HTML5 stuff implemented. I havn't tested Web Workers on those systems yet, but then again, I barely do any JS.
Don't Get Me Started - VB6: Waking a Sleeping Giant
https://msdn.microsoft.com/en-us/magazine/mt632280.aspx
We already have 98% of what his "VB*" would do already, and arguably maybe 1000% of what it would do since we don't have to give up ActiveX: HTML Applications (HTAs).
No it doesn't use HTML5 and no it doesn't compile down to JavaScript. But otherwise it is a giant superset of what a "VB*" as described would do.
The downsides are lack of portability (because VBScript is very ActiveX-friendly) and lack of performance (because the bathless .Net horde at Microsoft actively opposed any optimization and enhancement to VBScript).
So if you demand portablity and better performance HTAs don't cut the mustard. Otherwise they do and all you really might want is a decent IDE (something we never got).
If those aren't important to you then I'm not sure what a "VB*" brings to the table that you can't already get using some other language. And if they are important to you there are lots of other languages.
It's almost as if he thinks VB6 is about the language syntax and nothing else. Surely he can't be that dense?
And even if such a thing did come along, it would not have that stability of VB6. That is an entirely accidental side effect of its deprecated status. Stability was what he based his whole notion on:
So I'm not sure the article adds up to any kind of sense at all.Quote:
I was having lunch with a client some weeks ago. He has a Silverlight-based solution that displays video from security cameras. But Microsoft has now deprecated Silverlight, encouraging developers to switch to HTML5 instead. “That’s a pain in the ass,” complained my client. “I was doing fine with what I had. Now I have to go learn another language and migrate all my code. My app isn’t all that complicated, just a few video streams and some buttons. I wish there was some way to make that really easy.”
Thank you Skreener!!!! I must say after trying to migrate my code from VB6 to VB.NET is just absurd. VB.Net is three times the work that VB6 is, just to do the SAME THING.Quote:
Originally Posted by Skreener
Results may vary. The migrations I've done had no appreciable difference one way or the other.Quote:
Originally Posted by DFPCNC
Here's the other side of that migration coin.
One of my first big .NET projects was a multi-threaded file searcher that looked for suspicious files like .mp3s on a vast collection of network shares. If you asked me to write it again today from scratch, given a firm set of requirements I'm pretty sure I could hit every high note in a week and have something robust/showable in 2. If you instead handed me the source code and told me to migrate it, I'd have to budget at least a month, with no guarantee I'd have all features present.
It'd take a week just to comb the code and figure out what features were implemented, and if there are any that were attempted but aren't working. It'd take several days to decide how much of it I could reuse. Development would move slowly, because for every new feature I'd have to test it first in the old program, then compare the new program to it and prove I did the same things the same way.
Porting a program is hard, especially when you have less experience in the new language. That's not .NET's fault. It's like you studied French for a year, then were handed an entire novel to translate. Of course your native language will seem so much easier. Ask a French native to do the same, and their complaint will be that your native language is what makes it so complex.
But considering we get better as developers as time goes on, even that metaphor isn't complete. Porting a program is more like being handed Moby Dick in French as written by a second-grade student with D marks, then being asked to write it in English. If you think English or French is the source of difficulty there, you have some bad thoughts to deal with. There's certainly some clunky mechanisms in .NET, but it's fascinating how quickly we forget that over decades with a language, we learn how to work around its rough edges.
I agree that "porting" woes have less to do with the old and new language than other factors.
Working from requirements can be a lot smoother. However with legacy code of any serious vintage any requirements documents remaining are probably far out of date. Even good requirements documents don't get updated with every nuance of the adjustments made in requirements between the start and end of the original development effort.
Porting old applications is just hard.
In one shop I used to work at they had a vendor come in to "help run" a project to convert some mainframe systems to Windows. For "fire one" they chose VB.Net and sent a lot of staff to formal training in it.
Most of the programming was done by the vendor. The idea was that the shop's permanent staff was going to take on long term maintenance after delivery. Well the project failed miserably after lots of time and money had gone down the drain. They got less than 1/4 of the new software to a testable condition and performance was a joke.
So next the vendor said "well gosh we need to use C# for better performance, yeah, that's the ticket."
So another round of training. In another language. Another group of vendor contractors. "Fire two," more time, more money.
That was about 5 years ago now. The mainframe software is still in use.
Porting old applications is just hard.
Edit:
I forgot that there was a "Fire Zero" in there. The first attempt was a vendor package "already done, just needs customization." ASP.Net front end. That lasted two years and the interim result performed so poorly, omitted so many requirements, had so many bugs, and had so many browser-based usability woes that it got ashcanned without ceremony.
The ports I've done was a port of a VB6 application to .NET. I had written both, so I was thoroughly familiar with what needed to be done. However, I also wanted to add a bunch of features, which increased the size of the .NET program to about 50% beyond that of the VB6 version, and maybe more. Because of my familiarity with the program, this went about as Sittens first example went: Fast and smooth.
The second program was re-creating a VB6 application in .NET where the source code didn't exist any longer and I hadn't been involved with it. That took a bit longer. I had to study the existing program to see what it was doing for each control, and how it was impacting the database. There were a few fields in the DB that didn't seem to serve any purpose that I could think of and which never changed. If those fields weren't vestigial, the resulting program didn't match what the old program did, but it's hard to say.
Porting depends on lots of things. For one thing, as Sitten also pointed out, when you port a program you tend to start with the assumption that the program you are porting is good (or else why bother?). A few bugs isn't too bad, but if there are features that exist for no known reason, that makes life difficult. Anybody who tried to port the first program I wrote at this employer, which was also written in VB6, and for which the source code was stolen over a decade back, would find features that made no sense at all, including a button that put up random puns, phrases, and limericks. There was a reason for it all back when it was written. That was just two decades back on a vastly different network topology.
Many of the vb5-6 programs I wrote for my current company have died quietly over the years. The major programs in use daily I ported over to VB.NET. Some of them took several re-writes to get right. All of those added new features where I saw improvements were possible. In short they bear very little resemblance to the original programs let alone the code driving them.
Yes porting is mostly a pain for me. Which is why I am very selective about what I do port.
Also I'm kind of thinking the major difficulty with deciding on what a new VB6 would be like is something like this:
From a syntax perspective, we've got many vibrant candidates for language features that'd be great in a non-programmer language. The pendulum could swing to the less-object-oriented VB6 and I'd be fine with it. Buy me a drink and I'd agree it might be easier to teach a newbie how to work with OOP if you first don't let them use OOP at all. Either way, I don't think this is the hurdle, though a lot of people like to get hung up on it, me included.
But there's a million languages out there that make it drop-dead easy to write a console program. What really made VB6 kick major butt was how easy it made developing a UI application. And we're in a real pickle in terms of UI client development.
I think part of why VB worked so well is for a brief few decades, the UI paradigm and metaphors stabilized. Color depth and screen resolutions got bigger, but most of the superficial changes to apps like shading on buttons were things you expected Windows to update for you without much hassle. Now we can't agree on aspect ratios, dot pitch, whether buttons should be shaded, etc. It's hard to present a cohesive UI framework when the expectation of "what an app looks like" shifts every 2-3 years. And there's lots of different directions we could be headed:
- The return of the Desktop.
- The return of the Desktop, except you have to use something like WPF.
- The death of the Desktop, to be replaced by web "applications" using JS bridges.
- The death of the Desktop, to be replaced by cross-platform application frameworks like Xamarin's.
- The death of the Desktop, to be replaced by a platform that transcends hardware like UWP.
- The death of Windows, leaving web/x-platform/a new platform dominant.
- VR/AR destroys the concept of 'a monitor'.
Some of those are a lot more likely than others. But each requires a VB that looks a little different, or has a different kind of toolkit.
The best "new VB" will be the absolute best way to write a GUI application. Right now I don't know which of 2 or 3 of the options above will come out on top. If the industry can't settle on a UI paradigm, there's really not a way for a "new VB" to assert its role.
Yep, I call those "dark world" programming languages.Quote:
Originally Posted by Sitten Spynne
Their tooling tends to be very dismal as well, forcing GUI development into tedious sessions of hacking markup like a Web Secretary or something. Their idea of an IDE is little more than a text editor with some code-colorization and maybe autocomplete, with a menu selection to fire off a "make" script. When they do have any kind of debugger it isn't really integrated and may just be another "make then debug" menu option invoking external tools.
These are so incredibly clunky and unproductive to work with I have to roll my eyes trying to imagine how they could be popular at all. Python is one of these and how anyone can justify using it as a teaching language completely escapes me. You fuss with the primitive tooling so much you hardly have any time to focus on learning anything.
My conclusion is that an incredibly strong Anybody But Microsoft sentiment lingers among many academics. That could also explain why there are still strong pockets of people teaching based on VB6 this late in the game: VS/.Net is simply too craptastic (bloated, slow, languages encumbered with thousands of extraneous arms and legs) to deal with.
Well that was really the entire point. Try writing a Windows GUI application in plain old C or even C++ without MFC or ATL... and even with them! It required so much knowledge, was so much work, and was so unproductive... it proved a barrier to Windows adoption for line of business development.Quote:
Originally Posted by Sitten Spynne
VB came along and probably more than any other thing besides perhaps MS Office made Windows a success instead of a novelty.
Of course that did get some teeth grinding. A certain product (can you say DOS Turbo Pascal?) saw its sales plummet to nothing. So the Great Satan of Software himself decided to create a new product: Delphi (codename "VB Killer").
Nothing substantial really came of Delphi but the inferiority complex burned and burned for a decade. Old Bathless Anders finally got himself hired by Microsoft and quickly churned out VJ++, and just as quickly got Microsoft sued and they lost. So "Fire Two!" here comes .Net to try to kill VB again. That time the old Dog in the Manger finally got his way. The rest is history.
Why make things simple when you can make them complicated?
That's how american astronauts ended hitch-hiking their ride up to the ISS on a soviet firecracker and why .Net blows.
Nah, that happened because of decades of Republicans and Democrats-in-name-only pushing to dismantle the government. Now the Russian contracts are mostly being replaced by more expensive Boeing and SpaceX contracts that Wall Street makes money on.
Once again the taxpayer loses big as they shout "cut taxes" at the same time they keep on raising them. Voters are gullible fools by and large.
Omg - the NEW vb6 thread and The Donald thread have merged!
VBForums has given birth!
That or just inbreeding itself to extinction.
Don't worry, if you just hook up these compatibility hacks it'll keep working for... at least the current version.
Also I think you have a very "GUI or bust" oriented view of development, dilettante. There's plenty of programs that have no business having a GUI, and I wish .NET made them as easy as it is in those "horrible" languages. The problem isn't object-oriented programming. The problem is other languages make obscure tasks like "be an HTTP server" 3-5 lines whereas in VB I have to start with, "OK, let's open a TCP socket and listen on port 80, when I receive a connection..."
In other words, for their console-type applications, they provide VB-like simplicity. It's hard to write a GUI with them for the same reason it's difficult to bake cupcakes with a flamethrower.
for now , this idea will come true
What idea?
I think he's referring to this thread.
If I was to hazard a guess I would say spammer trying to get past the mandatory post count. Already exceeded though so preparing the ban hammer for when the spam arrives.:wave:
I disagree. I'm pretty sure he's not a spammer. Just another person hoping that somebody will write a new VB6. Seems pretty determined about it, but I also feel the enthusiasm for such a thing has faded away over the last few years.
Oh, I didn't spot that he was the OP in that linked thread. Yeah, you're probably right then.
the new vb6 , will coming soon.
my team is now writting the new C2.exe, and link.exe to the new vb6 , it will be replace the VB6 IDE .
I've heard that before, so I'll just say: I'll disbelieve it when I see it.
Actually you can already update LINK.EXE by using versions from at least the Vista SDK if not newer. I've done that. The downside is that /OPT:NOWIN98 was removed and the setting is effectively always "on" for this, so Win95/98 support is lost. It also doesn't seem to work right for DLL and OCX project types.
C2.exe is basically VC6.0's C2.dll wrapped within an EXE. I don't think it is trivially replaced by another C compiler's code generator because it has to understand VB6.EXE's generated p-code and symbol tables. You'd have to rewrite VB6.EXE's built-in incremental compiler first. That is 99% of the p-code compilation and serves as pass 1 for native compilation.
I've heard this mentioned before, and I'm curious - is there any known benefit to updating the linker? Breaking DLL/OCX compilation always made this a deal-breaker for me, but maybe there's a "killer feature" for .exe's I don't know about.Quote:
Originally Posted by dilettante
I mean, the second post-VB6 LINK.EXE (.NET 1.1, circa 2003) did add support for some neat features - like link-time code generation - but a feature like that wouldn't work on VB code anyway, since it requires cross-communication with the compiler. Is there some other improved linker behavior that makes a newer LINK.EXE worth the trouble?
I had used it for a while because it created smaller linked binaries. However this turned out to be entirely due to the NOWIN98 switch's default value changing.
Since you can set that switch via a small tweak to your VBP file there is probably nothing left to be gained from it aside from any possible bug fixes we have no way to know about.
Example:
Code:[VBCompiler]
LinkSwitches=/OPT:NOWIN98
Interesting. How did I miss it breaking DLL/OCX compilation? I've been using DLL's with an updated link (VS 2010) for some time.
And didn't notice they were broken.
I think I'll happily go back to the VB6 LINK, with the NOWIN98 switch.
Good to read this old thread from the beginning, review and realise how wrong the majority of contributors were...
You read the whole thing:eek:
I have no desire to read all those pages of posts, but I did go back and read the first couple pages. I wouldn't say that anybody was wrong, exactly. People seemed pretty much right as far as anybody could predict the future. Now, ten years later, it seems like the same arguments could be recycled without major changes. Some people would answer "TwinBasic" in a bunch of places, but overall things could be about the same.