From: Karl E. Peterson on
Claire wrote:
> "MikeD" <nobody(a)nowhere.edu> wrote in message
> news:%23V3PiXv6KHA.5708(a)TK2MSFTNGP02.phx.gbl...
>>
>> "Claire" <replyto(a)fra> wrote in message
>> news:OSScK6u6KHA.5848(a)TK2MSFTNGP06.phx.gbl...
>>> Hello,
>>> I wrote the code in late 90's and some of my global variables are
>>> declared as Byte.
>>> My question is:
>>> Should I convert all those variables to Long as now we are dealing more
>>> and more with 64 bit Windows, or it does not matter?
>>> I do not want to run into compatibility problem.
>>> Thanks,
>>
>>
>> Well you wouldn't change Byte variables to Long anyway. You *might* change
>> Integer variables to Long, but that was really more with going from 16 bit
>> development to 32 bit development.
>>
>> The apps you create with VB6 are 32 bit apps and when run on a 64 bit OS,
>> run in the 32 bit sub-system (called WOW64).
>>
>> So what I'm saying is you should not have to change anything in your 32 bit
>> VB6 apps for them to run on a 64 bit version of Windows.
>>
>> Running into compatibility problems is something else entirely.
>>
> Mike, I do have also some variables declared as Integer. Should I change
> those?

I think the best answer here is, "If you don't know, you probably
shouldn't." You don't change variable types based on operating system,
but based on what function they serve within the program. Ideally, you
choose your variable types initially based upon this criteria.
Changing the operating system doesn't affect that decision, in nearly
all cases. There are a few cases where that isn't strictly true, but
none where your program will fail for this reason alone.

--
..NET: It's About Trust!
http://vfred.mvps.org


From: Nobody on
"Claire" <replyto(a)fra> wrote in message
news:ORoJ8Dx6KHA.5808(a)TK2MSFTNGP02.phx.gbl...
> Mike, I do have also some variables declared as Integer. Should I change
> those?

Change nothing. There is no next version of classic VB, so there is no need
to change anything.

P.S.: I have ported a DLL written in VC++ from 32 to 64 bits and I
practically didn't have to change a thing. They kept byte/int/long the same
size as before.


From: Helmut Meukel on
"Claire" <replyto(a)fra> schrieb im Newsbeitrag
news:ORoJ8Dx6KHA.5808(a)TK2MSFTNGP02.phx.gbl...
>
> "MikeD" <nobody(a)nowhere.edu> wrote in message
> news:%23V3PiXv6KHA.5708(a)TK2MSFTNGP02.phx.gbl...
>>
>> "Claire" <replyto(a)fra> wrote in message
>> news:OSScK6u6KHA.5848(a)TK2MSFTNGP06.phx.gbl...
>>> Hello,
>>> I wrote the code in late 90's and some of my global variables are
>>> declared as Byte.
>>> My question is:
>>> Should I convert all those variables to Long as now we are dealing more and
>>> more with 64 bit Windows, or it does not matter?
>>> I do not want to run into compatibility problem.
>>> Thanks,
>>
>>
>> Well you wouldn't change Byte variables to Long anyway. You *might* change
>> Integer variables to Long, but that was really more with going from 16 bit
>> development to 32 bit development.
>>
>> The apps you create with VB6 are 32 bit apps and when run on a 64 bit OS, run
>> in the 32 bit sub-system (called WOW64).
>>
>> So what I'm saying is you should not have to change anything in your 32 bit
>> VB6 apps for them to run on a 64 bit version of Windows.
>>
>> Running into compatibility problems is something else entirely.
>>
>>
>> --
>> Mike
>>
> Mike, I do have also some variables declared as Integer. Should I change
> those?
> Claire
>
>



Claire,
I wouldn't change anything.
With 16-bit code (=VB3) you had a performance penalty with
Longs compared to Byte and Integer, but with 32 bit this doesn't
matter.
I once wrote a for next speed test, comparing byte to integer to
long to single to double when used as loop counter.
I just started the compiled VB5 exes (both native code, but one
compiled to favor Pentium Pro).
On a machine with Pentium 4 CPU 2.80 GHz and Win2000
There were no performance differences worth mentioning.
Then I recompiled with VB6. Same result.
On my new Vista machine the VB6 apps were four times faster.
Still no performance differences worth mentioning.

If the 32-bit subsystem(WOW64) on 64-bit windows has different
performance impacts depending on the data type used I can't test
here.

HTH.

Helmut.



