I need to use the reference to Microsoft Word 97 in my VB6 development project. (Its a long story - in a nutshell if I use ref to MSWord97 then I can support Word 97+).
I use Microsoft Word 2007 on my development machine. Ideally if I could get away with NOT installing Word97, that would be great.
In VB6 I tried to set a reference to C:\Software\Microsoft\Office97Pro\OFFICE\mso97.dll (path to software - not installed) but that didn't work. I then tried regsvr32 mso97.dll but that gave me the error: mso97.dll was loaded, but the DllRegisterServer entry point was not found.
Anyone know what I need to do to get this to work? Or will I need to install Word 97 on my machine for it to work?
It sounds like you basically want to do as suggested in Writing Automation clients for multiple Office versions but ignoring the advice about using late binding.
The type library involved is MSWORD8.OLB, but I can't recall whether there is any legitimate way to obtain it without Word 97 or an Office 97 Edition including Word. Offhand I'm not sure what the impact of registering this tylepib would have on your Word 2007 installation either, since they may well share many ClassID values.
In the VC++ article PRB: Automation of Office Using #import Can Fail if Multiple Versions of Office Are Installed Microsoft seems to suggest this can be a viable strategy as long as you reference the proper OLB. This is probably less of a problem for VB6 than in C++ because VB6 doesn't use the VC++ #import semantics for locating typelibs. Then again they may be referring to run-time behavior, since the explanation concludes by once more suggesting late binding.
The article WD: How to Obtain the Word for Windows Type Library offers links to the Word 6 and Word 7 typelibs (links may no longer be good) but none for Word 97, which they suggest you obtain by installing Word 97.
In any case it only sounds safe to use the constants, enums, etc. from Word 97 and use late binding for all of your objects. This "half a loaf" is better than nothing. You could still do your initial development with early-bound declarations to geet "Intellisense" assistance, then go back and change all of the early-bound object declarations to late-bound As Object and replacing Set X = New TYPE by the corresponding late-bound CreateObject() call, leaving the actual strong typing as a trailing comment. One could also use conditional compilation #If/#Else blocks to make flipping back to early binding easier later.
Since obtaining MSWORD8.OLB legitimately may be impossible today, you might also consider OFF: "Built-in Constants in Visual Basic for Applications" (WC0993) which offers a download containing VB .BAS modules defining the constants for many old versions of Word and other Office applications. The download link works - as of right now at least!
Since named constants are the primary reason for the typelibs (considering that only late binding is truly safe) this might not be a bad compromise. You can take the .BAS file you need, clean it up (bound to be some warts in there), and even convert it to a custom "Generic Word" TLB containing just those constants and enums with a little effort. For that matter somebody may already have done this work. I'd suggest you try a few searches before writing your own "VB .BAS to ODL/IDL" compiler though.
When adding a reference to your project, look for MS Word x.0 Object Library where x is the version of MS Word you want to work against. I believe you can reference a lower version than Word 2007 (version 12.0). Look for 8.0.
Related
I know that in Windows, the GUID is used by the Windows Installer to check for already installed products under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ and other product-relevant information is stored using the compressed GUID in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\.
Yet a google search to figure out what the compressed GUID actually is and why both forms are being used for saving product-specific data in the registry database only revealed algorithms for converting from one form to another.
Apparently, the compressed GUID is calculated from merely changing the order of the characters in a specific way, giving me more confusion about why this is the compressed form and why it is used this way.
Additionally, some sources appear to refer to the GUID as the product code of the software product, and others specifically use the term product code as a synonym for the compressed GUID.
I do not have much knowledge of the inner workings of Windows and its installers, but hope that someone can enlighten me with the information I was unable to find. I apologize in advance for my mediocre English.
Not sure what you are doing, or why this is a problem for your scenario. However, the GUIDs you mention - the rearranged GUIDs with the braces and dashes removed - are actually referred to as Packed GUIDs. Then there are also Compressed GUIDs that are just 23 characters long that are primarily used to create Darwin descriptors - which are combinations of the product code GUID, a feature name, and a component code GUID. They are used for MSI's advertisement features. This is according to Bob Baker's book "Getting Started with InstallShield Developer and Windows Installer Setups".
As far as I recall the packed GUIDs are apparently used to make registry searches more efficient. I am unfamiliar with the exact technical details involved. Perhaps Bob or Rob of WiX can elaborate.
I have to run, not really an answer, I will look at it again later. Please elaborate your question with more details on what the problem actually is. As a summary it seems the collective comments suggest that this GUID concept is due to registry space saving, searching efficiency and obfuscation.
My advice (if I understand correctly): do not attempt to read packed or compressed GUIDs from the registry directly - rather go via the MSI API (COM / Win32) - which should have the features you need to do almost anything with MSI.
Some Links:
MSIEXEC -Embedding
MSI API Links (quite similar links):
Is MsiOpenProduct the correct way to read properties from an installed product?
Wix upgrade goes into maintenance mode and never does upgrade
how to find out which products are installed - newer product are already installed MSI windows
Is there an alternative to GUID when using msiexec to uninstall an application?
The packed guid is reportedly used to save space in the registry. It is used for component Ids, so once you start getting a million components on the system I assume they were worried about the extra space usage. It's also possible it was used to prevent people trawling the registry to look for Windows Installer items instead of using the APIs. It's an undocumented implementation detail, and if too many people got into habit of using the registry instead of using the APIs there would be issues if that implementation changed. So treat this as interesting information, not something to use in an application.
Darwin Descriptors are different - they are just an encoding of product code, component id, and feature name. They occur in various places where that combination of data is useful for loading COM servers, starting programs etc. Again, it's undocumented, but if you wanted to untangle them you could LoadLibrary on msi.dll and find and call MsiDecomposeDescriptorW with the right parameters.
I have an old vb6 app that I'm in charge of maintaining that saves, opens, and prints Word documents to a users computer. The other day when we switched from office 2003 to office 2010, I started to get complaints that the software would no longer open saved reports and print them. Removing Officer 2010 and installing 2003 fixes the problem.
The sub procedure that handles this is all vanilla msdn code and I'm unable to find anything that would tie it to a certain version of Word. My next thought is perhaps its the OLE dll reference. Where/how can I update the VB6 reference to the dll to work with the new version of office?
Any other suggestions would be greatly appreciated.
I'm not sure but as a guess it sounds like you are trying to use early binding. If so this is likely your problem.
There are numerous MS KB articles warning about this over a period of over a decade. Examples:
http://support.microsoft.com/kb/247579
http://support.microsoft.com/kb/245115
In other words: remove all references to any version of Word, declare all of the objects As Object, and use CreateObject() or GetObject() where appropriate instead of Set Obj = New LibName.ClassName.
These KB articles are old now, and the old rules that let you get away with compiling with a reference to Word 95 and still automate Word 2002 don't seem to apply anymore. Besides needing the oldest supported version of Office installed on your dev machine, I suspect upward compatibility was broken beginning in Office 2003.
Your best bet is late binding. The performance penalty is minimal for most programs so the biggest headache is losing IntelliSense.
If you just blindly update the reference, you'll likely break support for Office 2003. if that's not a problem, go for it.
if it is, you'll need to narrow down where in particular, the app is failing. There are some minor differences between revs of the automation model between versions. Not a lot, but they are there.
Most likely, the code is doing something in a way that makes it specific to 2003. MS does a pretty good job of maintaining backwards compat, but they aren't 100%
To answer your question "Where/how can I update the VB6 reference to the dll to work with the new version of office?": You need of course a computer with Office 2010 and VB 6 installed. If you open the project in the VB IDE, you can change the reference to the appropriate Word Library. The references are also noted in the VBP file, e.g. like this
Type=Exe
Reference=*\G{00020905-0000-0000-C000-000000000046}#8.0#409#C:\Program Files\Microsoft Office\OFFICE11\MSWORD.OLB#Microsoft Word 8.0 Object Library
Reference=*\G{00025E01-0000-0000-C000-000000000046}#4.0#0#C:\Program Files\Common Files\Microsoft Shared\DAO\DAO350.DLL#Microsoft DAO 3.51 Object Library
Reference=*\G{420B2830-E718-11CF-893D-00A0C9054228}#1.0#0#C:\WINDOWS\system32\SCRRUN.DLL#Microsoft Scripting Runtime
Then recompile.
Well, and if you are there, you can just start to debug and see, what happens in detail and why the reports fail. There's no way to change the reference without recompiling, if this was your question.
If it's plain vanilla code related to open, save and print, it's hard to imagine something going wrong.
On the other hand - are there any "base files" in Word format, which are used? May be they have an old format (from Office 95, have just seen this lately). Try to open those files manually and see what happens.
We've got this large application written in Delphi 5, and development is ongoing to this day. There is research going on into migrating to newer versions, but so far there is no success, as some 3rd party components have not been updated in ages and do not work on later versions.
In the meantime however people need to continue work on it. Now Delphi 5 IDE is no real treat. It's pretty bug-ridden and lacks a lot of features of contemporary IDEs which makes it difficult to use. Especially when it comes to debugging.
So I was wondering - would it be possible to use Visual Studio in the process? As far as I know the .PDB file format is pretty old and is well documented. Could it be possible to make the Delphi compiler to somehow generate a .PDB files for it's compiled results? Then the program could be debugged with Visual Studio, possibly to a much greater extent than in the original IDE.
Well, the absolute Holy Grail would be to move all development to VS, just keeping the compiler from Delphi, but I imagine that would be pretty impossible.
No, and neither can any other version of Delphi. You can use Map2Dgb to turn a detailed map file into a dbg file, though, and you can use that in WinDbg.
I'm curious what debugging features you're expecting to use in Visual Studio that aren't in Delphi 5 and that also don't rely on the IDE understanding the Delphi language. I was always rather pleased with Delphi 5.
BTW, you can vote for this feature here.
Note, that VS-compatitible debug info will be useful not only for debugging application (I agree: it's better to use Delphi), but it will be useful for using tools like Process Explorer. For example, Process Explorer may be able to show human-readable call stack, instead of RAW numbers.
I've tried tds2pdb and it works great for me.
Apparently you can't. Seems that PDB is after all a propieritary Microsoft format without documentation, and as such there are no other tools generating it. Pity. :(
I would recommend moving to a later version of Delphi. We have done this with various applications for clients. Moving to a newer version of Delphi is normally straightforward, but there were issues moving from D5 to D6 due to changes in the way components were handled (design time code being separated from run time) and the change to Unicode in D2009 was a bigger change.
The main thing is to sort out the third party components. We only ever use third party components that come with source so if the worst happens and the vendor disappears, we can still work on the components ourselves.
Which components are causing the issues?
OK, the Windows dev platform I have is a Windows XP box and a copy of Visual C++ 6.0. I'm trying to create or modify security descriptors for a service. My initial thought from other answers (and some reading) was that I should use ConvertStringSecurityDescriptorToSecurityDescriptor to setup my security descriptor.
Except...my install of VC++ 6.0 lacks the headers for this function (sddl.h according to MSDN).
Can anyone point me to other APIs for creating/modifying Security Descriptors? I'd be happy if I could walk through an existing one (I can QueryServiceObjectSecurity) and just eliminate certain users, but I can't figure out how to do that just looking at MSDN.
Alternately, if someone could point me in the direction of how to call this function without proper headers, that would be fine.
Obvious answer rebuttal: I can (and will) make an attempt to get IT to install a newer version of VC++ on my system, but the last time I asked IT about anything significant it took 7 weeks for them to respond. Since I'd like to get this done in the next week or two, I think IT is not going to fix this question for me in a timely manner.
In theory, you don't need a newer compiler, just an updated SDK. In reality, VC++ 6 is old enough that it may have trouble parsing the headers for a current SDK though.
As an alternative to that, you could declare pointers to the correct types of functions in your code, then use LoadLibrary and GetProcAddress to get the addresses of the correct functions, then call the functions via those pointers.
As an aside, however, I'd point out that I doubt what you've envisioned will work. I've never tried to do exactly what you're trying, so it's always possible I'm wrong, but every time I've done anything manipulating security descriptors, DACLs, SACLs, or anything similar in Windows, the code's ended up considerably longer and more complex than it initially seemed like it should. Even something extremely trivial generally requires at least a couple hundred lines of code...
You could check out the DCOMPerm sample, it has handles the DACL/ACE and other structures you are going to run into - thats where i started when i created a set of classes to handle this for our COM installations - and as #jerry coffin said it ended up being a lot of code.
You'll have to download the SDK to get the sample.
Is it possible to remotely debug a process started outside VB6?
The application is a VB6 application with quite a few dll/ocx resources. I am attempting to setup a ClickOnce deployment, using Registration-Free COM, of the VB6 app but have been getting errors when it executes.
My understanding of the way that VB6 redirects COM registerations will probably mean that this is not possible but I thought someone might have a better idea.
To support Darryl's answer suggesting Windbg - here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft guy with a brief introduction to Windbg.
EDIT: Just to make it totally clear. Windbg is a free standalone debugger from Microsoft. Compile your VB6 EXEs, DLLs and OCXs into native code with symbols (create PDB files) and you will be able to debug your ClickOnce application.
Key excerpt from the blog:
If you have limited access to the server machine then you can use the
remote debugging facilities of WinDbg. Attach a copy of WinDbg to the
process in the usual way and then turn it in to a debugging server
(check out .server in the WinDbg help). You can then connect to it
remotely from the File menu of WinDbg. It will be just like being
there except for the lack of noise from the server room fans. When
debugging a remote, your copy of WinDbg is just a very smart terminal
so all extensions, symbols and so on have to be on the remote server.
You set this up the exact same way for any DLL, VB6 or .NET.
The symbols for your component will not load until your component does
and so you have to let the server run at least that long. You can put
a break in early in your VB code if you want to stop the debugger at
that point but if you do, remember that it will stop there every time
through the code. Let’s assume that you let it run and then break in.
If you list the loaded symbols for your module with "x MyModule!*"
then you will see all of your functions together with a lot of symbols
bundled in there for you. VB adds interfaces and symbols quite
unashamedly but you don’t generally need to worry about those. One
thing that will probably look strange is that all class/method syntax
with the C++ double colon convention instead of the friendly little
dot. WinDbg doesn’t understand that VB is different and it is treated
just like any DLL with symbols.
From here, you can set breakpoints in the usual way (bp etc) and step
through code. You can also open up VB source code modules and set
breakpoints in them with F9 although the VB file extensions are not in
the source file type dropdown. Stepping through the code is revealing
but might be a little alarming if you have not seen the code that VB
generates for you before. You will be stepping through the assembler
and there is a lot of COM goo in there. Hresults get checked a lot.
You will probably need to refer to the source often to work out where
you are since it takes a bit of practice to be able to know what the
source code looked like. Variants are especially challenging because
VB does a lot of work for you there and what looks like a simple
equation can result in a great deal of code. Optimised code is even
harder because the order of execution is often very different from
what you might expect and it is harder than usual to see the data.
Data is not easy to get at this way. When you look at local variables
(dv is the command) then you may see that variables are simply listed
as eclipsed which means that the memory is being used for something
else as well within the function lifetime or that the name is not
unique in this context. Enums just show as integers or longs and
objects show as pointers. In fact, they always were exactly that but
the VB IDE hides that from you. VB strings are COM BSTRs (and
accordingly Unicode) under the covers and byte arrays are really char
arrays. You might be surprised to discover that VB strings are Unicode
as VB appears to have no support for anything but ANSI. That is
because the Ruby forms engine was ANSI only. The runtime converts the
Unicode strings to ANSI for Ruby and API calls although there are ways
to pass Unicode if you want.
You are not going to be able to get at the Err, App or Printer objects
since you would need to go through a lot of internal and completely
undocumented structures to get at them. Even if you could get there,
they would just be raw data without the accessor functions that you
use in VB. If you need to look at any of those fields, your best bet
is to embed debug code in the source code to copy their values to
somewhere that you can get at.
You can step in to the VB runtime if you want but it probably won’t be
very revealing if you are trying to debug your application. If you do,
you will notice that VB’s internals are very COM influenced. The
influence was actually two way since some COM ideas came from VB
originally.
You may see exceptions when running your code. Null reference
exceptions (i.e dereferencing a null pointer) are not uncommon or
anything to worry about. They will show up as first chance C000005
exceptions with a 0 or almost 0 address. The runtime will sometimes do
that if there are objects set to nothing but that is safe because the
only possible values are null or a valid value. You will also see
exceptions if your code does lookups in collections and the value is
not there. Because exceptions are now so expensive, you probably want
to avoid doing that if you can. Another exception that you will
commonly see is c000008f. If you look the number up then you will find
that it is a floating point inexact result exception. It is used in a
different meaning here – since we don’t generate real floating point
inexact result exceptions, they can safely be thrown to indicate VB
errors of the normal trappable type.
Debugging hangs and crashes in VB components is done very much in the
same way as with any other unmanaged component but it is just a little
harder because of the compilations described above. If you have to try
debugging VB code this way, I would strongly recommend that you start
on a "Hello world" application and work your way up. All the things
that may VB an easy language to code in make it a terrible language to
debug.
I believe that when debugging in VB6, it does not attach to a running binary but instead interprets the code within it's own process. This is why the Task Manager and Win32 APIs show VB6.exe as the running app when debugging.
Also as you say, VB6 sometimes short-circuits calls to COM libraries so intercepting these calls is not always possible.
You're probably going to have to resort to intelligent logging (i.e. log the values of variables around the points where the errors you are getting occur in the hope of locating the line of code it occurs on, and/or the state of relevant variables.)
Good luck
Have you tried windbg? Just make sure you have pdb files for the project.