Visual Basic, Stand-Alone EXE File

Stand-Alone EXE File

Author	Message
Randy Barro #1 / 24	Stand-Alone EXE File Quote: > Background: I'm moving a number of QBasic/ProBasic programs into VB > (using v4.0 Professional Edition, yeah, I know, it's old). Most are > batch processes on text files so the real effect is just a prettier > reporting screen for counts. :-) > In the QB environment there's a choice of making an EXE that requires > the BRUN module, or of bundling the BRUN into the EXE so the EXE can > stand alone (and run on a machine that might not have the BRUN > module). > It doesn't seem that VB can make a stand-alone EXE. Is that corect? > (I hope not.) Hi John- Welcome to Windows! No standalones in VB. No "little" .EXE files. All the support DLLs and assorted support files mean all your apps have to play well with others. I've yet to do anything that will fit on less than 2 diskettes when packaged for distribution. Of course, I think I read somewhere that the new Windows ME won't even run DOS apps (or something to that effect)... ;-( Later, Randy Barrow -- ============================================== Please remove NOSPAM from address for replies ==============================================
Wed, 18 Jun 1902 08:00:00 GMT

Stormdev Software Developmen #2 / 24	Stand-Alone EXE File John, Unfortunately Visual Basic cannot build standalone executables, it is both a compiled and interpreted language and requires runtime support files... Regards, Jonathan Roach - CEO Stormdev Software Development Quote: > Background: I'm moving a number of QBasic/ProBasic programs into VB > (using v4.0 Professional Edition, yeah, I know, it's old). Most are > batch processes on text files so the real effect is just a prettier > reporting screen for counts. :-) > In the QB environment there's a choice of making an EXE that requires > the BRUN module, or of bundling the BRUN into the EXE so the EXE can > stand alone (and run on a machine that might not have the BRUN > module). > It doesn't seem that VB can make a stand-alone EXE. Is that corect? > (I hope not.) > Thanks in advance for any assisstance. > John Baltimore
Wed, 18 Jun 1902 08:00:00 GMT

th.. #3 / 24	Stand-Alone EXE File Background: I'm moving a number of QBasic/ProBasic programs into VB (using v4.0 Professional Edition, yeah, I know, it's old). Most are batch processes on text files so the real effect is just a prettier reporting screen for counts. :-) In the QB environment there's a choice of making an EXE that requires the BRUN module, or of bundling the BRUN into the EXE so the EXE can stand alone (and run on a machine that might not have the BRUN module). It doesn't seem that VB can make a stand-alone EXE. Is that corect? (I hope not.) Thanks in advance for any assisstance. John Baltimore
Sun, 18 May 2003 11:37:08 GMT

Doug Ros #4 / 24	Stand-Alone EXE File Quote: > Welcome to Windows! No standalones in VB. No "little" .EXE files. All > the support DLLs and assorted support files mean all your apps have to > play well with others. I've yet to do anything that will fit on less > than 2 diskettes when packaged for distribution. Yeah, no standalone EXEs in VB. It is possible to do with C or something if you only use the core APIs that exist in the system DLLs, but not VB. Quote: > Of course, I think I read somewhere that the new Windows ME won't even > run DOS apps (or something to that effect)... ;-( I think it still does DOS. The whole Win9x architecture was "based on DOS" (I've never really understood what the hell that ACTUALLY means - just what is remnant from DOS in Win9x?). I think what throws people is there is apparently no DOS shortcut created in the Start menu by default. Command.com is still there though as far as I know.
Sun, 18 May 2003 12:16:55 GMT

emun.. #5 / 24	Stand-Alone EXE File That is correct: Visual Basic for Windows is incapable of making standalone EXEs. This has long been a sore spot for VB developers and there is no indication that this will change in the near future. - Jim Quote: > Background: I'm moving a number of QBasic/ProBasic programs into VB > (using v4.0 Professional Edition, yeah, I know, it's old). Most are > batch processes on text files so the real effect is just a prettier > reporting screen for counts. :-) > In the QB environment there's a choice of making an EXE that requires > the BRUN module, or of bundling the BRUN into the EXE so the EXE can > stand alone (and run on a machine that might not have the BRUN > module). > It doesn't seem that VB can make a stand-alone EXE. Is that corect? > (I hope not.) > Thanks in advance for any assisstance. > John Baltimore Sent via Deja.com http://www.deja.com/ Before you buy.
Sun, 18 May 2003 12:28:47 GMT

