Hi All.:9does anyone know how I can remove this Lago item from my FS9 menu at all please,:-roll I did contact them, but have had NO reply whatsoever.:-madI do not have any Lago products now that I have got rid of the MD aircraft for various reasons.on a personal note,:-shy it really really does miff me right off when companies just add their items to the FS menu Without either Asking, or Informing you that they are doing so,:-fume and, then after completely removing their product, you STILL have their menu item left behind.:-fumenot only do I find this Arrogant,:-grr but, I also think it is Extremely bad Programming on their part regarding removal of the item's in question.:-newburnthanks.:-wave

if there is a dll in your module folder, remove that :)

Remove the vimacore2004.dll from your FS2004 modules folder. That will do the trick.David

thanks PD and David,yes, I did that and it's gone now, thanks again.PS what is the vimacore2004.dll for!

just the module for Lago.

Vimacore2004 is a dll created by Vistamare software. It's used for all sorts of things under the FS9 hood, like creating the functionality to play sounds in proximity to a certain object for instance. It's important to bear in mind though that vimacore2004 itself doesn't do much without another program to use it. It simply provides a variable space for other applications to work with FS. I think it also enables things to show in the FS9 menu, although I'd bet that the menu items can be removed without removing Vimacore itself. Maurizio Gavioli is the programmer, and if you email him I'm sure he'd be happy to explain how to do it. Sorry, I don't have his address handy.thanks,

thanks again guy's,I really appreciate you're help, it did the trick, and now my FS9 Menu is clear of the Lago item,I still never got a reply from them and this is why I asked for help in here. but, I do still stand by my original comment in that I think it's very very arrogant not to mention darn right rude, to just dump another item into you're FS9 menu without either asking you if you want it there or not, or even just telling you that it will be there next time you fire up "YOU'RE" FS9, notice the "YOU'RE" FS9 and not Their FS9.I have noticed now that there are a couple of companies that are starting to do this same thing, and, I think it should be stopped.you may think that this is all bit on the silly side, but, I ask you this, what else can they just dump into you're FS9 without asking you !PSS have never done this, and their products have load editors, fuel configuration panels, and a panel configuration tool as well, none of these are put in you're FS9 menu.and to top it all off, there wasn't really even a need for it in there anyway.

>I have noticed now that there are a couple of companies that>are starting to do this same thing, and, I think it should be>stopped.There are specific reasons because many companies are starting to add their own menus.Users are, of course, asking for more and more features, and many of these are not directly available from the official Microsoft SDK, for example, accessing a lot of data variables not listed in the SDK but existing in the simulation, like meteo, flight model, several simulation states, etc.Also, there's the problem the gauge code is not always executed, if you fly from spot plane view, the gauge code is not called, and if there are calculations and predictions to be made at all times not supported by FS, the only way it's to make a module.Once you have your product that has to rely on that module, the fact there's a new menu or not it's not important, it's not the menu that takes memory or cpu time, once you have the module in place, the menu doesn't cost anything extra, and can be useful for accessory functions.Of course the installation program doesn't ask if you want the module to be installed: if the airplane relies on it to work, they can't offer you a choice that could make the product unusable.WRT the uninstall, if the module is shared with several packages, it would be *really* rude to uninistall it, because that would break all the others. For example, all Lago sceneries use Vimacore.dll. If you have, let's say, the Maldives and Honolulu, and you decide to get rid of the Maldives, uninstalling vimacore.dll would break Honolulu as well. And, it's almost impossibile to make the uninstaller aware of all possibile products. It could know only of products released before, but how the uninstaller can be absolutely sure you don't have any *newer* products unknown to it, that relies on that very same module ? Safer choice it's to let all the modules in place.And, I object to your statement of "bad programming". Bad programming would be duplicating the same functions into each product. Since the most important function of the modules it's usually the direct memory access for variables not available through the SDK interface, and this is not related to a specific airplane or product, it makes a lot of sense to group all these features into a DLL, that would be accessed by all the different products, rather than duplicating the same code in all the gagues around. This way, it's much more convenient to fix problems, without having to patch *all* the products involved, but just the module. That's Windows programming 101, very basic and widely accepted rule.And, if you want to know the reason why many companies are just starting to do this *now*, there are some reasonable explainations.First, the main reason it's the unworthiness of the MS SDK. It's too little, and it usually comes too late, and it's very badly documented. If WE developers had access to the SDK months *before* release, not months *after*, and if the SDK was better documented, and covering all the aspect of the simulation, not just what's it's needed to do a very simple default-like airplane, nobody would have felt the need to find things in the hard way.Previously, up to FS2002, many relied on FSUIPC module to suit their needs, because it was freely available. Now, since FSUIPC has become a commercial program, many companies simply decided to develop their own interface in order not having to depend on it.Of course, if the MS SDK had been done very differently ( I, for example, would agree being put under the MSDN subscription, so the MSFS team could justify the cost of better supporting it ), there would be no need for FSUIPC, or any other additional module.For example, a better way of doing these things would be FS to support Automation, like almost every other MS program does. I was expecting this feature since the first Windows version, but, unfortunately, it never came.best regards,Umberto Colapicchioni

