RE: Going from 2003 server to Windows 7 Pro

"'Skand Bhargava' [email protected] [blat]" <[email protected]>
Newsgroups gmane.mail.blat
Message-ID <4D2620D28077449199FC9848C85B5E79@extensa>
In a 64 bit Windows environment...32 bit application...use 32 bit blat.dll...will go to SysWOW64 (not System32; the System32 folder is for 64 bit DLLs).

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Sunday, March 15, 2015 11:12 PM
To: [email protected]
Subject: RE: [blat] Going from 2003 server to Windows 7 Pro


    
  If you are distributing a 32 bit application, I’d just distribute ONLY 32 bit Blat, forcing it into System32 in 64bit Windows environments. If setup misbehaves, manually copy the 32 bit blat. 

  If you compile your app as a 64 bit app, then distribute the 64bit Blat too.

  Mike

  From: [email protected] [mailto:[email protected]] 
  Sent: March-14-15 16:38
  To: [email protected]
  Subject: RE: [blat] Going from 2003 server to Windows 7 Pro

  I include blat.dll in my distribution package (setup.exe file) created through MS Office Developers Toolkit and the file coolly sits in System32 or SysWOW64 depending on whether Windows is 32 bit or 64 bit. I presume all this happens correctly because OS has realised that my distribution package is a 32 bit system.

  However I am wondering if I include the 64 bit blat.dll, whether it will sit in System32 in a 64 bit Windows or not. I haven't tried it but have low expectations about it. I feel the installer will incorrectly copy this file to SysWOW64 folder.

  -Skand

  -----Original Message-----
  From: [email protected] [mailto:[email protected]]
  Sent: Saturday, March 14, 2015 9:29 PM
  To: [email protected]
  Subject: RE: [blat] Going from 2003 server to Windows 7 Pro

  Blat does NOT have an installer, so one must manually place the files appropriately. 

  I believe you are correct for pathing, just caution you to install and test both versions to be sure both installs are working at the end of the process. 

  Code below assembles parameters into a single parameter string used with send(cparams) after dll is declared with full path.

  cparams = '-body "' + body_as_string + '" -to '+name + domain + ' -subject "'+subject_string +'"'

  IF LEN(p_five)> 0 && if not default sender ID 

  cparams = cparams+' -f '+ return_email

  ENDIF

  LOCAL tlogfile && 2013 08 06

  tlogFILE = CDOW(DATE()-6)

  tlogfile = tlogfile+'.LOG'

  IF FILE(tlogfile) && delete 6 day old log file

  DELETE FILE (tlogfile)

  endif

  cparams = cparams+" -debug -log "+CDOW(DATE())+".LOG -try 2" && note a new log file daily

  Mike Mattos

  “Confidence is what you have before you understand the problem.”

  Woody Allen <http://www.goodreads.com/author/show/10356.Woody_Allen> 

  From: [email protected] [mailto:[email protected]] 
  Sent: March-14-15 12:32
  To: [email protected]
  Subject: RE: [blat] Going from 2003 server to Windows 7 Pro

  Hi,

  Just assuming if both versions are installed on same PC, the 64 bit blat.dll will be sitting in Windows\System32 folder while 32 bit blat.dll in Windows\SysWOW64.

  I am also assuming that a 32 bit application like MS Access 2000, when using blat.dll, will automatically use the 32 bit one. Similarly if a 64 bit application uses blat.dll, it will automatically refer to the 64 bit blat.dll.

  Are my assumptions correct?

  Regards,

  For Softools Middle East, A Dubai Based Company

  Skand Bhargava
  Attendance: Software is the main thing. Hardware (Reader) is only a means to get IN/OUT time accurately
  PO Box 14959, Dubai
  Tel: +971 4 2680533, Mob: +971 50 6340258 

  -----Original Message-----
  From: [email protected] [mailto:[email protected]]
  Sent: Saturday, March 14, 2015 8:07 PM
  To: [email protected]
  Subject: RE: [blat] Going from 2003 server to Windows 7 Pro

  I believe the trouble was most apparent when I had BOTH 32 and 64bit versions on the same machine, accessed by different windows apps. The ‘blat install’ was not shared between versions, I believe I ended up coding all parameters within the app rather than relying on blat install.

  Wasn’t a big deal, just frustrating while I figured it out. 

  Similar issue arose with Simply Accounting, it ‘updated’ a MySQL ODBC driver, removing the previous version, and shutting down all other users of the same driver. And you cannot install a ‘previous version’ of a driver. You can decide to add a newer version. SO Simply Accounting crashed the customers Windows access to all databases! 

  Mike

  From: [email protected] [mailto:[email protected]] 
  Sent: March-14-15 11:52
  To: [email protected]
  Subject: Re: [blat] Going from 2003 server to Windows 7 Pro

  > Is this correct?

  > 

  > I thought you need to use 32 bit or 64 bit depending on Application. I use MS Access 2000 which is a 32 bit application for our Call Monitoring (for scheduling PDF reports) and Payroll (for emailing payslips in PDF format). I always use 32 bit blat irrespective of whether the Windows is 32 bit or 64 bit.

  > 

  > -Skand

  Skand,

  How you use Blat is good, it seems to me that you are using Blat.exe as a standalone program, so you are not dependent on which size of Windows you run.

  For other folks, to use 32-bit or 64-bit copies of Blat can be a little confusing, so let’s see if I can make it better without going into technical details.

  If you want to run Blat.exe, the standalone program, then:

  1. When using 32-bit Windows, you must use the 32-bit Blat.exe because Windows cannot run any 64-bit code.

  2. When using 64-bit Windows, starting with Windows XP, it is safe to use 32-bit Blat.exe if you wish, or you can use the 64-bit Blat.exe.

  If you have an application that uses Blat.dll, then you need to use the same “size” Blat.dll as your application:

  1. If you have a 32-bit application that runs on either 32-bit or 64-bit Windows, your application must use 32-bit Blat.dll because of memory pointer limitations.

  2. If your application is 64-bit, which means it can run only on 64-bit Windows, then you must use 64-bit Blat.dll.

  Chip

  [Non-text portions of this message have been removed]

  [Non-text portions of this message have been removed]

  [Non-text portions of this message have been removed]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.