John Keysto #6 / 24	Stand-Alone EXE File Hi, I believe that you are mixing apples and oranges. VB uses dynamic linking, rather than static linking, but this has nothing to do per se with compiled vs. interpreted. As I understand it, the .exe files produced by VB and the DLLs whose functionality it uses are all compiled, not interpreted. John............... Quote: > John, > Unfortunately Visual Basic cannot build standalone executables, > it is both a compiled and interpreted language and requires runtime > support files... > Regards, > Jonathan Roach - CEO Stormdev Software Development > > Background: I'm moving a number of QBasic/ProBasic programs into VB > > (using v4.0 Professional Edition, yeah, I know, it's old). Most are > > batch processes on text files so the real effect is just a prettier > > reporting screen for counts. :-) > > In the QB environment there's a choice of making an EXE that requires > > the BRUN module, or of bundling the BRUN into the EXE so the EXE can > > stand alone (and run on a machine that might not have the BRUN > > module). > > It doesn't seem that VB can make a stand-alone EXE. Is that corect? > > (I hope not.) > > Thanks in advance for any assisstance. > > John Baltimore
Sun, 18 May 2003 13:46:54 GMT

Bert Byfiel #7 / 24	Stand-Alone EXE File Quote: >Unfortunately Visual Basic cannot build standalone executables, >it is both a compiled and interpreted language and requires runtime >support files... Microsoft is like that. They don't want us getting too independent. Caravela Books 134 Goodburlet Road Henrietta, NY 14467 http://caravelabooks.com
Sun, 18 May 2003 14:24:34 GMT

Doug Ros #8 / 24	Stand-Alone EXE File My understanding is that VB5+ can compile to native code or p-code. Native code is just that - regular x86 machine code. This code doesn't need an interpreter, but I believe p-code does, which is the other compile option. In either case the code requires the runtime DLLs because that's where the functionality of VB lies (InStr, Val, etc) and also to implement OLE automation and stuff. I believe the VB runtime DLL also contains the p-code interpreter. Why p-code? The difference is the classic speed/size tradeoff. Native code runs faster but takes more space. P-code runs slower but is much smaller. Did I miss something? Am I leading everyone astray? - Doug Quote: > Hi, > I believe that you are mixing apples and oranges. VB uses dynamic linking, rather than static Quote: > linking, but this has nothing to do per se with compiled vs. interpreted. As I understand it, > the .exe files produced by VB and the DLLs whose functionality it uses are all compiled, not > interpreted. > John............... > > John, > > Unfortunately Visual Basic cannot build standalone executables, > > it is both a compiled and interpreted language and requires runtime > > support files... > > Regards, > > Jonathan Roach - CEO Stormdev Software Development - Hide quoted text - - Show quoted text - Quote: > > > Background: I'm moving a number of QBasic/ProBasic programs into VB > > > (using v4.0 Professional Edition, yeah, I know, it's old). Most are > > > batch processes on text files so the real effect is just a prettier > > > reporting screen for counts. :-) > > > In the QB environment there's a choice of making an EXE that requires > > > the BRUN module, or of bundling the BRUN into the EXE so the EXE can > > > stand alone (and run on a machine that might not have the BRUN > > > module). > > > It doesn't seem that VB can make a stand-alone EXE. Is that corect? > > > (I hope not.) > > > Thanks in advance for any assisstance. > > > John Baltimore
Sun, 18 May 2003 14:31:29 GMT