Umberto, your comments make a lot of sense! let me add this too: the first "intrusive" module (intrusive per this thread subject) is FSUIPC, which adds a "MODULES" menu item too. Per this thread subject, is this bad programming as well?Hope this helps!

It is bad programing practice. MS advises that for shared files (ie .dlls) that on installation:"If the file is already present, compare its date and size to determine whether it is the same version as the one you are installing. If it is, increment the usage count in its corresponding registry entry."and on uninstalling: "When uninstalling an application, decrease the usage count in the registry for any shared component

>It is bad programing practice. MS advises that for shared>files (ie .dlls) that on installation:that was the original Windows logo guidelines. Unfortunately, this method is not 100% reliable, again according to Microsoft, from MSDN site:Why the Existing "SharedDLL" Mechanism is InadequateTo do correct code caching, the existing shared dynamic-link library (DLL) reference counting scheme will not suffice because reference counts are easily inflated. Specifically, any application that is reinstalled increases the reference count on a shared DLL even though that DLL already has a reference count belonging to the particular application.What's happening here: if a user launch the installation program twice, skipping the uninstallation, the reference count value will no longer be reliable, because the mechanism relies on the fact that for a certain number of installations, there should be an equal number of uninstallations.Also, since FS modules are not self-registering dlls and are not put into the windowssystem32 folder, the increase/decrease of the reference counting is not done by Windows automatically, but it has to be dealt with by the installer/uninstaller routine, and it would require, for example, that all FS developers would agree on this strategy, and I'm afraid it's a little late. Just imagine all the different addons using FSUIPC, just one not adhering to this standard, and the reference count will become unreliable.I think it's better to be on the safe side, the added disk space ( not much, modules are rarely more than 500KB ) it's a small price to pay, a module usually doesn't do anything, if there is no client to call its functions. If anything, modules are all in the same place, and quite easy to locate and delete, if really the menu annoys that much.But, I think we are covering two different problems, apart from discussing of best uninstalling strategies, I had the impression the original poster complained about the very existance of a module, as if it shouldn't be needed. That's why I've explained the reasoning behind making such extensions, the menu it's just a side effect, but it's what the module is doing in the background that counts.>If MS released the SDK "months *before* release" then the SDK>could not reflect subsequent changes to FS made during last>minute testing and developers would then complain if they had>to re-work their products once FS was released.Well, I'm assuring that I would rather prefer to fix small things ( last minute testing could only impact minor stuff ) a week or so after a new FS release, than waiting many months *before* release trying to guess what MS will leave in the next SDK and what will likely disappear, and waiting other months *after* release for the final SDK, that is as badly documented as usual.Also, why on MSDN we got all Betas and ( more important ), Release Candidates and Gold Masters, but NOT for FS ? A small fix could be easily made in the time between RTM and retail release date, so users would be able to enjoy, in many cases, all their existing programs already updated by the time the FS release hits the store shelves.It works for OS releases, Office products, developer products, and these are all products that relies on 3rd parties to succeed, just like FS!!>Preparing fully comprehensive SDKs is resource intensive. MS>may well judge that it's not cost-effective to apply resources>to SDKs and prefer to apply the resources elsewhere more>profitably and continue to issue SDK without support. that's why I've been proposing putting into MSDN, for commercial developers. So the MSFS team could justify the money spent in support.And, the SDK's could be more focused: Panel developing it's probably the most complex task in FS, so the SDK should be released first. There's a Netpipes SDK that it's close to useless, and nobody use it. There's a Multiplayer SDK that simply doesn't work, or perhaps the documentation is so badly written that's impossibile to make it work, and nodoby uses it.There is an ABL SDK, but the language itself is so bad and so underpowered ( it's *much* less powerful than the old FS5 ADV language! ) that almost nodoby really use ABL, although the concept could have been really intriguing, if it was developed better. The FSEDIT SDK it's a bad joke. The program, once being supplied together with FS2002 Professional version, has been dropped from FS2004, because it's so bugged that it has been relabeled as an SDK, so none will be able to complain, because the SDK is ufficially unsupported. The end result is that nobody use it, and everyone doing flight models is using AirED, and all the resources of doing FSEDIT has been wasted.There's a Cabdir SDK. I *really* hope they didn't spent too much time on this...I suspect that having a good Panel SDK and a good Scenery SDK, and getting rid of all the others, would be much better, for users and developers alike.>Why should MS take the risk of>being sued by a developer who has relied on the SDK to develop>a product only to find a fault in the SDK requires rework and>subsequent delays to the release date?Well, not having *any* SDK for months, the delays would be certain. And, there are already a lot of faults in the various SDK we had to rely onto, and wait months for, and I don't think anyone is dreaming of sueing MS for this. Also, if the SDK will remain unsupported, like today is, none will have the right to complain anyway, regardless of when the SDK was released.

You refer to the section "Why the Existing "SharedDLL" Mechanism is Inadequate" on the MS site. This section is immediately followed by a section "Tracking Usage of Shared Components" which begins "To do reference counting correctly..." so my point is still valid.It isn't a matter of developers "agreeing" on a strategy - it's just a matter of them following published best practice. No mechanism is perfect but that's no reason for ignoring it totally, which is what you imply most developers do. If the SDKs were only available on subscription it would mean that the rest of us would either have to go without them or pay what a developer would be prepared to pay. Also, expectations are higher once something has been paid for, increasing the risk of legal action."It works for OS releases, Office products, developer products, and these are all products that relies on 3rd parties to succeed, just like FS!!" Are you suggesting that OS releases, Office products etc would be failures without 3rd parties? The bottom line is that MS main business isn't supporting 3rd party developers but selling/leasing its products and services. It will balance the additional costs of providing 3rd party support against the additional profit it expects to be able to make as a result . How many purchasers of FS base their decision to buy on the existence of add-ons? I'll stick my neck out and suggest very few - I guess most people find out afterwards.

Another argument why Windoze is not an Operating System, but an overbloated kids toy and pure crap.It makes me wonder again and again how serious IT people refer to their wonderful Windows 2003 server installations. Kids toy brought to "bigger" machines, same crap as on the desktop...But we don't have an alternative and need to live with it...Andreas

>which begins "To do reference counting>correctly..." so my point is still valid.and after the "correctly..." there is: "Internet Component Download maintains a ModuleUsage section in the registry".Standard DLL doesn't have it. The whole point of the article is to explain how Internet components improves on the reference counting issues, aknowledging the shortcomings of the standard SharedDLL mechanism.>It isn't a matter of developers "agreeing" on a strategy ->it's just a matter of them following published best practice.The published best practice, according to MS, it's not reliable enough, so it's simply better to play safe, and don't risk deleting anything, it's way harmless than having users complaining why a certain product doesn't work anymore.>If the SDKs were only available on subscription it would mean>that the rest of us would either have to go without them or>pay what a developer would be prepared to pay.No, you would be free to choose between having unsupported, exactly like it is now, and having it under MSDN subs, to get access to support.>Are you suggesting that OS>releases, Office products etc would be failures without 3rd>parties?Would you choose Windows if the *only* software available were comining from Microsoft, and all the other developers supported, let's say, the Mac ?Do you think Office would be where is it now if it was ONLY a Wordprocessor+Spreadsheet ? We have Wordperfect dominating the market before, and we had Lotus. Office won because it's not *just* a set of Applications, it's an extremely capable platform, expecially Access, lots of software doesn't work without MS database, and so can't be easily ported to other platforms.MS has an history of winning the developers first, to get end users after. 10 years ago, the N.1 developer tools were coming from Borland, everybody used Turbo C or TP, then Microsoft slowly improved their VS product version after version, and now they are absolutely the best, but what make the difference was, primarly, their MSDN subscription and their MCSE certifications, and *all* of this is geared toward 3rd parties. Ok, try to see it from an opposite point of view:1996 - no published SDK, FS had the following competitors:ATPSierra Pro PilotFlight UnlimitedFlyX-PlaneThere were even *addons* for the other products, I did a commercial scenery for Italy for ATP and lot of freeware was available too, and PMDG *started* their career with Fly 757!1998 - Microsoft publishes the first SDK for FS982001 - Where are the competitors ?>How many purchasers of FS base>their decision to buy on the existence of add-ons? I'll stick>my neck out and suggest very few - I guess most people find>out afterwards.Yes, a new user probably will find after some time of the addon market, but FS has been around for more than 20 years, the existing users are well aware of the situation.