|
Philip Laureano wrote: Has anyone else ever run into this scenario?
MFC?
|
|
|
|
|
J2SE?
I kid, I kid! 
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means? 
|
|
|
|
|
Naw, he mentioned "nicely structured".
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
STL? ATL? COM? DCOM? ... 
|
|
|
|
|
Nope! But my first professional programming job was to write an application in less than 2 weeks, because the previous programmer, who was writing it in assembly over a 6 month period, left the company along with all the code. I brought in my libraries, QuickC compiler, and wrote it in C, it worked well given the time frame.
I occasionally write code generators, but only when it is required to eliminate wasting my time by having to hand code something that can be automated. Point, click, verify, and generate. That way a non-programmer can handle the creation, and I only have to verify it, before and after the code generation.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Actually, yes!
In my college days, I was taking an AI class and one of my fellow students got around a language requirement for one assignment by writing a LISP interpreter in Prolog just so he could do the actual assignment in LISP (or maybe the other way around, I don't remember -- that was almost 20 years ago)
|
|
|
|
|
Probably PROLOG interpreter for LISP: the reverse would be extremely difficult. A number of these have been made. The best Common LISP implementation around is AllegroCL (still among the most powerful platforms, esp. with its unmatched AllegroCache). AllegroCL has an extension called AllegroPROLOG, which is implemented on top of AllegroCL in such a way that the programmer can mix LISP and PROLOG code freely, while the PROLOG code is compiled into LISP code and integrated properly. Pretty nice for certain applications, notably Artificial Intelligence, for which AllegroCL is probably best.
-Nick P.
|
|
|
|
|
Reminds me of a job I did MANY years ago (when I was a fresh out of college 'grammer). Of course, my reasons were actually legitimate.
We were using Turbo Pascal (TP3 I think, but not sure, circa 1986) to develop the project and I discovered that TPs keyboard interrupt routine would occassionally drop characters if you typed fast enough. So, I wrote a new keyboard interrupt routine in 8086 assembler, hand assembled it, and put it in as inline binary code (TP had a way to do that). Worked like a charm.
|
|
|
|
|
the handler used by the IDE or the one used by applications it built? I used TP6/7 in HS during the mid/late 90s. I never noticed a problem in the IDE, and IIRC apps built in it used the DOS handler by default. OTOH I'd replaced the one for DOS with a 255 char buffer instead of the paltry dozenish MSes used. For most of my larger apps I used a custom handler that supported multiple simultaneous key presses. I grabbed the ASM for both off the web though instead of writing my own.
--
If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
|
|
|
|
|
The one used by the apps it built... And the buffer was the problem. Boy is thi staking me back to that project 20+ years ago...
I was a new developer and just knew that I needed to rapidly catch the keystrokes for processing. There weren't any standard "input" type fields on the application as it was a real time graphing system for statistical process control that processed data coming in through the keyboard buffer from various data-collection devices. Being a public/purchased application, we couldn't guarantee the devices would be configured with 40ms delays between simulated keystrokes. This was in the day when user's who bought the software put requirements on the software, not the other way around.
There were several modules to the application.
One was the device interface which would capture the input and push it into the keyboard buffer. The requirement was that the floor users had to be able to upload this data as fast as possible as well as be able to do near real-time input from the collection devices.
The second module also ran in the background and collected that data from the keyboard buffer and wrote it to the datastore (a custom designed fixed-length flat file system with a unique indexing algorithm written by the senior developer). He was having a hard time with the buffer overflowing on large uploads and losing data, so he asked me to research alternatives. I came up with a cheap custome keyboard handler with a large (8K I think) buffer which would hold everything the largest device we supported at the time. At the same time, it sped up the processing of the data as the TP-based keyboard handler would type into a text field at a very slow paste. I could type 70 WPM at the time and I could make the simplest input field drop characters.
The third and final part would continually update the various control graphs from the flat files. I did plenty with that eventually as well, but that's another topic.
This was 1986 and the PC/AT was the latest and greatest thing. Windows 286 wasn't even dreamed of (much less 3.0, 3.1, Workgroups, or the future OSs) and the Mac was viewed as a "toy" for graphics designers and the like, not a serious machine for floor production systems. Instead, factory floors had ultradurable (and super-expensive for their day) PC or XT 8086/8088 based computers from Compaq or IBM. In short, creative "get it done" solutions that could do things quicker and with little overhead were the best. I think the assembler code took less than 1K so the whole thing was under 9K and our entire package could run on a 512K XT very reliably.
-Draugnar
|
|
|
|
|
Draugnar wrote: I think the assembler code took less than 1K so the whole thing was under 9K and our entire package could run on a 512K XT very reliably.
The handler or the application? IIRC the big buffer handler I'd used took less than 1k ram. I actually have the HD from my 486 sitting around somewhere, unless it suffered bitrot over the last few years I could probably still boot it if I actually wanted to.
--
If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
|
|
|
|
|
The handler module took 1K on disc and 9K in memory (adding in the 8K for the buffer). The whole application took significantly more (it's been 20+ years and my memory fades now that I'm in my 40s), but still ran on the 512K XTs that had been spec'd by our beta client (who got the final app at a greatly reduced price over the later retail clients).
-Draugnar
|
|
|
|
|
The most interesting part of the project was the hand assembling. The Microsoft assembler put in header info for the linker that I didn't want as it was going in as inline binary, so I sat down with the 8086 Assembly manual and hand assembled it so I had just the code used by the routine. Having taken C+ (not C++) and 360/370 Assembler in college sure made that job a lot easier.
|
|
|
|
|
|
leppie wrote: I have been given a VB6 project to upgrade to C#
Bah, that's nothing. Or null. Or empty. 
[ My Blog] "Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn "Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
|
|
|
|
|
Surely this is better than being given a C# app to downgrade to VB6? And better than being given a VB 6 to maintain.
|
|
|
|
|
Better that than the other way round
|
|
|
|
|
That's was a pretty big typo there ^^
Nice Rule btw
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
leppie wrote: - 400 Upgrade warnings
- 100 Compiler errors
- 2 Missing dll references...
Wouldn't such a mammoth statistics suggest going for a fresh VB.NET development rather?
|
|
|
|
|
I think the application has less lines of code than errors, so yes I am pushing for a fresh C# app 
xacc.ide
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
|
|
|
|
|
leppie wrote: so yes I am pushing for a fresh C# app
Good Move! Rather than suffering sick with the horrible VB! 
|
|
|
|
|
leppie wrote: - 400 Upgrade warnings
- 100 Compiler errors
- 2 Missing dll references...
I don't understand how this can be classified as a "coding horror". If you copy VB6 code into a VB.NET (or C#) project and compile it, I am supprised that you did not get more warnings and errors. As we developers know, one syntax error or misspelling could cause tens or hundreds of other errors, which means when you fix one, the others will disappear, too.
Coding Horror implies that someone wrote horrible code. In this case, who that someone would be? The VB6 programmer or you?
|
|
|
|
|
Xiangyang Liu wrote: Coding Horror implies that someone wrote horrible code
Or that someone is experience a horror
Xiangyang Liu wrote: If you copy VB6 code into a VB.NET
It was not copy. I used the converter in VS2005, which does a pretty good job, most of the forms actually open in the designer Most of the issues seem to be related to either missing libraries and interop stuff. The ActiveX bits and WinForms converted very well.
xacc.ide
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
|
|
|
|
|
VB6 -> C# ... Does the converter fix all the optional parameters from the VB6 code? I've never used it myself  .
If not you'll likely have a bunch of Type.Missing's to add
|
|
|
|
|
Don't forget that most of those warnings will be in the form of, "this function doesn't exist anymore. You've got to write your own" types of warnings.
Deja View - the feeling that you've seen this post before.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