J Fren #9 / 24	Stand-Alone EXE File ALL Windows programs rely on a massive run time support setup - these files are the core of Windows. Sure C and Delphi can produce 'Standalone' programs - but they have to stand on Windows. If you are very careful with the Controls that you use you can produce a VB5 App that just requires : MSVBVM50.dll This means not using any extended MS Controls or 3rd party controls This is no great hardship. You say you are using VB4 - JUST DON'T (yes this is a shout) Prior to VB5 - VB could not create UserControls - and these are the things that are at the core of your graphics. In my opinion VB4 is a substandard product and deserves to be thrown away. I know - I started with it - and loathe it viscerally. Also VB4 does not have AddressOf - which you will find essential for some APIs - don't kid yourself that you will not need these features. If I were you I would play around with simple controls, then charge straight into UserControls and Classes. These are the eqivalant of re-usable BASIC subroutines. Good Luck - AND DON'T WASTE TIME WITH VB4 On Wed, 29 Nov 2000 06:24:34 GMT, Bert Byfield Quote: >>Unfortunately Visual Basic cannot build standalone executables, >>it is both a compiled and interpreted language and requires runtime >>support files... >Microsoft is like that. They don't want us getting too independent. >Caravela Books >134 Goodburlet Road >Henrietta, NY 14467 >http://caravelabooks.com
Wed, 18 Jun 1902 08:00:00 GMT

Signe #10 / 24	Stand-Alone EXE File WinMe runs DOS apps just fine, same as it predecessors did. I think Win2K may not run them, but Me doesn't have a problem. -- -------------------------------- "For every action, there is an equal and opposite criticism." Quote: > > Background: I'm moving a number of QBasic/ProBasic programs into VB > > (using v4.0 Professional Edition, yeah, I know, it's old). Most are > > batch processes on text files so the real effect is just a prettier > > reporting screen for counts. :-) > > In the QB environment there's a choice of making an EXE that requires > > the BRUN module, or of bundling the BRUN into the EXE so the EXE can > > stand alone (and run on a machine that might not have the BRUN > > module). > > It doesn't seem that VB can make a stand-alone EXE. Is that corect? > > (I hope not.) > Hi John- > Welcome to Windows! No standalones in VB. No "little" .EXE files. All > the support DLLs and assorted support files mean all your apps have to > play well with others. I've yet to do anything that will fit on less > than 2 diskettes when packaged for distribution. > Of course, I think I read somewhere that the new Windows ME won't even > run DOS apps (or something to that effect)... ;-( > Later, > Randy Barrow > -- > ============================================== > Please remove NOSPAM from address for replies > ==============================================
Wed, 18 Jun 1902 08:00:00 GMT

Signe #11 / 24	Stand-Alone EXE File Quote: > My understanding is that VB5+ can compile to native code or p-code. Native > code is just that - regular x86 machine code. This code doesn't need an > interpreter, but I believe p-code does, which is the other compile option. > In either case the code requires the runtime DLLs because that's where the > functionality of VB lies (InStr, Val, etc) and also to implement OLE > automation and stuff. I believe the VB runtime DLL also contains the p-code > interpreter. > Why p-code? The difference is the classic speed/size tradeoff. Native code Quote: > runs faster but takes more space. P-code runs slower but is much smaller. > Did I miss something? Am I leading everyone astray? I think you're on target, except that I've heard many say that in their experience native code doesn't run any faster. Or if it does, the difference is unnoticeable or just in certain calculation portions of the code. I too came from a QB background, and loved compiling into a small EXE. In fact I still use some of them on occasion, where I want to call a small program to do something from my VB programs. I was shocked when I compiled my first native code VB EXE, which was bout 3 times the size of the P-code version, and found that it not only did not run noticeably faster, it still required the runtimes (which I did /not/ expect based on my QB experience - I thought that's why the EXE was so large, that it included all the stuff in there). Personally, I'm sorely disappointed where VB is going. All the stuff they're adding in VB.net has no use at all for me. My needs are really very simple, but if I were making a list of desired improvements, I would lean more toward adding the following for VB+: The ability to compile to a single EXE (no required runtimes - given the Win2K problems with runtimes, this is especially desirable). A native control that displays animated GIFs. Supported Lightweight checkboxes and other controls that have the extra properties of the unsupported lightweight controls (like Group, etc.). Resource usage on large VB projects is ridiculous. In short, native, supported controls for a lot that we have to buy 3rd party controls for. I was going to go on, but no one (MS least of all) is listening. Instead I'm told I need all these things I have no use for, and that all the code I've written and need to maintain is scrap. Looks like I'll be with VB6 for a /long/ time. -- -------------------------------- "For every action, there is an equal and opposite criticism."
Wed, 18 Jun 1902 08:00:00 GMT

