|
Ideas and suggestions please
Hi,
I am in the process of doing a requiments definition for a new project and I was hoping to get some technology ideas from y'all. The deliverable is a Windows based application that interacts with some proprietary hardware via a COM port. There is a current application, that we will be replacing, written in MSVC++ with MFC and I believe that the application uses a threaded architecture. I am currently analyzing different tools to build this application as well as defining the functional requirements of the app.
My background is in developing traditional Win32 Client/Server applicaitons using VB6 and SQL Server.
Now the biggest stumbling block is that that application needs to be a threaded solution. IMO, this leaves VB6 out because of its inability to create a threaded app. I am evaluating different types of environments and I have come up with either C++ or Delphi or Java.
Can you offer some ideas or suggestions and maybe something that I haven't thought of. BTW, I really like the VB6 IDE and was hoping to use something similar, like C++Builder from Borland. I have a problem wrapping my head around the traditional C++ Win32 GUI development.
Thanks,
Kevin
Kevin Moore
Tuesday, January 13, 2004
VB can be used to create applications that support multiple threads, but it's not particularly straightforward (last time I tried, creating the thread would crash the IDE but if you run the program outside of the IDE, the thread runs fine).
On the other hand you might use something like C++, Delphi, etc to make the back-end system (com port session handler or whatever it is) into which you'll call with VB (this is much more straightforward and simple -- especially with Delphi and its much simpler support for COM than MS VC++).
You're probably better off going with something that you're pretty familiar with, whatever that is. On the other hand, if there's a different tool than you're comfortable with that will allow you to maximize the use of the previous work on this project (if that previous work isn't defective), then you probably should go with that.
K
Tuesday, January 13, 2004
Not a whole lot to go on there, Kevin.
Who is the application targetted at? Highly technical audience, or folks at home via shrinkwrap box?
What's the overall balanace of the application's work? Small amount of device interaction, incredibly rich GUI, or a huge amount of device interaction with a small amount of GUI work, or somewhere inbetween?
How many installations will there be? One or two specific inhouse users that you can easily work with, or many installations far and wide that you can't trivially update when you need to?
Use of threading -vs- asynchronous I/O is probably not the most important decision to make this early in the process. It's certainly one of them, but I suspect there's a bunch of other forces to consider as well.
Andrew Lighten
Tuesday, January 13, 2004
Kevin,
Is using .NET out of the question? It requires the Framework to be installed and that still doesn't have very wide coverage, even though it can be installed with your app. I only mention it because going from VB6 to VB.NET might be a bit easier than going from VB6 to C++.
I'm not a huge fan of Delphi, but I believe that has the ability to build multi-threaded apps and it doesn't look too difficult to master.
If you've never done Win32 C++ development then jumping into an application that is multi-threaded is likely to make your head swim at first, so make sure you study up on the basics of multithreading and the myriad of problems it brings.
Mark Hoffman
Tuesday, January 13, 2004
You can achieve multi-threading with VB6 COM components by running them in MTS (Microsoft Transaction Server). However, you have to follow some pretty specific guidelines when you code your COM components in order to make them thread-safe or you'll get a crapload of intermittant, inconsistant, and hard-to-reproduce crashes. Essentially, you need to make your components *stateless*... no global or static vars. Each function must not rely upon any state within the component... only the variables local to that function. Global constants are OK. Wrox publish(ed) book specifically dealing with VB6 COM components in MTS; I'm sure there are/were others.
At my old job we had pretty good results once we got the hang of it... figuring out how to keep the components threadsafe was a real ball-buster at first but easy once we got the hang of it. One tip: MTS does NOT like to release the COM components... so get used to the lengthy remove COM component from MTS/shut down MTS/unregister COM component/compile or register new COM component/restart MTS/re-add new version of COM component to MTS cycle each time you re-compile. And you'll want to use ProcessExplorer or some other utility (not TaskMan) to kill components sometimes, because MTS doesn't always release things even when it's dead.
Perhaps the most appealing option would be VB.Net, which allows for multithreading. I'm not sure about the specifics of achieving multithreading in VB.Net but the language itself should be a snap for you compared to VC6, and I'm sure that achieving multithreading in .NET is a lot simpler than it is with VB6+MTS.
John Rose
Tuesday, January 13, 2004
I'm curious--why is the current app being replaced? Is it garbage? Or should you build on top of the existing app?
Rob Warner
Tuesday, January 13, 2004
"Now the biggest stumbling block is that that application needs to be a threaded solution"
Does it? Just because the previous one used threads doesn't necessarily mean the replacement must. What alternatives to threads have you considered?
Tom H
Tuesday, January 13, 2004
 Recent Topics
Fog Creek Home
| 