From: Claire on
Thank you all.
The reason I asked was that I have received email from someone who installed
my software in Windows 7 64 bit environment and has a problem with the
executable (agi.exe) crashing on startup.
I have tested it on my Windows 7 64 bit and I cannot reproduce that problem.
The Event Log received from that user is shown below:
================
Log Name: Application
Source: Application Error
Date: 4/30/2010 3:09:19 AM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: RRK3
Description:
Faulting application name: agi.exe, version: 5.2.0.75, time stamp:
0x4b6c9951
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00300af7
Faulting process id: 0xef8
Faulting application start time: 0x01cae8340cfdd917
Faulting application path: C:\Program Files (x86)\AGI\agi.exe
Faulting module path: unknown
Report Id: 4ad79e1c-5427-11df-b124-e0cb4ed5900a
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2010-04-30T07:09:19.000000000Z" />
<EventRecordID>2762</EventRecordID>
<Channel>Application</Channel>
<Computer>RRK3</Computer>
<Security />
</System>
<EventData>
<Data>agi.exe</Data>
<Data>5.2.0.75</Data>
<Data>4b6c9951</Data>
<Data>unknown</Data>
<Data>0.0.0.0</Data>
<Data>00000000</Data>
<Data>c0000005</Data>
<Data>00300af7</Data>
<Data>ef8</Data>
<Data>01cae8340cfdd917</Data>
<Data>C:\Program Files (x86)\AGI\agi.exe</Data>
<Data>unknown</Data>
<Data>4ad79e1c-5427-11df-b124-e0cb4ed5900a</Data>
</EventData>
</Event>

and:

Log Name: Application
Source: Windows Error Reporting
Date: 4/30/2010 3:09:19 AM
Event ID: 1001
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: RRK3
Description:
Fault bucket 1123192085, type 5
Event Name: BEX
Response: Not available
Cab Id: 0

Problem signature:
P1: agi.exe
P2: 5.2.0.75
P3: 4b6c9951
P4: StackHash_0a9e
P5: 0.0.0.0
P6: 00000000
P7: 00300af7
P8: c0000005
P9: 00000008
P10:

Attached files:
C:\Users\richard\AppData\Local\Temp\WER9500.tmp.WERInternalMetadata.xml

These files may be available here:
C:\Users\richard\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_agi.exe_6a189c5857e31f184e88832e4df27f2d528ff3_0f7b982b

Analysis symbol:
Rechecking for solution: 0
Report Id: 4ad79e1c-5427-11df-b124-e0cb4ed5900a
Report Status: 16
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Windows Error Reporting" />
<EventID Qualifiers="0">1001</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2010-04-30T07:09:19.000000000Z" />
<EventRecordID>2763</EventRecordID>
<Channel>Application</Channel>
<Computer>RRK3</Computer>
<Security />
</System>
<EventData>
<Data>1123192085</Data>
<Data>5</Data>
<Data>BEX</Data>
<Data>Not available</Data>
<Data>0</Data>
<Data>agi.exe</Data>
<Data>5.2.0.75</Data>
<Data>4b6c9951</Data>
<Data>StackHash_0a9e</Data>
<Data>0.0.0.0</Data>
<Data>00000000</Data>
<Data>00300af7</Data>
<Data>c0000005</Data>
<Data>00000008</Data>
<Data>
</Data>
<Data>
C:\Users\richard\AppData\Local\Temp\WER9500.tmp.WERInternalMetadata.xml</Data>
<Data>C:\Users\richard\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_agi.exe_6a189c5857e31f184e88832e4df27f2d528ff3_0f7b982b</Data>
<Data>
</Data>
<Data>0</Data>
<Data>4ad79e1c-5427-11df-b124-e0cb4ed5900a</Data>
<Data>16</Data>
</EventData>
</Event>
==================
Thanks,
Claire

"Claire" <replyto(a)fra> wrote in message
news:OSScK6u6KHA.5848(a)TK2MSFTNGP06.phx.gbl...
> Hello,
> I wrote the code in late 90's and some of my global variables are
> declared as Byte.
> My question is:
> Should I convert all those variables to Long as now we are dealing more
> and more with 64 bit Windows, or it does not matter?
> I do not want to run into compatibility problem.
> Thanks,
> Claire
>