J Fren #12 / 24	Stand-Alone EXE File Signet, Maybe you should take a serious look at Delphi. You can 'enhance' it to use VB like statements, and I have ported a lot of DOS utilities in Basic 7.1 straight into Delphi. If nothing else it is good for making 'Real' DLLs and doing things that you simply cannot do in VB Personally I find VB quicker for development. Quote: >Personally, I'm sorely disappointed where VB is going. All the >stuff they're adding in VB.net has no use at all for me. My >needs are really very simple, but if I were making a list of >desired improvements, I would lean more toward adding the >following for VB+: >The ability to compile to a single EXE (no required runtimes - >given the Win2K problems with runtimes, this is especially >desirable). >A native control that displays animated GIFs. >Supported Lightweight checkboxes and other controls that have >the extra properties of the unsupported lightweight controls >(like Group, etc.). Resource usage on large VB projects is >ridiculous. >In short, native, supported controls for a lot that we have to >buy 3rd party controls for. >I was going to go on, but no one (MS least of all) is listening. >Instead I'm told I need all these things I have no use for, and >that all the code I've written and need to maintain is scrap. >Looks like I'll be with VB6 for a /long/ time. >-- >-------------------------------- >"For every action, there is an equal and opposite criticism."
Wed, 18 Jun 1902 08:00:00 GMT

Signe #13 / 24	Stand-Alone EXE File Quote: > Signet, > Maybe you should take a serious look at Delphi. I did some time ago. Geez, it's hard to completely switch languages when you know one so well. I learned C++, but that didn't seem so bad because it's so low level and there aren't as many commands, but I've done too much in VB to change I guess. Quote: > You can 'enhance' it to use VB like statements, and I have ported a > lot of DOS utilities in Basic 7.1 straight into Delphi. > If nothing else it is good for making 'Real' DLLs and doing things > that you simply cannot do in VB > Personally I find VB quicker for development. I do too, I love it from a form design, development standpoint. Just thought it could be made better, and /my/ ideas of better are a /whole lot/ different than MS's idea of better. ;-( -- -------------------------------- "For every action, there is an equal and opposite criticism."
Wed, 18 Jun 1902 08:00:00 GMT

J Fren #14 / 24	Stand-Alone EXE File Quote: >> Signet, >> Maybe you should take a serious look at Delphi. >I did some time ago. Geez, it's hard to completely switch >languages when you know one so well. I learned C++, but that >didn't seem so bad because it's so low level and there aren't as >many commands, but I've done too much in VB to change I guess. Dunno - it is a bit hard switching and swapping - but once one gets settled down it is Ok - I just have a VB like Delphi Library - makes things feel more familiar - but [Ctl F9] and [Ctl F5] still fox me. Quote: >I do too, I love it from a form design, development standpoint. >Just thought it could be made better, and /my/ ideas of better >are a /whole lot/ different than MS's idea of better. ;-( Delphi is pretty hot on Form Design Yes - mine as well - I think MS have some truly strange ideas. Quote: >-- >-------------------------------- >"For every action, there is an equal and opposite criticism."
Wed, 18 Jun 1902 08:00:00 GMT

th.. #15 / 24	Stand-Alone EXE File Quote: >ALL Windows programs rely on a massive run time support setup - these >files are the core of Windows. Sure C and Delphi can produce >'Standalone' programs - but they have to stand on Windows. But they're stand-alone, and that's an objective of the present exercise. Quote: >If you are very careful with the Controls that you use you can produce >a VB5 App that just requires : MSVBVM50.dll And the "just" defeats what I want for the current situation. It's not a relative matter. :-) Quote: >You say you are using VB4 - JUST DON'T (yes this is a shout) >Prior to VB5 - VB could not create UserControls - and these are the >things that are at the core of your graphics. In my opinion VB4 is a >substandard product and deserves to be thrown away. >I know - I started with it - and loathe it viscerally. >Also VB4 does not have AddressOf - which you will find essential for >some APIs - don't kid yourself that you will not need these features. >If I were you I would play around with simple controls, then charge >straight into UserControls and Classes. These are the eqivalant of >re-usable BASIC subroutines. >Good Luck - AND DON'T WASTE TIME WITH VB4 Well... I dunno. I have other tools I like better for that stuff, and v4 looks like it does what I need it for. But thanks for the input. John Baltimore
Mon, 19 May 2003 09:56:40 GMT

Page 1 of 2

[ 24 post ]

Go to page: [1] [2]