In the course of the installation of trados, I have the runtime of the installshield ISProbe.tlb failing with error 2 (not found), although it's correctly there as well as dao2535.tlb of microsoft shared (not there but I could get it from the XP installation).
Questions are: Why is the first seen as not found although it's there - is this a registry problem?
Are these files important (DAO) and is it enough for me to copy them from the windows installation (which would maybe bring me back to first issue)
Is Wine supporting .tlb files
a .tbl file needs a key in the registry under \HKEY_CLASS_ROOT\Typelib\{CLSID of the component}.
You can make a serach with regedit for "ISProbe.tlb". If no occurence is found, then your error is normal.
A tlb file is very important for COM object to be used in a out-of-process way. And just copy it will not solve the problem because you need to register it into the registry. And if you register the tbl file, you'll need to register the component itself. In other word, try to install the application which provides the wanted component.
You can make a serach with regedit for "ISProbe.tlb". If no occurence is found, then your error is normal.
A tlb file is very important for COM object to be used in a out-of-process way. And just copy it will not solve the problem because you need to register it into the registry. And if you register the tbl file, you'll need to register the component itself. In other word, try to install the application which provides the wanted component.
The odd thing is that dao2535.tlb is not directly accessible on my XP on that directory either.
On Wine I have dao350.dll; dao350.dll and dao360.dll on XP.
In any case there is some repairing work being in progress (comparing to the big break of 0.9.60), because that's the first time I get the desktop icon of synergy (another component) for weeks.
In the registry I have
[Software\\Classes\\Typelib\\{94636247-BC39-4B8B-A728-2D1FBEBFA76A}\\1.0\\0\\win32] 1216821507
@="C:\\Programme\\Gemeinsame Dateien\\InstallShield\\Professional\\RunTime\\IsProBE.tlb"
in system.reg but nothing starting with HKEY_CLASS_ROOT
On Wine I have dao350.dll; dao350.dll and dao360.dll on XP.
In any case there is some repairing work being in progress (comparing to the big break of 0.9.60), because that's the first time I get the desktop icon of synergy (another component) for weeks.
In the registry I have
[Software\\Classes\\Typelib\\{94636247-BC39-4B8B-A728-2D1FBEBFA76A}\\1.0\\0\\win32] 1216821507
@="C:\\Programme\\Gemeinsame Dateien\\InstallShield\\Professional\\RunTime\\IsProBE.tlb"
in system.reg but nothing starting with HKEY_CLASS_ROOT
In which registry file?
Looks like there is something more to add then because the only occurrence of HKEY is with the .NET and Java.
There is no registry entry simply starting with HKEY and probably I will have to know the path to the .NET application like here:
[Software\\Microsoft\\.NETFramework\\Policy\\AppPatch\\v2.0.50727.00000\\winword.exe\\{2CCAA9FE-6884-4AF2-99DD-5217B94115DF}\\Registry Keys\\{2CCAA9FE-6884-4AF2-99DD-5217B94115DF}] 1216821126
"Key Name"="HKEY_CLASSES_ROOT\\Interface\\{000C0601-0000-0000-C000-000000000046}"
"Key Presence"=dword:00000000
Please however note that on this test MS office is not installed, this patch on winword.exe is only for Trados.
The HKEY is also not the same number as the number on the first line.
Looks like there is something more to add then because the only occurrence of HKEY is with the .NET and Java.
There is no registry entry simply starting with HKEY and probably I will have to know the path to the .NET application like here:
[Software\\Microsoft\\.NETFramework\\Policy\\AppPatch\\v2.0.50727.00000\\winword.exe\\{2CCAA9FE-6884-4AF2-99DD-5217B94115DF}\\Registry Keys\\{2CCAA9FE-6884-4AF2-99DD-5217B94115DF}] 1216821126
"Key Name"="HKEY_CLASSES_ROOT\\Interface\\{000C0601-0000-0000-C000-000000000046}"
"Key Presence"=dword:00000000
Please however note that on this test MS office is not installed, this patch on winword.exe is only for Trados.
The HKEY is also not the same number as the number on the first line.
If the key is missing the way you are describing it, then I can't use regedit, rather regsvr32 or regasm.
Regasm is however crashing at the moment at the end (bug 13679), causing me some error with the IDriver of the installshield.
Suppose this registry entry has to be added into the place where regasm is writing them, where would it be to add it manually? The .NET is not writing into the register (alike I said once would have register problem when copying the files of a java application directly from Windows into Wine and I got a sharp answer since Java is not writing into the register).
So to make things short: where is regasm writing into??
Regasm is however crashing at the moment at the end (bug 13679), causing me some error with the IDriver of the installshield.
Suppose this registry entry has to be added into the place where regasm is writing them, where would it be to add it manually? The .NET is not writing into the register (alike I said once would have register problem when copying the files of a java application directly from Windows into Wine and I got a sharp answer since Java is not writing into the register).
So to make things short: where is regasm writing into??
Maybe some more information so that you understand why I keep talking about Java and the .NET at the same time.
Trados had been bought in 2005 by its competitor SDL which was offering a competing software, SDLX.
It's like for the people using Autocad, that Autocad had been bought by the competitor the second largest in the branch.
Now, instead of paying for one software, you are paying for Autocad and it's competitor. There are basically different, you can't use both at the same time because they are not even working the same way, one is tagging files to process them, the other is converting files to its own format before processing. Pay for 2 and use one - the dream of every developer and one of the reason for it being overpriced.
Trados (the most widely used) as it's looks like was written in Java. SDLX is based on the .NET. Now SDL is trying to merge this two softwares that have actually nothing in common, had made Synergy as a bridge between Trados and SDLX, Synergy is based on .NET and it looks like that any new function introduced into Synergy to work in both softwares is based on the .NET, which ends up in a Java application depending on the .NET2
Isn't it wonderful ?!
Presently I am only testing trados, I am not even interested in 100 years in learning to cope with SDLX even if SDL is offering free online interactive seminars.
All the tests I do are for Trados - Someone else will have to relay for SDLX, but I do not worry, SDLX is SDL's baby, if Trados get working, they will take care of them so that they don't loose even more people using the "wrong" application.
Trados had been bought in 2005 by its competitor SDL which was offering a competing software, SDLX.
It's like for the people using Autocad, that Autocad had been bought by the competitor the second largest in the branch.
Now, instead of paying for one software, you are paying for Autocad and it's competitor. There are basically different, you can't use both at the same time because they are not even working the same way, one is tagging files to process them, the other is converting files to its own format before processing. Pay for 2 and use one - the dream of every developer and one of the reason for it being overpriced.
Trados (the most widely used) as it's looks like was written in Java. SDLX is based on the .NET. Now SDL is trying to merge this two softwares that have actually nothing in common, had made Synergy as a bridge between Trados and SDLX, Synergy is based on .NET and it looks like that any new function introduced into Synergy to work in both softwares is based on the .NET, which ends up in a Java application depending on the .NET2
Isn't it wonderful ?!
Presently I am only testing trados, I am not even interested in 100 years in learning to cope with SDLX even if SDL is offering free online interactive seminars.
All the tests I do are for Trados - Someone else will have to relay for SDLX, but I do not worry, SDLX is SDL's baby, if Trados get working, they will take care of them so that they don't loose even more people using the "wrong" application.
. I checked my registry files under my wine directory, and I have no key which begin by HKEY_CLASSES_ROOT, too. But I can use regedit ^^OK, all data here:
The entry is there where you told me.
On the main section (after the number):
Name: standard REG_SZ data: value not set
1.0 standard REG_SZ Installshield DevStudio Setup kernel
win32 standard REG_SZ Path of the file (up to the file)
flags standard REG_SZ 0
helpdir same path as win32 to the directory containing the file (path not to the file itself)
Is there a reason that the software cant find it? Should I complete helpdir?
The entry is there where you told me.
On the main section (after the number):
Name: standard REG_SZ data: value not set
1.0 standard REG_SZ Installshield DevStudio Setup kernel
win32 standard REG_SZ Path of the file (up to the file)
flags standard REG_SZ 0
helpdir same path as win32 to the directory containing the file (path not to the file itself)
Is there a reason that the software cant find it? Should I complete helpdir?
If I launch the installation, I have to know which debug channel to activate, otherwise I will end up with a log of 400MB.
I can't launch the installation without the installshield (components independently one from another) because otherwise I get a weird message that the service pack of this installer can not be applied to this version and the installation is aborting.
Furthermore I have to know exactly when to cut it because it looks like this installshield component is installed with trados (where the first time this error is occuring) which is crashing at the registration. Then synergy installs fine (but is never working in a trial mode) and then on SDLX you get back to the error (in the past regasm.exe had exacly the same crash as with Trados but now the component is being launched again and it goes through after waiting approx. 10 mn for wine to debug a page fault and it ends with this error).
I can't launch the installation without the installshield (components independently one from another) because otherwise I get a weird message that the service pack of this installer can not be applied to this version and the installation is aborting.
Furthermore I have to know exactly when to cut it because it looks like this installshield component is installed with trados (where the first time this error is occuring) which is crashing at the registration. Then synergy installs fine (but is never working in a trial mode) and then on SDLX you get back to the error (in the past regasm.exe had exacly the same crash as with Trados but now the component is being launched again and it goes through after waiting approx. 10 mn for wine to debug a page fault and it ends with this error).
-
James Mckenzie
Is Wine supporting .tlb files
Timeout:
I was able to import .tlb files from .NET 1.1. I'll have to go back and see what I did at a later time. Can this wait until this weekend for me to look at it?
James McKenzie
-----Original Message-----
I was able to import .tlb files from .NET 1.1. I'll have to go back and see what I did at a later time. Can this wait until this weekend for me to look at it?
James McKenzie
-----Original Message-----
From: Timeout <[email protected]>
Sent: Jul 24, 2008 8:46 AM
To: [email protected]
Subject: [Wine] Re: Is Wine supporting .tlb files
If I launch the installation, I have to know which debug channel to activate, otherwise I will end up with a log of 400MB.
I can't launch the installation without the installshield (components independently one from another) because otherwise I get a weird message that the service pack of this installer can not be applied to this version and the installation is aborting.
Furthermore I have to know exactly when to cut it because it looks like this installshield component is installed with trados (where the first time this error is occuring) which is crashing at the registration. Then synergy installs fine (but is never working in a trial mode) and then on SDLX you get back to the error (in the past regasm.exe had exacly the same crash as with Trados but now the component is being launched again and it goes through after waiting approx. 10 mn for wine to debug a page fault and it ends with this error).
Just an update: on yesterday's GIT (18.08), the files are still not able to be found. Here an extract from the installation:
It looks like that the line about FIND_DATA is new. Is there something I can do?
Code: Select all
err:ole:TLB_ReadTypeLib Loading of typelib L"C:\\Programme\\Gemeinsame Dateien\\InstallShield\\Professional\\RunTime\\IsProBE.tlb" failed with error 2
fixme:x11drv:X11DRV_SetWindowRgn not supported on other thread window 0xa0052
err:ole:marshal_object object doesn't expose interface {be6115a1-7de5-48dc-ad2a-25060e00fce2}, failing with error 0x80004002
err:ole:ClientIdentity_QueryMultipleInterfaces IRemUnknown_RemQueryInterface failed with error 0x80004002
fixme:advapi:LookupAccountNameW (null) L"yolande" (nil) 0x317c38 (nil) 0x317c3c 0x317c30 - stub
fixme:advapi:LookupAccountNameW (null) L"yolande" 0x1ba6620 0x317c38 0x1ba63c8 0x317c3c 0x317c30 - stub
fixme:msi:ACTION_HandleStandardAction unhandled standard action L"SetODBCFolders"
fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixme:advapi:CheckTokenMembership (0x128 0x15ec80 0x33d4ac) stub!
wine: Unhandled page fault on read access to 0x00000000 at address 0x2de2c57 (thread 0037), starting debugger...
err:ole:marshal_object object doesn't expose interface {be6115a1-7de5-48dc-ad2a-25060e00fce2}, failing with error 0x80004002
err:ole:ClientIdentity_QueryMultipleInterfaces IRemUnknown_RemQueryInterface failed with error 0x80004002
fixme:atl:AtlModuleInit SEMI-STUB (0x1e40a60 0x1e3e430 0x1e10000)
err:ole:TLB_ReadTypeLib Loading of typelib L"C:\\Programme\\Gemeinsame Dateien\\Microsoft Shared\\DAO\\dao2535.tlb" failed with error 2
fixme:ole:DllRegisterServer stub
fixme:atl:AtlModuleInit SEMI-STUB (0x10045f90 0x1003c388 0x10000000)
fixme:atl:AtlModuleInit SEMI-STUB (0x10096bd8 0x100921f8 0x10000000)
fixme:atl:AtlModuleInit SEMI-STUB (0x10078bb8 0x10071848 0x10000000)
fixme:shell:IShellLinkA_fnGetPath (0x1bbc0f8): WIN32_FIND_DATA is not yet filled.
fixme:shell:IShellLinkA_fnGetPath (0x1bbc0f8): WIN32_FIND_DATA is not yet filled.
fixme:shell:IShellLinkA_fnGetPath (0x1be7488): WIN32_FIND_DATA is not yet filled.
fixme:shell:IShellLinkA_fnGetPath (0x1be7488): WIN32_FIND_DATA is not yet filled.
fixme:shell:IShellLinkA_fnGetPath (0x1ba38b8): WIN32_FIND_DATA is not yet filled.
fixme:shell:IShellLinkA_fnGetPath (0x1ba38b8): WIN32_FIND_DATA is not yet filled.
fixme:shell:DllCanUnloadNow stub
fixme:shell:DllCanUnloadNow stub
err:ole:dispatch_rpc no apartment found for ipid {ffffffff-ffff-ffff-3400-000031000000}
err:rpc:I_RpcReceive we got fault packet with status 0x80010108
err:ole:dispatch_rpc no apartment found for ipid {ffffffff-ffff-ffff-3400-000031000000}
err:rpc:I_RpcReceive we got fault packet with status 0x80010108
fixme:shell:DllCanUnloadNow stub
fixme:shell:DllCanUnloadNow stub
I got some hope about the user32 fix for dll not in the same installation directory as the installation file.
However this patch is not working for my case.
Now a question for developers knowing about this topic:
I have these .tlb files, they are in the directory, they are registered and yet they can't be found.
So far (in Wine or Crossover), I have only seen this problem (together with a null reference exception in some case) only with an error message in German or in Spanish.
In English this does seem to go through.
The null reference exception disappears if the installshield window appears, followed by a page fault that Wine is handling after some time. However it's get stuck at the next path not found.
Now a thought (maybe I'm crazy): the .NET, during the installation is not able to see the language and is setting back to English as standard. Is not the .NET then looking somewhere internally for an English path although the error message is well showing a German path?
How do I proceed to have an installation with an English prefix when my o/s is set per default on German?
However this patch is not working for my case.
Now a question for developers knowing about this topic:
I have these .tlb files, they are in the directory, they are registered and yet they can't be found.
So far (in Wine or Crossover), I have only seen this problem (together with a null reference exception in some case) only with an error message in German or in Spanish.
In English this does seem to go through.
The null reference exception disappears if the installshield window appears, followed by a page fault that Wine is handling after some time. However it's get stuck at the next path not found.
Now a thought (maybe I'm crazy): the .NET, during the installation is not able to see the language and is setting back to English as standard. Is not the .NET then looking somewhere internally for an English path although the error message is well showing a German path?
How do I proceed to have an installation with an English prefix when my o/s is set per default on German?