From: Claire on
I do not know how to analyze those reports Windows creates.
Below is shown content of Report.wer file:
=========================
Version=1
EventType=BEX
EventTime=129170849590818653
ReportType=2
Consent=1
UploadTime=129170849591442654
ReportIdentifier=4ad79e1d-5427-11df-b124-e0cb4ed5900a
IntegratorReportIdentifier=4ad79e1c-5427-11df-b124-e0cb4ed5900a
WOW64=1
Response.BucketId=1123192085
Response.BucketTable=5
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=agi.exe
Sig[1].Name=Application Version
Sig[1].Value=5.2.0.75
Sig[2].Name=Application Timestamp
Sig[2].Value=4b6c9951
Sig[3].Name=Fault Module Name
Sig[3].Value=StackHash_0a9e
Sig[4].Name=Fault Module Version
Sig[4].Value=0.0.0.0
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=00000000
Sig[6].Name=Exception Offset
Sig[6].Value=00300af7
Sig[7].Name=Exception Code
Sig[7].Value=c0000005
Sig[8].Name=Exception Data
Sig[8].Value=00000008
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=6.1.7600.2.0.0.768.3
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=1033
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=0a9e
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=0a9e372d3b4ad19135b953a78882e789
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=0a9e
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=0a9e372d3b4ad19135b953a78882e789
UI[2]=C:\Program Files (x86)\AGI\agi.exe
UI[3]=AGI has stopped working
UI[4]=Windows can check online for a solution to the problem.
UI[5]=Check online for a solution and close the program
UI[6]=Check online for a solution later and close the program
UI[7]=Close the program
LoadedModule[0]=C:\Program Files (x86)\AGI\agi.exe
LoadedModule[1]=C:\Windows\SysWOW64\ntdll.dll
LoadedModule[2]=C:\Windows\syswow64\kernel32.dll
LoadedModule[3]=C:\Windows\syswow64\KERNELBASE.dll
LoadedModule[4]=C:\Windows\system32\MSVBVM50.DLL
LoadedModule[5]=C:\Windows\syswow64\USER32.dll
LoadedModule[6]=C:\Windows\syswow64\GDI32.dll
LoadedModule[7]=C:\Windows\syswow64\LPK.dll
LoadedModule[8]=C:\Windows\syswow64\USP10.dll
LoadedModule[9]=C:\Windows\syswow64\msvcrt.dll
LoadedModule[10]=C:\Windows\syswow64\ADVAPI32.dll
LoadedModule[11]=C:\Windows\SysWOW64\sechost.dll
LoadedModule[12]=C:\Windows\syswow64\RPCRT4.dll
LoadedModule[13]=C:\Windows\syswow64\SspiCli.dll
LoadedModule[14]=C:\Windows\syswow64\CRYPTBASE.dll
LoadedModule[15]=C:\Windows\syswow64\ole32.dll
LoadedModule[16]=C:\Windows\syswow64\OLEAUT32.dll
LoadedModule[17]=C:\Windows\system32\IMM32.DLL
LoadedModule[18]=C:\Windows\syswow64\MSCTF.dll
LoadedModule[19]=C:\Program
Files\CheckPoint\ZAForceField\WOW64\Plugins\ISWSHEX.dll
LoadedModule[20]=C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5\MSVCR80.dll
LoadedModule[21]=C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5\MSVCP80.dll
LoadedModule[22]=C:\Windows\system32\ntmarta.dll
LoadedModule[23]=C:\Windows\syswow64\WLDAP32.dll
State[0].Key=Transport.DoneStage1
State[0].Value=1
State[1].Key=DataRequest
State[1].Value=Bucket=1123192085/nBucketTable=5/nResponse=1/n
FriendlyEventName=Stopped working
ConsentKey=BEX
AppName=AGI
AppPath=C:\Program Files (x86)\AGI\agi.exe
=========================

Thanks,
Claire

