-
Visual Basic APIs and the effect in Windows environments
Hi I'm looking for some feedback on any experiences with Visual Basic applications
and API calls running in all of the Windows environments.. i.e.: Windows
2000, Windows 95/98, Windows NT workstation 4.
For this application I am responsible for testing the deployment in all of
the Windows environments. So from the installation stage to actually running
the application on the clients machine. This application integrates the
MS Excel Server, the WinInet (to connect to an ftp server) and Entrust.
The installation tool that we will be using is Microsofts Install Sheild.
One of my concerns is that this application declares a whole slew of APIs
in a seperate BAS file. Most of them are not used throughout the APP.
-Does this have any effects on a Windows environment? Will this cause problems
in Windows NT workstation 4.?
-I am curious to know if the APIs are the same in Windows NT and Windows
95/98 and 2000.
-Since we are not using all of these APIs will it cause any overhead or bottlenecks?
-Is it recommended that we only declare those APIS that we are using?
Does anyone have any testing advice they can give me.
Thanks in advance
Toni Bisson
-
Re: Visual Basic APIs and the effect in Windows environments
The unused declare statements won't cause any harm, but they do increase the
size of the executable a bit. I'd try to trim out (or comment out) the ones
that aren't being used.
As far as differences between API calls between 9x and NT/2000... there are
some, but if the different ones are unused it makes no difference. If they
are used, you'll find out in your testing <g>.
Dave
www.davidcrowell..com
-
Re: Visual Basic APIs and the effect in Windows environments
The unused declare statements won't cause any harm, but they do increase the
size of the executable a bit. I'd try to trim out (or comment out) the ones
that aren't being used.
As far as differences between API calls between 9x and NT/2000... there are
some, but if the different ones are unused it makes no difference. If they
are used, you'll find out in your testing <g>.
Dave
www.davidcrowell..com
-
Re: Visual Basic APIs and the effect in Windows environments
"Toni Bisson" <toni@magma.ca> wrote:
>
>Hi I'm looking for some feedback on any experiences with Visual Basic applications
>and API calls running in all of the Windows environments.. i.e.: Windows
>2000, Windows 95/98, Windows NT workstation 4.
>
>For this application I am responsible for testing the deployment in all
of
>the Windows environments. So from the installation stage to actually running
>the application on the clients machine. This application integrates the
>MS Excel Server, the WinInet (to connect to an ftp server) and Entrust.
>The installation tool that we will be using is Microsofts Install Sheild.
>
>One of my concerns is that this application declares a whole slew of APIs
>in a seperate BAS file. Most of them are not used throughout the APP.
>-Does this have any effects on a Windows environment? Will this cause problems
>in Windows NT workstation 4.?
>-I am curious to know if the APIs are the same in Windows NT and Windows
>95/98 and 2000.
>-Since we are not using all of these APIs will it cause any overhead or
bottlenecks?
>-Is it recommended that we only declare those APIS that we are using?
>
>Does anyone have any testing advice they can give me.
>
>Thanks in advance
>Toni Bisson
Toni,
I will try to make my answers as simple as possible:
>-Since we are not using all of these APIs will it cause any overhead or
bottlenecks?
UNLIKELY
>-Is it recommended that we only declare those APIS that we are using?
First of all - it will simplify your code. Second - it's not about how many
APIs, but how many DLLs they belong to. If all of your API functions belong
to the same dll (user32.dll; shell32.dll; kernel32.dll; etc), you will be
distributing only one dll. If you are declaring API functions from different
DLLs and not using half (or some) of them - then it's absolutely not reasonable
to keep then in the project due to "havier" distribution package.
>Does anyone have any testing advice they can give me.
A good QA person.
I may continue, but I hope you've already got my point.
Regards,
Roy
-
Re: Visual Basic APIs and the effect in Windows environments
"Toni Bisson" <toni@magma.ca> wrote:
>
>Hi I'm looking for some feedback on any experiences with Visual Basic applications
>and API calls running in all of the Windows environments.. i.e.: Windows
>2000, Windows 95/98, Windows NT workstation 4.
>
>For this application I am responsible for testing the deployment in all
of
>the Windows environments. So from the installation stage to actually running
>the application on the clients machine. This application integrates the
>MS Excel Server, the WinInet (to connect to an ftp server) and Entrust.
>The installation tool that we will be using is Microsofts Install Sheild.
>
>One of my concerns is that this application declares a whole slew of APIs
>in a seperate BAS file. Most of them are not used throughout the APP.
>-Does this have any effects on a Windows environment? Will this cause problems
>in Windows NT workstation 4.?
>-I am curious to know if the APIs are the same in Windows NT and Windows
>95/98 and 2000.
>-Since we are not using all of these APIs will it cause any overhead or
bottlenecks?
>-Is it recommended that we only declare those APIS that we are using?
>
>Does anyone have any testing advice they can give me.
>
>Thanks in advance
>Toni Bisson
Toni,
I will try to make my answers as simple as possible:
>-Since we are not using all of these APIs will it cause any overhead or
bottlenecks?
UNLIKELY
>-Is it recommended that we only declare those APIS that we are using?
First of all - it will simplify your code. Second - it's not about how many
APIs, but how many DLLs they belong to. If all of your API functions belong
to the same dll (user32.dll; shell32.dll; kernel32.dll; etc), you will be
distributing only one dll. If you are declaring API functions from different
DLLs and not using half (or some) of them - then it's absolutely not reasonable
to keep then in the project due to "havier" distribution package.
>Does anyone have any testing advice they can give me.
A good QA person.
I may continue, but I hope you've already got my point.
Regards,
Roy
-
Re: Visual Basic APIs and the effect in Windows environments
Thanks Roy...I think I do get your point. You are saying simplify the application
and the best thing we can do is declare those APIS that are being used.
Thanks for your feedback it is much appreciated.
Wish me luck in the test phase
Toni bisson
"Roy" <roy@aol.com> wrote:
>
>"Toni Bisson" <toni@magma.ca> wrote:
>>
>>Hi I'm looking for some feedback on any experiences with Visual Basic applications
>>and API calls running in all of the Windows environments.. i.e.: Windows
>>2000, Windows 95/98, Windows NT workstation 4.
>>
>>For this application I am responsible for testing the deployment in all
>of
>>the Windows environments. So from the installation stage to actually running
>>the application on the clients machine. This application integrates the
>>MS Excel Server, the WinInet (to connect to an ftp server) and Entrust.
>
>>The installation tool that we will be using is Microsofts Install Sheild.
>>
>>One of my concerns is that this application declares a whole slew of APIs
>>in a seperate BAS file. Most of them are not used throughout the APP.
>
>>-Does this have any effects on a Windows environment? Will this cause
problems
>>in Windows NT workstation 4.?
>>-I am curious to know if the APIs are the same in Windows NT and Windows
>>95/98 and 2000.
>>-Since we are not using all of these APIs will it cause any overhead or
>bottlenecks?
>>-Is it recommended that we only declare those APIS that we are using?
>>
>>Does anyone have any testing advice they can give me.
>>
>>Thanks in advance
>>Toni Bisson
>
>Toni,
>I will try to make my answers as simple as possible:
>
>>-Since we are not using all of these APIs will it cause any overhead or
>bottlenecks?
>UNLIKELY
>
>>-Is it recommended that we only declare those APIS that we are using?
>First of all - it will simplify your code. Second - it's not about how many
>APIs, but how many DLLs they belong to. If all of your API functions belong
>to the same dll (user32.dll; shell32.dll; kernel32.dll; etc), you will be
>distributing only one dll. If you are declaring API functions from different
>DLLs and not using half (or some) of them - then it's absolutely not reasonable
>to keep then in the project due to "havier" distribution package.
>
>>Does anyone have any testing advice they can give me.
>A good QA person.
>
>I may continue, but I hope you've already got my point.
>
>Regards,
>Roy
-
Re: Visual Basic APIs and the effect in Windows environments
Thanks Roy...I think I do get your point. You are saying simplify the application
and the best thing we can do is declare those APIS that are being used.
Thanks for your feedback it is much appreciated.
Wish me luck in the test phase
Toni bisson
"Roy" <roy@aol.com> wrote:
>
>"Toni Bisson" <toni@magma.ca> wrote:
>>
>>Hi I'm looking for some feedback on any experiences with Visual Basic applications
>>and API calls running in all of the Windows environments.. i.e.: Windows
>>2000, Windows 95/98, Windows NT workstation 4.
>>
>>For this application I am responsible for testing the deployment in all
>of
>>the Windows environments. So from the installation stage to actually running
>>the application on the clients machine. This application integrates the
>>MS Excel Server, the WinInet (to connect to an ftp server) and Entrust.
>
>>The installation tool that we will be using is Microsofts Install Sheild.
>>
>>One of my concerns is that this application declares a whole slew of APIs
>>in a seperate BAS file. Most of them are not used throughout the APP.
>
>>-Does this have any effects on a Windows environment? Will this cause
problems
>>in Windows NT workstation 4.?
>>-I am curious to know if the APIs are the same in Windows NT and Windows
>>95/98 and 2000.
>>-Since we are not using all of these APIs will it cause any overhead or
>bottlenecks?
>>-Is it recommended that we only declare those APIS that we are using?
>>
>>Does anyone have any testing advice they can give me.
>>
>>Thanks in advance
>>Toni Bisson
>
>Toni,
>I will try to make my answers as simple as possible:
>
>>-Since we are not using all of these APIs will it cause any overhead or
>bottlenecks?
>UNLIKELY
>
>>-Is it recommended that we only declare those APIS that we are using?
>First of all - it will simplify your code. Second - it's not about how many
>APIs, but how many DLLs they belong to. If all of your API functions belong
>to the same dll (user32.dll; shell32.dll; kernel32.dll; etc), you will be
>distributing only one dll. If you are declaring API functions from different
>DLLs and not using half (or some) of them - then it's absolutely not reasonable
>to keep then in the project due to "havier" distribution package.
>
>>Does anyone have any testing advice they can give me.
>A good QA person.
>
>I may continue, but I hope you've already got my point.
>
>Regards,
>Roy
-
Re: Visual Basic APIs and the effect in Windows environments
> -I am curious to know if the APIs are the same in Windows NT and Windows
> 95/98 and 2000.
The Win 32 API is consistent to an extent. But things will be different in
unexpected way.
A presonal experience might help here. We recently switched methods for
waiting for a shelled program to stop. Previously, I was using CreateProcess
and WaitForSingleObject. This year the code was changed to use VB's Shell
and the OpenProcess API instead of the CreateProcess.
The previous process worked fine in for Win 9x/NT systems. The change had
downright nasty effects on NT. WaitForSingleObject never detected the other
program closing. Instead this API either locked up (if the timeout was set
to INFINATE) or timed out. Future calls to WaitForSingleObject returned
immediately, until the system was restarted.
The code worked flawlessly on Win 9x systems, but fails every time on NT.
The ultimate solution ids to test in all systems.
--
~~~
!ti timda I ,KO
..em deppals nocaeB sivaM
!draH
~~
C'Ya,
mrfelis@yahoo!com
Toni Bisson <toni@magma.ca> wrote in message
news:3a687f64$1@news.devx.com...
>
> Hi I'm looking for some feedback on any experiences with Visual Basic
applications
> and API calls running in all of the Windows environments.. i.e.: Windows
> 2000, Windows 95/98, Windows NT workstation 4.
>
> For this application I am responsible for testing the deployment in all of
> the Windows environments. So from the installation stage to actually
running
> the application on the clients machine. This application integrates the
> MS Excel Server, the WinInet (to connect to an ftp server) and Entrust.
> The installation tool that we will be using is Microsofts Install Sheild.
>
> One of my concerns is that this application declares a whole slew of APIs
> in a seperate BAS file. Most of them are not used throughout the APP.
> -Does this have any effects on a Windows environment? Will this cause
problems
> in Windows NT workstation 4.?
> -I am curious to know if the APIs are the same in Windows NT and Windows
> 95/98 and 2000.
> -Since we are not using all of these APIs will it cause any overhead or
bottlenecks?
> -Is it recommended that we only declare those APIS that we are using?
>
> Does anyone have any testing advice they can give me.
>
> Thanks in advance
> Toni Bisson
-
Re: Visual Basic APIs and the effect in Windows environments
> -I am curious to know if the APIs are the same in Windows NT and Windows
> 95/98 and 2000.
The Win 32 API is consistent to an extent. But things will be different in
unexpected way.
A presonal experience might help here. We recently switched methods for
waiting for a shelled program to stop. Previously, I was using CreateProcess
and WaitForSingleObject. This year the code was changed to use VB's Shell
and the OpenProcess API instead of the CreateProcess.
The previous process worked fine in for Win 9x/NT systems. The change had
downright nasty effects on NT. WaitForSingleObject never detected the other
program closing. Instead this API either locked up (if the timeout was set
to INFINATE) or timed out. Future calls to WaitForSingleObject returned
immediately, until the system was restarted.
The code worked flawlessly on Win 9x systems, but fails every time on NT.
The ultimate solution ids to test in all systems.
--
~~~
!ti timda I ,KO
..em deppals nocaeB sivaM
!draH
~~
C'Ya,
mrfelis@yahoo!com
Toni Bisson <toni@magma.ca> wrote in message
news:3a687f64$1@news.devx.com...
>
> Hi I'm looking for some feedback on any experiences with Visual Basic
applications
> and API calls running in all of the Windows environments.. i.e.: Windows
> 2000, Windows 95/98, Windows NT workstation 4.
>
> For this application I am responsible for testing the deployment in all of
> the Windows environments. So from the installation stage to actually
running
> the application on the clients machine. This application integrates the
> MS Excel Server, the WinInet (to connect to an ftp server) and Entrust.
> The installation tool that we will be using is Microsofts Install Sheild.
>
> One of my concerns is that this application declares a whole slew of APIs
> in a seperate BAS file. Most of them are not used throughout the APP.
> -Does this have any effects on a Windows environment? Will this cause
problems
> in Windows NT workstation 4.?
> -I am curious to know if the APIs are the same in Windows NT and Windows
> 95/98 and 2000.
> -Since we are not using all of these APIs will it cause any overhead or
bottlenecks?
> -Is it recommended that we only declare those APIS that we are using?
>
> Does anyone have any testing advice they can give me.
>
> Thanks in advance
> Toni Bisson
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Development Centers
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center
|