Hi all
Will VB6 IDE work well under WIN7 os ?
If yes, will the enduserapp.exe that was developed by that VB6 under win7 os work well
under win7/8/10 os ?
Thanks in advance
Elico
Printable View
Hi all
Will VB6 IDE work well under WIN7 os ?
If yes, will the enduserapp.exe that was developed by that VB6 under win7 os work well
under win7/8/10 os ?
Thanks in advance
Elico
Yes, the IDE (VB6.exe) will work under Win7 (when you run it with Administrator-privileges).Quote:
Originally Posted by elico
VB6.exe does not only provide the IDE - it does also provide a compiler-frontend.Quote:
Originally Posted by elico
VB6-Apps which are compiled with it, will run on Vista/7/8/10 without problems -
even when you compile your "enduserapp.exe" on an XP-system.
One just has to take care about proper placement of certain files,
which ship with your enduser-executable (as e.g. a Database- or other
files which would require FileSystem-write-access) ...
Putting "everything into the \Programs\ directory" would be the
wrong way to go about it.
Olaf
Quote:
Originally Posted by Schmidt
I am talking about database programs only as enduserapp.exe , what additional files I have to add
, I intend to use Sqlite server, and where to place them on user pc ?
Elico
I've used vb6 under win7 and it ran fine for me, you might want to "Disable desktop composition" in the Compatibility tab (right click on shortcut/executable). For some reason dragging the "Immidiate" window would be very sluggish if didn't disable that setting.
Technically, you do not place any files. You would build a deployment package, i.e., setup.exe, and the setup would install the needed dependencies (dlls, ocxs, etc).Quote:
Originally Posted by elico
There is no "Sqlite server" so it is very hard to know what you are asking.Quote:
Originally Posted by elico
If you mean SQLite which is a file-based database technology (there is no "server" in the usual client/server sense) it gets even more complicated because this beast gets packaged up in many different ways by different people. So even saying "SQLite" doesn't tell anyone much since the many ways this stuff has been compiled and linked into wrapper DLLs seems almost without limit.
If you mean something else then you'd need to tell us. If you are as much of a novice as you sound you should avoid the complexity and pitfalls of SQLite like the plague unless you have some compelling need for it. If you are having language barrier problems then perhaps you can try providing more explanation and maybe we can work out what you mean.
Yes I will try better now .
My intention is to buils simple database programs for sale.
I am talking about database apps like datbase for stamp collectors , coin collectors and alike.
Since those apps nees SQL functionality for filtering and showing just the relevant records at run time .
I try to understand what SQL engine I need to include at design time.
And also my main dilemma is if I need to add some SQL related files to the enduserapp.exe file when deployed on user pc , or maybe that enduserapp.exe will include that sql related files.
Also how that "deployment package" is built exactly , does VB6 include such functionality ?
I hope I made myself clear now.
Many thanks
Elico
You can probably get by just fine using Jet 4.0, which is part of Windows and has been for a very long time. Even if your users have just installed a fresh copy of Windows 95 onto a computer it can be added there easily. But anything newer should already have it, certainly anything currently supported by Microsoft. So basically you don't need to deploy any of that except in unusual cases.
Packaging and deployment can be a huge topic in itself and get nearly as complex as programming itself.
When VS6 & VB6 shipped the new Windows Installer technology was not ready yet. So they decided to include one of the old legacy scrpted installer technologies used with prior versions of VB: the Package and Deployment Wizard (PDW). The PDW is still "good enough" for most simple programs, but the world has changed a lot since 1998. So using it requires a bit more knowledge than in 1998 bcause things the PDW has been "told to" package and deploy either don't need to be deployed or can't safely be deployed anymore.
Since the vast majority of casual VB6 programmers are clueless Windows will try to help. It has gotten far better over the years at defending itself from misdeployment of items which have become system components since 1998. This lets quite a few faulty legacy setups still work in spite of being incorrect now.
You can help the PDW but doing the job right means you have to know a great deal about what has changed since 1998. One thing you can easily do is to manually exclude certain items every time you use the PDW to define a new setup package: MDAC_TYP.EXE, any VCRTxxx.DLL, and the "VB6 Runtime and OLE Automation" bundle. Early in the Wizard's steps it lists these for you with checkboxes and you simply uncheck those boxes.
That hits the highlights, but there are other things to watch out for too. This just isn't something a reply here and cover in depth. Sadly there is a lot of incorrect or misleading information about this on the web too, which makes things that much tougher.
Along with these raw basics you have to consider the impact of UAC now which forces people to pay attention to security boundaries. You may have been able to ignore these on Win9x systems and pre-UAC WinNT systems by making sure users all logged on with admin rights.
Of course your program may use things supplied with VB6 that are not part of Windows. These need to be packaged as well. Most of these will be control libraries (normally .OCX files, but some require supporting .DLL files too). Most of the ones that came with VB6 are convered within this writeup:
Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, Windows 8 and Windows 8.1, Windows Server 2012, and Windows 10
Most importantly:
Are you sure you are using VB6?
It isn't cheap or easy to come by legally anymore. This makes me wonder if you are not using one of the many versions of the misleadingly named and unrelated VB.Net products instead.
Many thanks
Are there some deployment software tools that will automate the deployment for VB6 based apps ?
Elico
Schmidt - What do you mean by a 'bad idea'? I am writing a program now that will read/write text files in a directory under the App directory. e.g. App.Path /txtFiles
Is this not good?
I think that he meant only on the root of the App directory. You should have there folders like that which will separate programs' files from the others, and prevent polluting by grouping all of them.Quote:
Originally Posted by meopilite
MikiSoft pointed it out already - I meant "the placement of your Enduser-Apps "Root-Directory"...Quote:
Originally Posted by meopilite
If you want to deploy your stuff as a "portable App" (perhaps with some Installer-like actions
which take place at the first start of your EndUser-app executable), then you should take care,
where the EndUser has placed the Root-Folder of such a portable App.
Placing the Root-Folder behind the Win-OS' \Programs\ (or \Programs x86\) Folder, would
be a bad idea, since SubFolders below this special System-Folder (as your EnduserApp-Directory)
don't have full "File-Write-access" there (you will then run into all kind of issues - as e.g. from
FileVirtualization on the newer OSes above XP).
Olaf
What about SQLitening ... work very well on vb6.Quote:
Originally Posted by dilettante
http://www.sqlitening.com/
JFYI...Quote:
Originally Posted by cliv
A *much* better performing alternative to SQLitening would be the RPC-support
which is built into vbRichClient5.
One can set-up a VB6-ServerHost-application with only a few lines of VB6-code -
and then perform SQL-requests against this Server-App (over sockets, across
machine boundaries) with much better performance and comfort.
The Query-results can either be delivered as disconnected Recordset-Objects -
which are then updatable at the clientside (with Rs.AddNew, Rs.Delete, Rs.Updates)
and then send back to the serverside, performing an UpdateBatch there -
or alternatively one can transport JSON-Resultsets directly too (in case the Client-
App is a WebBrowser - or a WebBrowser-Control).
In case you want to experiment with it (e.g. doing your own comparisons to SQLitening),
I've explained the usage of the RPC-classes here:
http://www.vbforums.com/showthread.p...ent-per-RC5%29
Olaf
This FAQ might be helpful too:
Classic VB - Where should I store the files that my program uses/creates?
...and where are Attachment file?...link is invalidQuote:
Originally Posted by Schmidt
Oops, sorry - the link in the article on:Quote:
Originally Posted by cliv
http://www.vbforums.com/showthread.p...ent-per-RC5%29
is fixed now (SimpleRPC.zip)...
It currently contains transfers for (disconnected) ADO/JET-Recordsets -
let me know, when you need serverside code for disconnected SQLite-Rs-
transfers - could provide a small Demo for that scenario as well...
Olaf