"Claire" <replyto(a)fra> wrote in message
news:eSHEDFz6KHA.4508(a)TK2MSFTNGP06.phx.gbl...
> Thank you all.
> The reason I asked was that I have received email from someone who
> installed my software in Windows 7 64 bit environment and has a problem
> with the executable (agi.exe) crashing on startup.
> I have tested it on my Windows 7 64 bit and I cannot reproduce that
> problem.
> The Event Log received from that user is shown below:
> ================
> Log Name: Application
> Source: Application Error
> Date: 4/30/2010 3:09:19 AM
> Event ID: 1000
> Task Category: (100)
> Level: Error
> Keywords: Classic
> User: N/A
> Computer: RRK3
> Description:
> Faulting application name: agi.exe, version: 5.2.0.75, time stamp:
> 0x4b6c9951
> Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
> Exception code: 0xc0000005
> Fault offset: 0x00300af7
> Faulting process id: 0xef8
> Faulting application start time: 0x01cae8340cfdd917
> Faulting application path: C:\Program Files (x86)\AGI\agi.exe
> Faulting module path: unknown
> Report Id: 4ad79e1c-5427-11df-b124-e0cb4ed5900a
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System>
> <Provider Name="Application Error" />
> <EventID Qualifiers="0">1000</EventID>
> <Level>2</Level>
> <Task>100</Task>
> <Keywords>0x80000000000000</Keywords>
> <TimeCreated SystemTime="2010-04-30T07:09:19.000000000Z" />
> <EventRecordID>2762</EventRecordID>
> <Channel>Application</Channel>
> <Computer>RRK3</Computer>
> <Security />
> </System>
> <EventData>
> <Data>agi.exe</Data>
> <Data>5.2.0.75</Data>
> <Data>4b6c9951</Data>
> <Data>unknown</Data>
> <Data>0.0.0.0</Data>
> <Data>00000000</Data>
> <Data>c0000005</Data>
> <Data>00300af7</Data>
> <Data>ef8</Data>
> <Data>01cae8340cfdd917</Data>
> <Data>C:\Program Files (x86)\AGI\agi.exe</Data>
> <Data>unknown</Data>
> <Data>4ad79e1c-5427-11df-b124-e0cb4ed5900a</Data>
> </EventData>
> </Event>
>
> and:
>
> Log Name: Application
> Source: Windows Error Reporting
> Date: 4/30/2010 3:09:19 AM
> Event ID: 1001
> Task Category: None
> Level: Information
> Keywords: Classic
> User: N/A
> Computer: RRK3
> Description:
> Fault bucket 1123192085, type 5
> Event Name: BEX
> Response: Not available
> Cab Id: 0
>
> Problem signature:
> P1: agi.exe
> P2: 5.2.0.75
> P3: 4b6c9951
> P4: StackHash_0a9e
> P5: 0.0.0.0
> P6: 00000000
> P7: 00300af7
> P8: c0000005
> P9: 00000008
> P10:
>
> Attached files:
> C:\Users\richard\AppData\Local\Temp\WER9500.tmp.WERInternalMetadata.xml
>
> These files may be available here:
> C:\Users\richard\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_agi.exe_6a189c5857e31f184e88832e4df27f2d528ff3_0f7b982b
>
> Analysis symbol:
> Rechecking for solution: 0
> Report Id: 4ad79e1c-5427-11df-b124-e0cb4ed5900a
> Report Status: 16
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System>
> <Provider Name="Windows Error Reporting" />
> <EventID Qualifiers="0">1001</EventID>
> <Level>4</Level>
> <Task>0</Task>
> <Keywords>0x80000000000000</Keywords>
> <TimeCreated SystemTime="2010-04-30T07:09:19.000000000Z" />
> <EventRecordID>2763</EventRecordID>
> <Channel>Application</Channel>
> <Computer>RRK3</Computer>
> <Security />
> </System>
> <EventData>
> <Data>1123192085</Data>
> <Data>5</Data>
> <Data>BEX</Data>
> <Data>Not available</Data>
> <Data>0</Data>
> <Data>agi.exe</Data>
> <Data>5.2.0.75</Data>
> <Data>4b6c9951</Data>
> <Data>StackHash_0a9e</Data>
> <Data>0.0.0.0</Data>
> <Data>00000000</Data>
> <Data>00300af7</Data>
> <Data>c0000005</Data>
> <Data>00000008</Data>
> <Data>
> </Data>
> <Data>
> C:\Users\richard\AppData\Local\Temp\WER9500.tmp.WERInternalMetadata.xml</Data>
>
> <Data>C:\Users\richard\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_agi.exe_6a189c5857e31f184e88832e4df27f2d528ff3_0f7b982b</Data>
> <Data>
> </Data>
> <Data>0</Data>
> <Data>4ad79e1c-5427-11df-b124-e0cb4ed5900a</Data>
> <Data>16</Data>
> </EventData>
> </Event>
> ==================
> Thanks,
> Claire
>
> "Claire" <replyto(a)fra> wrote in message
> news:OSScK6u6KHA.5848(a)TK2MSFTNGP06.phx.gbl...
>> Hello,
>> I wrote the code in late 90's and some of my global variables
>> are declared as Byte.
>> My question is:
>> Should I convert all those variables to Long as now we are dealing more
>> and more with 64 bit Windows, or it does not matter?
>> I do not want to run into compatibility problem.
>> Thanks,
>> Claire
>>
>
>


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Read/ Write file header
Next: Localized Date