Most graphic Google logo to date
-
:laugh: I actually am finishing up a project in VB6/assembly (don't ask). X|
BW
If you're not part of the solution, you're part of the precipitate.
-- Steven WrightActually, this harkens back to the early days of micro-computing. (i.e. pre-IBM PC) On many early computers, a BASIC program often called machine language subroutines. This was done in the interest of speed as processor speeds were 1 or 2 Mhz. Of course, all REAL software at this time was written in assembler/machine language. The example I am most familiar with was the old Apple II. No Applesoft Basic program, which was written by Micro$oft, that did even remotely useful work used peeks, pokes, and calls to access memory directly and call machine language code directly. As an aside, not noting this coding practice was one of the many reasons that the Coleco Adam computer failed. The Adam used a basic that was "compatible" with Applesoft basic. However, the machine was not an Apple II clone. It didn't even use the same kind of processor! (Apple - 6502, Adam - Z80) Therefore all but the simplest (i.e. Hello, world!) programs designed for the Apple II would work on the Adam. Anyway, as processor speeds increased, we got away from that when the C/C++, TurboPascal, and the first Visual Basic compilers/interpreters arrived. But, in another sense, we never left. Anytime we use code from another DLL (Windows) or library (*nix) we are calling machine or intermediate code. The main difference is that the DLL/library being called is rarely coded in assembly nowadays.
Andrew C. Eisenberg Nashville, TN, USA (a.k.a. Music City USA) (Yes Virginia, there are rock and roll stations in Nashville! :laugh:)
-
It depicts the immense inner suffering of a typical C++ programmer forced to get familiar with VB !
brianwelsch wrote:
It's oddly comforting at work.
Which language are you developing with ? :-) Marius
--------------------------------------------------------- Complete freedom is a state without context ---------------------------------------------------------
I did some VBScripting today (automated testing of my C++ software - so no, I've not gone totally berzerk). I can totally relate to the scream guy...
-- Please rise for the Futurama theme song
-
:laugh: I actually am finishing up a project in VB6/assembly (don't ask). X|
BW
If you're not part of the solution, you're part of the precipitate.
-- Steven WrightVB + As*embler sure is an interesting combination. May I ask what the software does?
-- Bender's humor by Microsoft Joke
-
VB + As*embler sure is an interesting combination. May I ask what the software does?
-- Bender's humor by Microsoft Joke
I work on a POS system. Currently, it still sells as a character-based front-end written in assembler (our products have been around for decades). A few of our other products have recently been retrofitted with a shiny new VB front-end, and so it's the POS system's time. Someone wrote a C middle-layer to handle the data between VB and our assembler back-end. It's actually kind of neat from an academic point of view, but there are a lot of headaches involved with attaching a front-end to a system that was not developed for it. Some of the back-end code I deal with was written in the late 80s and has been haphazardly maintained since then. We also have to maintain backwards compatibility since the product will sold for a period of time essentially as it stands today or with an optional GUI.
BW
If you're not part of the solution, you're part of the precipitate.
-- Steven Wright -
I work on a POS system. Currently, it still sells as a character-based front-end written in assembler (our products have been around for decades). A few of our other products have recently been retrofitted with a shiny new VB front-end, and so it's the POS system's time. Someone wrote a C middle-layer to handle the data between VB and our assembler back-end. It's actually kind of neat from an academic point of view, but there are a lot of headaches involved with attaching a front-end to a system that was not developed for it. Some of the back-end code I deal with was written in the late 80s and has been haphazardly maintained since then. We also have to maintain backwards compatibility since the product will sold for a period of time essentially as it stands today or with an optional GUI.
BW
If you're not part of the solution, you're part of the precipitate.
-- Steven WrightHmm.. I think I'm getting senile. I think I've asked you this question before. Sorry if I seem absent minded. (I am! :-D)
brianwelsch wrote:
We also have to maintain backwards compatibility
:sigh: I know what you mean. I too am writing POS software for a living, and I have to keep in sync with other software which deals with the accounting stuff. The edge with our system is that all POS sales are synchronized with the customer's stock and accounting in real time. It's a friggin nightmare everytime the other vendor updates their software, because then I have to figure out the differences between the revisions. Not a biggy because we've developed tools to automate that process (database diff basically). We also have to keep backwards compatibility with older versions of the other vendor's software, because not all customers upgrade. I have yet to write any assembler (although, I have been known to perform black DB-driver voodoo by patching a database driver's collation tables (which, despite the DB-driver vendor's claim, wasn't collating Swedish properly), which involved a fair amount of trickery).
-- Now with chucklelin
-
Hmm.. I think I'm getting senile. I think I've asked you this question before. Sorry if I seem absent minded. (I am! :-D)
brianwelsch wrote:
We also have to maintain backwards compatibility
:sigh: I know what you mean. I too am writing POS software for a living, and I have to keep in sync with other software which deals with the accounting stuff. The edge with our system is that all POS sales are synchronized with the customer's stock and accounting in real time. It's a friggin nightmare everytime the other vendor updates their software, because then I have to figure out the differences between the revisions. Not a biggy because we've developed tools to automate that process (database diff basically). We also have to keep backwards compatibility with older versions of the other vendor's software, because not all customers upgrade. I have yet to write any assembler (although, I have been known to perform black DB-driver voodoo by patching a database driver's collation tables (which, despite the DB-driver vendor's claim, wasn't collating Swedish properly), which involved a fair amount of trickery).
-- Now with chucklelin
I may have explained the setup before, who knows? One benefit, sort of, is that we write everything in-house. That includes the accounting side, hardware drivers for the registers, reporting, inventory, etc. So we can control the release of changes much better. The major headache with 3rd party vendors at the moment is credit card processing, but I'm not directly involved with that, thankfully. The silver lining for me is coming up soon. I'm bowing out of the POS product and taking on a number of outlying tasks. I'll be the sole developer for two in-house IDEs, keeper of various build machines, PVCS admin, and InstallShield guru. That'll get me out of the assembler and back into C++, so I'm looking forward to that. I like having a variety of different tasks to do, it keeps things interesting.
BW
If you're not part of the solution, you're part of the precipitate.
-- Steven Wright -
It depicts the immense inner suffering of a typical C++ programmer forced to get familiar with VB !
brianwelsch wrote:
It's oddly comforting at work.
Which language are you developing with ? :-) Marius
--------------------------------------------------------- Complete freedom is a state without context ---------------------------------------------------------
marius_romanus wrote:
inner suffering of a typical C++ programmer forced to get familiar with VB
The picture that comes to mind for me is that of a Viking drowning in a huge vat of banana pudding.
Software Zen:
delete this; -
It depicts the immense inner suffering of a typical C++ programmer forced to get familiar with VB !
brianwelsch wrote:
It's oddly comforting at work.
Which language are you developing with ? :-) Marius
--------------------------------------------------------- Complete freedom is a state without context ---------------------------------------------------------
marius_romanus wrote:
Which language are you developing with
Black magic voodoo, yea I'm trying to communicate with management. :laugh: :rolleyes:
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
-
I may have explained the setup before, who knows? One benefit, sort of, is that we write everything in-house. That includes the accounting side, hardware drivers for the registers, reporting, inventory, etc. So we can control the release of changes much better. The major headache with 3rd party vendors at the moment is credit card processing, but I'm not directly involved with that, thankfully. The silver lining for me is coming up soon. I'm bowing out of the POS product and taking on a number of outlying tasks. I'll be the sole developer for two in-house IDEs, keeper of various build machines, PVCS admin, and InstallShield guru. That'll get me out of the assembler and back into C++, so I'm looking forward to that. I like having a variety of different tasks to do, it keeps things interesting.
BW
If you're not part of the solution, you're part of the precipitate.
-- Steven Wrightbrianwelsch wrote:
The major headache with 3rd party vendors at the moment is credit card processing, but I'm not directly involved with that, thankfully.
Tell me about it. :sigh: I'm particularly fond of one of our CC processing 3rd party, who keeps changing the communication protocol without letting everybody else know about it. I also love how their proxy software sometimes "forgets" to forward the response back to our app. What bothers me most is that the end customers aren't aware of the fact that it's not my fault.
brianwelsch wrote:
InstallShield guru
You might not be so happy about this one in the end... But if it's variation you want, then variation is what you'll get.. :-D
-- Verletzen zerfetzen zersetzen zerstören Doch es darf nicht mir gehören Ich muss zerstören
-
brianwelsch wrote:
The major headache with 3rd party vendors at the moment is credit card processing, but I'm not directly involved with that, thankfully.
Tell me about it. :sigh: I'm particularly fond of one of our CC processing 3rd party, who keeps changing the communication protocol without letting everybody else know about it. I also love how their proxy software sometimes "forgets" to forward the response back to our app. What bothers me most is that the end customers aren't aware of the fact that it's not my fault.
brianwelsch wrote:
InstallShield guru
You might not be so happy about this one in the end... But if it's variation you want, then variation is what you'll get.. :-D
-- Verletzen zerfetzen zersetzen zerstören Doch es darf nicht mir gehören Ich muss zerstören
Joergen Sigvardsson wrote:
What bothers me most is that the end customers aren't aware of the fact that it's not my fault.
No kidding. :sigh: I've just started getting into the Installshield gig and have helped a few sites troubleshoot installs. So far it's usually been an issue with user rights, but I'm sure it always feels like the install process is to blame. You might be right about my not liking IS :rolleyes:, but it's a new challenge.
BW
If you're not part of the solution, you're part of the precipitate.
-- Steven Wright