hello there.
just thought it would be ltta easier to use C++ scripting instead of perlscript or maybe along with.
c++ and perl are similar languages not to say more.
and maybe it would save a lotta space, becausewhen i have to install activeperl it takes approx. 30mb of disk space
It would also take 30mb of space to install a C++ scripting system, "assuming" such a thing exists. The scripting in Mushclient is not built into the client, but uses an external 'engine'. This means that any script type you want to run requires one of these engines to operate with Mushclient, and then only if Mushclient knows how to connect to it. If scripting where built in, then Mushclient would be an extra 30MB in size, would not support 4 different languages and would probably be a lot slower.
Assuming you could find a C++ script engine and it was actually smaller than 30MB, then Mushclient would still need to be changed to support that engine.
Basically, to explain it another way. If you have a printer and a copy of Word, you also need a 'driver' to sit in between and make them talk to each other. No driver, and the printer won't do anything. Same with a script. Without an engine (the driver) in between Mushclient and your script, all you have is a file with a bunch of C++ commands in it.
I've never heard of a C++ scripting engine. I don't even think that C++ can do such a thing, but I could be wrong on that.
The big problem with C++, at least, in its most common form, is that it is not interpreted. It is compiled. That would make it considerably more difficult to use as a scripting languages, if not impossible. All the scripting engines are basically virtual machines for your script - this means that perhaps Java would be a better alternative than C++ to use as a scripting language, even if personally I'm not terribly fond of it.
What might be possible, on the other hand, but completely different, would be to have a DLL interface - i.e. dynamically load a given DLL and call a function in that library. However, I'm not absolutely positive that will work either. You would probably need to have some form of common protocol for a common entry point function, and then have a way of passing back and forth events, methods and such. This is probably far more trouble than it's actually worth.
loading a DLL is exactly what MC does. It loads the vbscript/etc dll and uses that as the go between. Try clicking onRegister DLL on the script menu, and youll see what I mean.
I don't believe we're talking about the same kind of DLL. I believe that the DLL that MC is loading, vbscript.dll, is the interpreter, the virtual machine, whatever you want to call it that executes the VB script. The DLL that I was referring to would be your C/C++ code, compiled into a DLL - not an interpreter. Hence the difficulty, because you would have to know the entry points, and the addresses of whatever functions you want to call.
I agree with the comment that C++ is generally compiled not interpreted, and thus would be a funny script engine. Java is similar, if you want C++ style syntax, use that.
Personally I wouldn't compare C++ and Perl, contrast maybe, but not compare.
That DLL idea sounds interesting... Not that there's something MUSHClient can't do now, or that it's not slow enough to need compiled code, but out of curiosity, could it be done? Maybe specify a DLL whose functions triggers/aliases/whatever called? Or does it have to be declared beforehand (at MUClient compile time)?
That's the thing Poromenos, to access functions inside a DLL you need to know their address. I'm not fully aware of the exact mechanisms of this; I believe that the DLL contains a symbol table of function vs address, but your program has to have declared something to the effect of "I want this function from that DLL, but I don't know its address quite yet". This would mean that you could, in theory, have a default DLL that was empty for every single event, trigger, function, whatever you would want it to contain - MUSHclient would need this declared at compile time. Then you could make a replacement DLL that contained the same functions, that did something useful this time, and the symbol lookup would find the right addresses.
I'm not sure if it's possible to have a common entry point that is a function that, given a string (for a function name) will return a pointer to the function, much like the table lookups in table.c of SMAUG. I don't know if this would work from an application to a DLL though.
An interesting question is how the C++ program would know how to call MUSHclient functions, e.g. World.Note "hello".
Still, like you said, MUSHclient can already do just about everything you need it to do, and having this extra DLL lying around seems like it could be very unsafe for program execution. The nice thing about scripts is that they're fairly controlled, and it's hard to have them break (too badly) your program. C++ on the other hand could hose your running application, and do all sorts of very nasty things if mistakes are made. I don't think it's a good idea to have DLL support, myself, considering the problem it's trying to solve.
Scripting (except for Python) doesn't support this. You would need something like:
Declare Function GetDeskTopWindow Lib "user32" ()
Scripting doesn't support the 'Declare' option and I doubt any of the rest will work. When you execute CreateObject for a database or the like you are connecting to an ActiveX component using the IUnknown or IDispatch functions that are automatically added to ActiveX. In theory, other DLLs also have a table containing all the intefaces, but they are are set to expose them to scripts or other ActiveX interfaces. It is also pointlessly silly, since compiling the C++ code into a DLL, but not choosing to make it ActiveX would be dumb in this case. lol
As for a C++ engine.. Most muds use some version of C that impliments inheritance and the like for the internal code that makes them run. So interpreted C in not an impossibility, C++ wouldn't be either, but it wouldn't be a full implimentation. The problem is that as far as I know, no one has built an ActiveX based engine for it. Generally the trend has been to develope scripting languages that have the features you need for that. C++ tends to be far more complex than needed to do scripting.
This may just be being picky, but what you're describing isn't actually interpreting C - it's interpreting a C-like language. There's a huge difference between those two.
Interpreting C, in the proper sense of the term, would mean having an interpreter that could execute ANY C code and give proper results. And I doubt that MUDs actually have such interpreters. Their engines just implement the features of C - basically the syntax, basic statements, whatever - that they want to use, and then they leave the rest. For instance, could those interpreters handle malloc function calls and complete pointer manipulation?
Ok.. You may be right in the sense that it isn't true C, but then JavaScript isn't true Java, VBScript isn't true VB, etc. The engines doesn't compile any of those things into native code, thus malloc and the like would be handled by the engine, not directly. A C or C++ engine wouldn't be any different.
And by inheritance, I mean just that, the ability to have a single base class that you can instance and expand as needed. Maybe this is only true in LPC muds though. A lot of new ones seem to use databases heavilly, so when you make a new mob you are making a copy of some basic database entry, not creating an entirely new object based off a previous structure.
In any case. All scripts are interpreted. The may have the ability to compile themselves into a sort of tokenized form that executes like a real instruction set in the engine, but they are still being intepretted in the sence that they are not running native code. There is no reason why a limited form of C or C++ could not be designed to do this. There just aren't any around.
But you see, that's exactly my point. This C-like language wouldn't be C... and Javascript, VBscript don't pretend to be Java and VB, hence the script. They pretend to be small language SIMILAR to their "parent" in syntax, but don't make the claim at all that it's the same language, or even that you have the same functionality.
Inheritance in C in that case doesn't make a lot of sense to me. If you want to have inheritance, why bother with C and why not just use C++? Unless you're talking about "fake" inheritance, and don't actually have proper classes with methods and v-table lookups and all that. Still, I think it's odd to put inheritance into C, because that's already been done (with ObjectiveC and C++ for instance.)
I don't believe I ever said that a limited form of C/C++ (as in, a language that had similar syntax but not the same semantics and functionality) couldn't be implemented in a scripting form - in fact, I wrote a scripting engine for my MUD that uses a language I wrote that has syntax very similar to C. The whole point I was trying to make is that it isn't worth it in this case, as you're not adding functionality, you're just adding a new kind of syntax. And making a proper C interpreter engine that actually had full C functionality would not be an easy task at all.
Just browsing around sourceforge, and found this...
http://csl.sourceforge.net/csl.html
Its a C scripting language, which I havent read much about, but I was reading about it, and I remembered this discussion.
Hmm. Practically the first page of the manual nukes the idea of employing this. Basically you have 4 ways to link stuff into your program:
1. Code it directly.
2. Use a DLL, without any ActiveX support.
3. Use a DLL/EXE that has an imbedded table and supports the IUnknown interface.
4. Use a DLL/EXE that has an imbedded table and supports the IUnknown and Windows Scripting interfaces.
CSL is type 2, which means you have to directly link it into your program to use it. This is only one step above coding the entire thing yourself, in terms of the inflexibility and usefulness of it to us.
Type 3 ones, which are fairly easy to code are what most things, like databases and our mini-programs are built on. They can provide a program that wants to use them with a way to ask the DLL or EXE if it can do some task. Basically something like:
MyObject.QueryInterface("Picture", ...)
would ask myObject if it supported the interface for setting a picture. This makes it possible to either get a complete list of things it supports (using a different and slightly more annoying method) or attempting to use a command and having the control tell you if it would work. Example:
Maybe the first version only supported B&W, the next was 256 colors and the last is 32-bit. Your program and attempt to use Picture3, but if unable to (you have the wrong version), you can then try Picture2, then Picture1. Your program will thus still work, even if the version of the control is an old one. Or you can just have it scream that you need to upgrade.
Anyway.. Type 4, which implements the Active Script system needs to have IUnknown, so your program can ask if it supports some needed functions to be used in scripting. These are absolutely needed, since they include the methods needed to tell Mushclient when the script is done running code, let Mushclient call subs and functions in the script itself, etc. IE also used this interface to link things like buttons and stuff that it is displaying to the script, so when you click the button, it runs part of the script. Most scripts can't do this themselves, even if they do create the button itself.
The problem is that like virtually every actually *useful* piece of information, examples and explainations of the interface need for Active Scripting is probably buried someplace no one has a clue to look, or only comes with the super-professional-ultra-expensive-you'll-have-to-sell-your-sole-to-afford-this version of your favorite MS compiler. I certainly haven't had much luck finding usable information on it anyplace.
To use CSL with Mushclient, someone will need to build an Active Scripting 'wrapper' around the CSL code that provides the needed interfaces. :(
Couple times in this thread I've seen Java and JavaScript compared as if JavaScript is some kind of "light" Java scripting language. JavaScript and Java are not related except in that they both have a C-like syntax.
Prior to .NET, Visual Basic, Java and other things all used individual libraries. In other words, if you had a Java application it would need some file called Javarun.dll or something (I have no clue what it may be called). If you wrote a VB program, then it would need a file called vbrun300.dll or vbrun400.dll, or vbrun600.dll, etc. Each vbrun???.dll is a library that provides all the special gadgets that Visual Basic programs need to work, since they use pre-built 'libraries', instead of having the used design everything from the ground up.
The problem was that a) these where extra files you had to install to use anything, b) different versions where needed, depending on what version of VB they wrote it in, c) the libraries took up extra space in installation files that wasn;t always needed. Also, there was a completely different set of gadgets for VB, another for Java, another for C++, another for....
.NET was designed to solve this by providing a *single library* that all languages use. In theory, once installed, you never need to install a new version of those dlls to fix something that won't run (knowing Microsoft, this is probably not accurate... lol).
Basically.. It probably doesn't effect scripts, may effect how programs are written that are called through the script (since the original ActiveX COM has been replaced with COM+ in .NET) and the odds are about 50/50 whether or not it helps or hinders designing new programs to be used with Mushclient.
I think that C# is a cool gadget for writing plugins to MS applications (addins for office, etc.) Its platform- and Microsoft-dependency however makes me not want to spend too much time with it. It all depends on what the context of your question is.
Well Seawolf.. .NET completely changed the underlying architecture of the languages in some ways. One of these adjustments basically means that creating certain types of custom COM objects, like user controls, no longer works the same way or can actually be impossible to do. A lot of stuff you could do in VB 6.0 you can't duplicate in VB.NET because of it. Since COM is involved in these changes, it could concievably have a serious negative impact on designing programs and objects for use with Mushclient. Personally.. I have enough problems trying to adress 'basic' functionality in the existing VB, which involves simple things like, "gasp!", actually figuring out what the dimensions of a frames client area is at any given moment, without fighting the .NET system over even more things they left out of the new version of VB because of it.
Microsoft's trend in languages is much the same as in the OS, simplify the task of the end user, by streamlining tasks and making it easier to just plug parts into each other like a lego set. Unfortunately, if you ever played with legos, then you should recognize the side effect of this trend, the greater an greater reliance on big, prefab parts that look nice, but only let you build the model on the outside of the box. This is in contrast to the early days, when just building the spaceship or castle using the instructions was far more complex, but you could use all the smaller parts to build nearly anything you could imagine.
The newest trend around the corner for MS is not only to obfuscate the level of control you have in C# compared to what may have been possible in C++, but actually introducing something called XAML, which will let you design software like a web page. It appears that this is, at compile time, converted into C# instructions, which then get compiled. This is technically a good thing, since it makes designing simple programs easier, but it has two other effects - It lets MS dictate the interface, since 'their' decoder will decide what the C# code actually does and it could potentially seperate the coder even farther away from the ability to actually *code* anything.
The problem is that MS doesn't generally do this by adding an optional 'layer' in between the actually compiler and the code. It makes the whole process dependent on what 'they' think 'we' want or need. I would personally prefer if they started listening to what we want and need, not try to convince us that they know best. A complaint that is quite common among a lot of designers, who all complain that the only users MS pays any attention to are the majority of dumber users that think that a compiler in someone that stacks computers, rather than paying attention to the people that actually have a clue what tools are needed.
So.. From what I have heard:
Good things:
A single library instead of a mess of different ones.
Bad things:
Event less functionality in some cases.
Loss of existing functionality.
No fixes for existing problems that are already making desing difficult.
But heck.. I could be completely wrong, but past experience, things I have heard and the fact that the last 'simple' project in VB 6.0 required a week of hunting and help from several forums to get working 90% of the way I intended, all tend to make me suspicious of any great improvements in my ability to actually design anything *my way* in .NET. lol
VB.Net is a different language and the .NET platform if very different. You shouldn't have expected your VB apps to just pick up and move to VB.net without changes.
If you think there is less functionality, then I'm willing to bet a lot of money on the fact that you're not using it right. One could argue that perhaps some things shouldn't be so hard, but that's another topic.
Quote: 'their' decoder will decide what the C# code actually does and it could potentially seperate the coder even farther away from the ability to actually *code* anything.
Why is this a bad thing? There are many, many people who say that if all you have to deal with is high-level constructs, and no longer any low-level stuff, you lose a lot of hassle and can focus on solving a problem. Isn't that what VB is all about? This is only taking that same idea further. I'm surprised that you like VB but you don't like the idea of simplified programming.
Umm.. I am not using .NET at all. You can't simply shoehorn it into VB 6.0 and despite MS' apparently belief to the contrary, I don't have hundreds of dollars to upgrade every time they come out with a new compiler.
As for the comment about high level stuff... I have no problem with high level languages, they are very nice and make things a lot easier. My problem is that Microsoft's tradition with high level stuff is that the more easy to use and high level it gets, the less low level stuff you can even do at all. You see this in the OS, where under XP you either need a 3rd. party tool that basically does registry hacks or hack it yourself to make changes to some basic options that you could easilly tweak under 98 or even NT. It is about choice. VC++ was complicated, then came VB, where they took away the 'choice' to even do some things, but you could hand code User32.dll calls for 'some' things in and get around some limits. Now you have .NET, which not only, do to the changes in design, removes some options, it also seperates the coder even further from the option to do some things.
XAML seperates you even farther. The problem is that the page I saw showed XAML code and then "here is the equivalent C# code". This either means that it 'replaces' the function of a compiler or it translates 'to' C#. If the second is true, then you only have to deal with the limitations of C#. If instead it is really designed to be a completely seperate architecture, then once again, you lose any and all choice in what you can or can't do and on what level. And I don't know about you, but if I have trouble buying VB.NET, then having to run out an buy C#, VB.NET and some product that uses XAML, because I can't do anything really simple in C# or VB, but XAML is too limited, but again, I still can't do some things in VB at all, then...
Right now one project I want to do is hung up simply because a 'basic' funtion of the base frames used for all windows is not merely unavailable directly from VB, but because there isn't even an API you can use to access that level of function. MS never bothered to design one, since the only place 'they' use it is by reading the value, or within their *own* form designers. If there was an API for it, then anyone could write a non-MS approved language, complete with a full IDE that includes full support for design and runtime modes for objects. The solution... Spend weeks looking for a decent example of how it works and find almost nothing, or pay some other 3rd party for a $500 designer that you can't use anyway. Gee... Great choice.. But the fact is, MS provides virtually no documentation on using Ambient values, other than determining their current state. Even making them work in VC++ is such an insanely convoluted mess that just the macros used seem to span 5-6 different headers. They really don't seem to want anyone to know how to actually set them. This isn't low level machine language stuff, it is a *basic* property of all windows.
So, even in VC++, they intentionally leave out key documentation and obfuscate the operation of some things so you can't use them without wasting a lot of time and effort. This doesn't, as someone used to having the 'option' of using lower level things when needed, particularly impress me about MS compilers, or any of their other software for that matter.
Quote: My problem is that Microsoft's tradition with high level stuff is that the more easy to use and high level it gets, the less low level stuff you can even do at all.
That's just what high-level languages do, it's not Microsoft's fault.
Quote: You see this in the OS, where under XP you either need a 3rd. party tool that basically does registry hacks or hack it yourself to make changes to some basic options that you could easilly tweak under 98 or even NT.
Like what?
Quote: Now you have .NET, which not only, do to the changes in design, removes some options, it also seperates the coder even further from the option to do some things.
What options does it remove?
Quote: XAML seperates you even farther.
According to www.xaml.net:
--
The primary use of XAML is in the definition of Client User Interfaces, both describing the graphical layout of the interface, and tying user-Interface generated events to code.
--
In other words it's a specific tool, you shouldn't be using it for things it's not meant to do.
Quote: This doesn't, as someone used to having the 'option' of using lower level things when needed, particularly impress me about MS compilers, or any of their other software for that matter.
I think you're mixing up the MS compilers and the MS APIs. What kind of low level stuff are you trying to do that you can't in C++?
I think the problem here is just that you're not using the tool for the job... you're trying to make things do what they weren't really meant to do, so then no wonder it doesn't work exactly as you want it. :) Also, just because *you* want it done that way doesn't mean it should be that way; maybe they had their own design requirements when they made their decisions. MS may sometimes have its own agenda, but - for the most part - they aren't at all stupid.
If XP doesn't contain things you can't change within its own system, then why is there still a copy of TweakUI for it and most of the registry hacks at www.regedit.com almost all 2000/XP hacks? Ironically, everyone one of the hacks on the front page there today involve ways to secure the system from anyone changing certain settings or using certain services that MS never provided a direct way to disable (at least without disabling them completely, so they don't even run).
And yes, I understand what you mean by languages being 'designed' to do specific things. But lets look at C++ for a moment. You may have to be completely insane with the efficiency of modern compilers to want to do it, but it 'lets' you use assembly if/when you have to. VB lets you... use API calls, many of which should be functions inside the existing objects. Why for example do you need an API call to get the client rectangle of a window, but the window object is happy to supply you with full window size? Just because that is a property you need to set to use a window, *not* because it is actually useful for anyone trying to create something like a image browser or the like, where you may need to a) display one image for every 100 pixels. You can get the outer rectangle, but you have to 'guess' what the client area actually is. And that client area can change from machine to machine depending on the display settings someone used and thus how many pixels wide they made window borders. Guess what! You also can't get this information directly in VB, so you still can't calculate it without the API call. Why isn't it a property of the window object again???
I have no problem with the idea of using a tool for what it is designed for, but I get a bit annoyed when the only choice to fix a problem is to buy another multi-hundred dollar compiler from the same company, spend a month learning it, another month trying to figure out what I messed up when the program crashed, all because I need one function that the other language didn't bother to provide. The fact that I only have a stone age copy of VC++ from the days of 95 and I am pretty much clueless at coding in C++ anyway doesn't help my mood. I getter really frustrated when I look at MS' site for a clue how to use the API and it turns out you need the header files for VC++ anyway, since they decided to save space by not giving the actually values of any of the flags for those calls.
So, forgive me if I and a lot of other people think that the biggest issue with VB isn't its limitations, so much as the artificially induced limitations that MS gave it by deciding that certain basic information about the objects you use in it shouldn't be available without a) resorting to API calls or b) coding a few hundred lines of C++ into a new dll, just to get back 'one' feature they left out. That's just dumb imho. But then, relying on runtime libraries wasn't terribly bright either. What exactly prevented then from making VB a front end to VC++, so that the pre-compiler just translated the VB into C++ before compiling? I can't see how that would have been any different than using templates in VC++ to 'design' anything.
Anyway. My real problem.. I know that what I need I can do in a week with VB, if only it provided the one feature I need to complete it. I know it would take me months to do it in C++, since I am virtually clueless about that language in the first place and since I still don't really know how to do what I need in that. So, forgive me if I am a tad annoyed at what they left out, both of their own MSDN documentation *and* the language itself.
Oh wait.. I gues the MSDN does give one example of using ambient.usermode.. It refers to a program called Patron, which exists in at least 3-4 incarnations (the author of the Patron programs doesn't seem to have much imagination) and isn't actually available on the web or Microsoft's own site. It is however available from a probably out of print book written by someone affiliated to MS only by the fact that they published the pretty much useless 1-2 pages describing what the program did, but not actually how or with what code. It uses, drum roll please..., a .dll coded in C to manage it. That is the sum total of what you can actually figure out by reading the article. Amazing how their references to 'real' information is even worse than their own documentation. ;) lol
Quote: If XP doesn't contain things you can't change within its own system, then why is there still a copy of TweakUI for it and most of the registry hacks at www.regedit.com almost all 2000/XP hacks?
Hey - I didn't say XP couldn't be tweaked, I was asking what you can do in previous versions that you can't do in XP.
Quote: Ironically, everyone one of the hacks on the front page there today involve ways to secure the system from anyone changing certain settings or using certain services that MS never provided a direct way to disable (at least without disabling them completely, so they don't even run).
I guess people aren't aware of the group policy editor, or the local security settings? Yes, it's only on XP pro, but, well, XP home is not meant for the power user.
Quote: And yes, I understand what you mean by languages being 'designed' to do specific things. But lets look at C++ for a moment. You may have to be completely insane with the efficiency of modern compilers to want to do it, but it 'lets' you use assembly if/when you have to.
No - C++ doesn't "let" you use assembly - your *compiler* lets you use assembly.
Besides, weren't you the one complaining about not having low-level access? :P Why are you denigrating the use of assembly?
Quote: VB lets you... use API calls, many of which should be functions inside the existing objects. Why for example do you need an API call to get the client rectangle of a window, but the window object is happy to supply you with full window size?
Because it's not used enough. VB is not meant for "power apps" that would need to access such things.
Quote: You also can't get this information directly in VB, so you still can't calculate it without the API call. Why isn't it a property of the window object again???
Probably because the object is an abstraction, and itself may not be aware of the client rectangle. It doesn't need to be.
Quote: I getter really frustrated when I look at MS' site for a clue how to use the API and it turns out you need the header files for VC++ anyway, since they decided to save space by not giving the actually values of any of the flags for those calls.
Eh!! Of course they did. VB comes with an API explorer or something like that, that has a full database of all the API functions you can call, the constant values, etc. And if not, you can always check the VC++ MSDN documentation online for free.
Quote: So, forgive me if I and a lot of other people think that the biggest issue with VB isn't its limitations, so much as the artificially induced limitations that MS gave it by deciding that certain basic information about the objects you use in it shouldn't be available without a) resorting to API calls or b) coding a few hundred lines of C++ into a new dll, just to get back 'one' feature they left out.
You can't have your cake and eat it too. The language is meant to be simple, a high level abstraction to make basic GUIs easy to do for non-programmers.
Quote: That's just dumb imho. But then, relying on runtime libraries wasn't terribly bright either.
Umm, dude, *every single language* has a runtime library of some sort. Why shouldn't VB?
Amendment: Alright, perhaps not pure Assembly... what I meant is that every single higher level language - yes, even C - has a runtime library for the built-in language routines (like malloc, for example.)
Quote: What exactly prevented then from making VB a front end to VC++, so that the pre-compiler just translated the VB into C++ before compiling?
Because that wasn't the point of the language.
Quote: I can't see how that would have been any different than using templates in VC++ to 'design' anything.
I don't think you quite understand what C++ templates are. You don't "design" things - especially not GUIs - with templates. Templates are for generic programming.
Quote: Anyway. My real problem.. I know that what I need I can do in a week with VB, if only it provided the one feature I need to complete it.
I'm still not convinced that you can't. C++ makes the same API calls that VB does. You probably just haven't found the right one.
A minute of Googling revealed the GetClientRect function, which seems to do what you want.
Here is the MSDN documentation page.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Windowing/Windows/WindowReference/WindowFunctions/GetClientRect.asp
Although, Ksilyan, Shadowfyr was talking about "using" assembly in your C code, like... well, systemspeakers without headers, you actually code the assembly in the C compiler, he's not talking about once it compiles.
Also, XP home isnt 'meant' for power users. Theres just so much wrong with a OS being deficient in basic functions.
Thats all Im going to say, I really dont want to get in the middle of this.
My important stuff follows:
Anyway, Shadowfyr, stuff on ambient.usermode:
http://www.developerfusion.com/show/20/7/
http://www.aboutvb.de/kom/artikel/komlistitemeventscode.htm
http://pages.cpsc.ucalgary.ca/~saul/vb_examples/tutorial7/
Theres plenty more, google "ambient.usermode" and enjoy.
Quote: well, systemspeakers without headers, you actually code the assembly in the C compiler, he's not talking about once it compiles.
Right- what I meant is that it's not C++ or C per se that lets you do it, but rather the compiler that lets you insert snippets of assembly.
Quote: Theres just so much wrong with a OS being deficient in basic functions.
I think the link of causality is being reversed. They took out features to make it suitable for "normal people", therefore it's not meant for power users; it's not that the OS is "deficient" by accident or anything.
Actually Flannel, the point here is not that there are not a lot of sites about Ambient.UserMode. The issue is that they all only describe how to 'read' that property in order to change the behaviour of your code relative to the current mode. This is sort of pointless, since if you cannot actually 'set' this property on a container object, the only place you alternative behaviour becomes relevant is when importing your object into Microsoft Development Studio's form designer or other similar applications. It is a totally worthless property for your own programs, since unless you can actually set it, the alternative behaviour will *never* come into effect in your own applications.
As for Patron.. I can find at least 2-3 of the 'wrong' versions. One provides and example of creating an TCP/IP proxy (I used that to create my Phantom proxy for testing stuff in Mushclient), the other versions of it give examples of other 'tricks'. However, the problem is not finding a copy of the code for any 'one' of a dozen completey different, but unrelated programs called Patron, but finding the one that specifically belongs to the article about ambient properties. Someone else, besides me, already tried and completely failed to find the right one. I gave up after spending close to 48 hours trying to find the right Patron source.
Quote: I think the link of causality is being reversed. They took out features to make it suitable for "normal people", therefore it's not meant for power users; it's not that the OS is "deficient" by accident or anything.
Which brings me back to a quite common complaint amoung both power users, system administrators and other 'professional' users of the OS and the software from Microsoft that runs on it. They only pay attention to the needs of the loser, country bumpkin types that need it to be 'easier' to use and tend to completely ignore the users that have a clue what they are doing. Users that 'need' the option of doing something which the process of simplyfing it for the unwashed masses does not merely hide in a special tool or location, but all too often disables, removes or prevents them from doing at all. This is a bit like a car manufacturer deciding that two peddles and an ignition switch was confusing to some people and making the car so the moment you sit down in the seat the engine starts and how fast you go (or even if you stop) depends on depressing a single peddle. Never mind how inconvient this may be to the poor automechanic that has his hand stuck in the engine when someone sits in the driver seat to read the odometer or something. Or the mess that certain stunts and types of driving would become if it was literally impossible to break *and* apply gas to the engine at the same time.
After all, who cares about the 10% of the population that actually code or administrate systems? There are 500 times as many people that just need something they can plug into a wall socket and flip a switch. This is in fact the #1 reason why MS' past policies with security bit them in the ass. No unwashed masses computer user cared about firewalls or security holes, so system administrators and companies never got protected by them either. When MS added firewalls to the OS, it was still looked at not as a necessity, but merely an 'option' you could turn on when needed. Again, it bit them in the rear and the tech experts, who they didn't bother to initially listen to, shook their collective heads and proclaimed, "I told you so, maybe you will listen next time.." Nope, even MS' own internal memos have shown a general disregard for the very people that 'know' what the problems are and 'need' the sort of options MS removes in order to hyper-simplify every product they put out.
For the vast majority, MS systems aren't designed for developers. If you want to be a "real power user" go run *nix or something. That being said, XP-pro and Win2k are fairly decent. You still haven't really said what's so hidden/hard to do with them.
I'm not sure what's so bad about it though; think about it. You are a business. Are you going to satisfy the 90% of people, or the 10% of people? Like I said, if you want something that gives you real power, go run a *nix server. Then you may start appreciating some of the "easy features" of Windows that you criticize so much now. :)
Supposedly, they are addressing much of this in Longhorn, which is apparently geared towards developers. I'm not sure quite what they mean by that - I haven't looked into it too much - but that's just the buzz I'm hearing.
So hey Nick...while I'm wasting (everyones) time...what do you think of .net and C# and all that?
Hmmm - before I got a chance to reply the thread jumped a whole page size. :)
It's nice to see the old OS wars start up again, with some mild Microsoft-bashing thrown in.
My answer is that I haven't touched C# and .net and don't intend to, in the near future. Microsoft mean well in many cases, but they seem to be huge juggernaut that keep changing the operating system, interfaces, rules and everything else, just when people are getting used to them.
When I go to help people with their XP installations, for example, I have to hunt around to see under what nice "friendly" spot Microsoft have hidden their Network control panel, or their shared folders.
My problem is that I understand what the operating system is trying to do (eg. send data from one PC to another) but can't work out under what "wizard" or "helpful walk-through" thing they have hidden the configuration to it.
I had the same problem a few years ago with database access. First there was proprietary interfaces, then ODBC, then Microsoft added DAO, and then ADO, and then something else (Active Database?), each time changing the way you access a database, and just about when I was used to using the previous version. They may have thousands of programmers inventing all these new "better" way of doing database access, but I only have one brain, and can't keep up with their rule changes every year.
What Microsoft seem to be doing, intentionally or not, is to keep pushing you down a proprietary path. VB is a great example. Try running your VB programs (or MUSHclient plugins) on Linux. You can't, can you, because VB is proprietary. However C and C++ are not. I am guessing that C# and .net are also another attempt to bite at the "let's keep it proprietary" cherry.
Let's look at MUSHclient for an example. When I wrote that I had done (a year or so earlier) a programming course *run by Microsoft* in which they recommended using MFC (Microsoft Foundation Class library). It actually was a nice development environment, and made doing dialog boxes, menus etc. nice and easy.
However now that people as saying "how about MUSHclient on Linux?" or "MUSHclient on the Mac?" and I now see what has happened. MFC is Microsoft, and it is *not* simple to change to another way of doing things (eg. STL which I am gradually learning). Even STL (Standard Template Library) does not solve all the things that MFC does (like doing dialog boxes easily).
Someone had written something that did a similar thing to MFC and called it wxWindows, which I experimented with. Apparently Microsoft's lawyers got to them and it is now renamed wxWidgets. Seems you can't use the word "windows" these days any more. I suppose those things on the wall of my room will have to become "transparent viewing panels" now. ;)
An interesting comparison is the "help" given by Microsoft for the STL library compared to the help for their own MFC library.
Here is their description for "for_each":
for_each
template<class InIt, class Fun>
Fun for_each(InIt first, InIt last, Fun f);
The template function evaluates f(*(first + N)) once for
each N in the range [0, last - first). It then returns f.
The call f(*(first + N)) must not alter *(first + N).
See the related sample program.
To be honest, that description does not get me very excited, or even give me much idea of how to use it. Compare that to my description given on the web page:
My description there shows how to actually use for_each and gives examples of how useful it can be.
However Microsoft's help for its own MFC functions are much more detailed, with example programs, and example source supplied for complete solutions.
My point is that now I want to steer away from proprietary tools, and use "standard" tools. These would be:
C
C++
STL
Open source operating systems (eg. Linux, OpenBSD)
Open source web generation (eg. PHP)
Open source SQL databases
In recent projects, eg. writing a MUD server, whilst I compile on Visual C++ for ease of use, I make sure that the code compiles, and executes also under g++ on Linux, making any minor changes needed to ensure this happens. That way I know the server will also run on Linux, Mac OS/X and so on.
My other comment about high-level "solutions" is to invoke Gammon's Law:
Quote:
Gammon's Law
The solution cannot be simpler than the problem.
What this means is that you cannot make a really simple solution to a complex problem. I think some of the things you have been finding with VB have illustrated this. VB is great if you are writing a simple application - one that falls into the general area that they have simplified for you.
However as soon as you fall outside that "simplified area" you hit a brick wall of having to work out what VB "really does", or how to "get around" it, or how to call the low-level operating system call you would have used anyway if you had written the program in C in the first place.
What I have found on more than one occasion is that VB gives you the illusion that you will get the job done quickly, because you do indeed get 90% of the job done quickly. However that remaining 10% is what slows you right down.
So if you had a VB programmer and a C++ programmer pitted together to write an application you would probably find the VB programmer having a prototype up quickly that demonstrated a large amount of the end product, while the C++ programmer was working away with nothing to show, initially.
However towards the end, while the VB programmer was struggling to get from 91% to 95% completed, the C++ programmer would not hit that last road block, and finish the whole project, possibly earlier. Plus, the C++ solution would run faster, as it would not be interpreted, and would quite likely be portable to other operating systems a lot more easily.
Quote:
Shadowfyr:
.NET completely changed the underlying architecture of the languages in some ways. One of these adjustments basically means that creating certain types of custom COM objects, like user controls, no longer works the same way or can actually be impossible to do.
This is my point - Microsoft can, has, and will change things to suit their purpose. Whether it it to make things easier for programmers, keep things proprietary, or both.
However when did you last hear that a C++ program had to be rewritten because the C++ standard changed completely? Never.
Similarly with the STL library, you can use that now without worrying that it will be changed or become obsolete next year.
Is this really a surprise to anyone? A few comments from the famous Halloween Documents:
Halloween I>
Quote: To us, open-source licensing and the rights it grants to users and third parties are primary, and specific development practice varies ad-hoc in a way not especially coupled to our license variations. In this Microsoft taxonomy, on the other hand, the central distinction is who has write access to a privileged central code base.
Quote: Release early. Release often. And listen to your customers.
This is a classic play out of the Microsoft handbook. OSS advocates will note, however, that their release-feedback cycle is potentially an order of magnitude faster than commercial software's.
...
The difference here is, in every release cycle Microsoft always listens to its most ignorant customers. This is the key to dumbing down each release cycle of software for further assaulting the non-PC population. Linux and OS/2 developers, OTOH, tend to listen to their smartest customers. This necessarily limits the initial appeal of the operating system, while enhancing its long-term benefits. Perhaps only a monopolist like Microsoft could get away with selling worse products each generation -- products focused so narrowly on the least-technical member of the consumer base that they necessarily sacrifice technical excellence.
Halloween II>
Quote: HTTP-DAV. DAV is complex and the protocol spec provides an infinite level of implementation complexity for various applications (e.g. the design for Exchange over DAV is good but certainly not the single obvious design). Apache will be hard pressed to pick and choose the correct first areas of DAV to implement.
This was ironically several months after Apache had already provided 'full' support for everything in HTTP-DAV. But shows their tactics. Make everything completely incompatible and platform dependent, so it will only work under Windows, then claim that everyone else's products are inferior, because they can't duplicate something that MS has obfuscated to the point no one else can ever use it. It has never worked, but MS still tries.
As for the wxWindows thing you mentioned. Didn't know that, but I am going to have a good laugh when 'Windows' is inevitably declaired a generic term that cannot be trademarked. There is more than enough evidence to support this and MS is doing everything they can to either bankrupt Linspire or delay the court case to prevent it. lol
Oh yeah.. the halloween docs are at: http://www.opensource.org/halloween/
My problem is that I understand what the operating system is trying to do (eg. send data from one PC to another) but can't work out under what "wizard" or "helpful walk-through" thing they have hidden the configuration to it.
Amen to that, I've got an OEM version of WinXP Home with a new desktop, and since the WTO talks around here haven't died yet and as a result - getting a pirated version of Win98 for 3$ is a problem right now, I decided to stick with what I have. I fumed almost to the point of setting the chair under me on fire when I tried to set up my old network connections.
My point is that now I want to steer away from proprietary tools, and use "standard" tools. These would be:
...Open source operating systems (eg. Linux, OpenBSD)
Amen to that also, I am utterly fed up with Microsoft and what it puts out these days. I've basically replaced the 2 out of 3 software products I rely on heavily - Mozilla Firefox for IE, and OpenOffice for MSOffice, the only thing that's keeping me from paying those 28$ for a Linux installation and jumping off this train without a driver is Mushclient.
Why do you have to pay $28? And you can use VMware or WINE to run MUclient, I am sure it will run perfectly... Of course, you will also need to emulate windows, but it's not that big a deal, i think :)
It won't run perfectly. Unless you are using one of several expensive products that exist to support 'full' windows emulation, WINE and most others lack COM support. For most of us, COM and the scripting that depends on it is the #1 reason for using Mushclient.
I have given some thought to what you might be able to do with some sort of system that used TCP/IP to talk to a script, the same way that COM now does. However, this would require special script engines that supported it. You would basically be hacking an existing Linux script system to impliment it, or designing one of your own. As big a pain in the ass that everything else Microsoft make is, COM is one things they came up with that simplifies life a lot. Too bad it is also often the #1 security flaw on the machine, especially when talking about the wider ranging DCOM. lol Doing even half of what you can do with ease using scripting under Windows is likely to be far more than trivial under Linux. :(
I've never heard of VMware before. I'll look into it, thanks. As for the need to pay 28$... If you know a way to get it for free then I'd appreciate it, however according to my calculations it would be cheaper and a whole lot more convenient to pay that much to order it online than to download the distribution and then burn it on CDs. Besides, it's a Russian company, a good distribution (from what I've heard), and not much money at all. I don't mind paying 30$ for an OS with life-time free upgrades, I do mind paying 200$ every 2 years though. As long as Windows went for nearly free here, I was more or less happy to use it, now that it looks like it's going to cost as much as it does in the States Windows has lost me as one of its users.
Ack, VMware actually costs over 200 dollars. I'd rather get myself another hard drive for that money to install an extra OS on and wait for Mushclient possibly getting ported while I am getting accustomed to a new environment.
There are sites where people download the distros and burn them and sell them to you for like $3 or $6 or something... Also, your local computer shop should be able to copy linux for a small fee... And yes, VMware may be $200 but you can download a trial version and see if you like it, and maybe extend the trial *wink* :p
Nah, too much bother with VMware. I can live with Windowing for Mushclient. As for downloading Linux, things are different here. It's not too simple for an individual, and even a company, to transfer or receive money across the border due to a pretty harsh exchange regime. You can sign on to PayPal if you live in Sri Lanka, but not if you are in RF. Hopefully that'll change soon, since there's a new and more liberal law in the making, but for now I have to watch Mushclient's nag screen and pay 30$ instead of 3$ because that's what the mainstream Linux distributions go for around here :(
$30 sounds about right, but it is totally worth it. You pay i-don't-know-how-much for windows and you get a cd with a sticker, and you pay $30 for linux and you get a crate full of CDs, DVDs and books, user manuals, and whatnot. I'd pay $30 for a linux distro... SuSE perhaps :p
Dont know about the other Linux distributions but Redhat maintains a free download from their website, mind you they're BIG images but theyre free nonetheless (or should be unless theyve done something really wierd in the EC)
RH Linux 9 is actually being terminated - well, it hit its end of life. If you want to get upgrades, you need to go to RH Entreprise Linux, or go to Fedora which is the open-source continuation of RH Linux.
If you do download disc images.. You are better off using the Bittorrent links. It is much faster (like double the speed). For example, I downloaded an ISO of the Linspire version of linux, just to see if it was any good and because I could at the time get it for free at the time to anyone that could figure out the secret code. ;) My normal transfer rate on this dial-up service I have is about 2.7k/s, when it is a *good* ftp server. The Bittorrent system gave me 6k/s almost continuously. Even for broadband users, it is better if possible to get the Bittorrent link when one is available.
Bittorrent also uses its own internal checksums, so once completes a download, then odds are you have a complete file, something others don't necessarilly guarrenty, even for normal FTP servers. You can also interrupt the dowload and restart it anytime after. I wish some abandonware game sites would use it...
Oh, and just to point out. The newest realease of Fedora (core 2 release 3) now included the 2.6 fully premptive kernel, new security features you can turn on and other improvements. Sadly, it would take me a week to download on dial-up, even with the Bittorrent client, so I am not going to do it any time soon. :(
I had VMware (for Mac) when it was released by Connectix or whoever it was, but it doesn't run under the latest Mac operating system. Somewhat infuriatingly, there was no upgrade path as Microsoft have taken over VMware, and it costs something like $AUD 600 for a new copy.
VMware worked fine, I used to run MUSHclient under it, under "Windows 95" on Mac OS/X. Maybe slightly slow, but pretty good. However, no more. Various (unprintable) thoughts passed through my brain when I realised that the $200-odd I paid for VMware is now wasted money, and I resolved not to get caught in that trap again.
Quote:
For most of us, COM and the scripting that depends on it is the #1 reason for using Mushclient.
If I thought a lot of people were using MUSHclient on Linux, and I also thought that some at least were paying for it, I would think of adding a scripting engine that would work on Wine (ie. native to MUSHclient).
This wouldn't be a huge deal, and would probably look similar to JScript (ie. C-like). There didn't seem much point in the past, as the other script engines worked OK, but I can see it would be useful under Wine. That is, unless you can get COM to work on Wine, then just start MUSHclient up without the /wine command-line switch. And, install the VBscript DLL. I haven't had that work for me, but maybe the later versions of Wine would support it.
Hello my good men!
I didn't even realize thi had gotten more replies...sorry.
The only thing I don't like about .NET is having to download a 21 meg redist to do whatever it is you want to do, and that whatever it is is fairly rare right about now.
However, some of you may be interested in this...or may not.
http://go-mono.com/
The Mono project, which just went beta, being a Linux (and windows and Mac OS X apparently...) version of .NET stuff.
http://www.go-mono.org/faq.html
Nick, that's not VMware, that's Virtual PC, which does the same... Microsoft has acquired Connectix but they will continue development on Virtual PC. I like VMware better though.
By the way, I know this is off topic, but I'd like to try Linux out. I installed RedHat but it looks sloppy (installed all packages and still asked me for a CD to do some administrative tasks which it couldn't find even when I inserted, and was overall a bit messy). I don't mind it being moderately difficult for Linux newbies, I just want it to be robust. Any ideas?
If it asked you for more packages after installation, then undoubtedly you didn't install it all right. When I installed from the 3 RH Linux 9 CDs, I had no trouble at all. Then again, I knew what I wanted. :) If you have the disk space.. just install everything, it'll be easier that way.
Different. "Better" depends on what youre looking for.
As your obviously not ignorant to coding, you might want to consider running Gnome or something. Theres TONS of choices. You really should do your homework before running off and buying something. Obviously downloading you can be wimsical.
Theres a lot of things people arent liking about Fedora. Talk about the people in charge not listening to the users, about which things to impliment/remove/etc. Thats just chatter Ive been hearing though.
Seriously though, theres enough distros out there that you should be able to find one thats not proprietary. Unless youre looking for something extremely specific.
Ah, thanks. I want to try out SuSE, I downloaded the LiveEval CD but haven't looked at it a lot... I tried to find SuSE 9 for download on their site but they aren't offering it... I'll download/get a few distros and choose the one I like best, thanks again.
As for Red Hat, it *should* install without any difficulties. I certainly did for RH 7 and 8 I think. Not sure what the latest version is, unlike Windows there is no great need to keep updating.
Once installed with Gnome or KDE as the window manager, they look remarkably similar to Windows these days, so a Windows user should not have any difficulty using them.
Overall Linux is getting a very "smooth" look, with integrated web browser, and a file browser that is like the more recent versions of Windows, where you can type in a folder address (eg. /home/nick/muds ) or a web URL, and have it open it appropriately.
In fact, once you are used to it, the general approach in Unix of having a root directory with subdirectories is much friendlier than the old C:, D: and E: stuff we use under Windows.
Nowadays with big hard disks I have my disk partitioned into multiple logical drives, and can never remember where I put things like my web downloads (is it G: or H: ?) however under Unix you would just have them in /downloads and worry about which logical or physical disk that was actually on in your system configuration.
I agree, the latest versions of Linux look very impressive, but (to me, at least) they look a bit sloppy, as if they were built on top of another architecture as an afterthought. I can only speak for RH, that's the one I used, I imagine other distros may be better. The trick with mounting drives is nifty, although I imagine you can do it in XP too...
Yes, you can. I just looked in Windows Help and found the command mountvol. I mounted my downloads drive in the directory c:\downloads, and it's as if the entire drive is there. Cool trick :p
Quote: Nowadays with big hard disks I have my disk partitioned into multiple logical drives, and can never remember where I put things like my web downloads (is it G: or H: ?) however under Unix you would just have them in /downloads and worry about which logical or physical disk that was actually on in your system configuration.
Why partition though?
I have everything on c:, and then use the 'subst' command to have W: for example, where W: is an alias to c:\internet\apache\whatever-else-it-is-to-get-to-html-home. Similar for p:\, t:\ (programming and temp.)
That works, but it is generally better to partition your disk so you have your files on a partition different than the one you have windows on, in case they crash or whatever... It's nice to have all your files on a harddrive because you know where everything is, but I have 4 HDDs and I can never remember where everything is :p
If your disk crashes, then the whole thing dies, no matter what your partitions are. I've heard from many places that the whole "partition for safety" thing is a complete myth.
But yes, if you have four physical drives (as opposed to partitioned, logical drives), then you do need to partition them . . . because of the very nature of the drive. :)
The main reason partitions existed recently was because the filesystems couldn't handle a drive bigger than 2gb (fat16) and then fat32 couldn't handle files bigger than 4gb. So back in the days (but not way back), you *had* to partition your drive if you were running fat16.
Yeah. Partitioning drives now is only real useful to keep 'data' seperate from the OS and programs. If you need to reinstall (say your running Micro$haft Winblows or something), then it is a lot easier to store all your data on the second partition than to have to backup every file on the drive you 'think' you need to keep and miss something, then reformat and reinstall. Of course, since everything MS makes hides data in weird places and even Opera started doing this in new versions, you still have to force these programs to store your settings, email, etc. on the second partition, but... I have been trying off and on to get all the files off my non-multi-partitioned drive for weeks, but since I don't want to miss anything important, I have been reluctant to finish. lol
I was saying what Shadowfyr said, that if you have to reinstall because of OS crashes, you don't have to lose all your data if you have multiple partitions...
Even that isn't a particularly good idea. If your OS "crashes", you should format and reinstall everything anyways. If you know what you're doing it's not very hard to figure out what you need to keep and what you don't need. Generally you throw away everything that you didn't put there (i.e. things that got installed), and you keep all of your files.
By the way, what do you mean by an OS "crashing"? :P Never happened to me before...
If you know what you're doing it's not very hard to figure out what you need to keep and what you don't need.
If you have 160 GB worth of files, you'll have to copy them somewhere else when you format, whereas you could just have them in another partition and be happy. And, if your OS has never crashed on you, it's because you don't mess with it enough :p Anyway, this thread is waaaay off topic, we should stop here ;p
Quote: And, if your OS has never crashed on you, it's because you don't mess with it enough :p
Or maybe I know how to mess with it *grin*
Seriously though, what do you mean by an OS crashing? What does it do (or not do)?
Besides, you can always boot up in DOS, delete the Windows directory, and reinstall. No problems... you keep all your data, everything is happy, life is fine, and the birds are singing. No need for partitions. :)
Sometimes windows refuses to boot. For example, I installed Linux on another partition, XP saw that the partition table had changed and decided it didn't like its letter any more, so it assigned its partition a different letter. The Linux partition was not even before the XP partition, but XP decided it should change the drive letter of the OS... Or another time, when I install the (admittedly beta :P) XP SP2, XP just refused to boot... I ended up deleting each SP2 file by hand and replacing them with the original versions. Deleting the windows directory doesn't do anything, because in order to reinstall XP, they must format the entire drive, most of the time. Whenever the setup program feels like it, it presents you with an option to install to that drive without overwriting, but it's messy. Anyway, there's no point in arguing what's better, each person can use whatever they think suits them :p
Mono just went 1.0....if you really wanted to go cross platform thats one way to do it :)
http://www.mono-project.com
from the release notes:
Novell is proud to introduce Mono 1.0: an open source implementation of the .NET framework for use on Linux, Unix and Windows systems. Mono consists of:
A cross platform ECMA CLI runtime engine.
A cross platform IKVM Java runtime engine.
C# 1.0 compiler.
Development toolchain.
Class libraries implementing the .NET 1.1 profile.
The Gtk# 1.0 GUI programming toolkit.
Mono specific libraries.
Third party convenience libraries bundled with the release.
GNU Classpath for the CLI.
Visual Basic runtime.
The Mono Project:
Provides a superior development environment for writing Linux applications with unprecedented productivity.
Allows developers to write rich client, web services and server-side applications and deploy them on Linux, Solaris, MacOS X, Windows NT/XP and various other Unix systems on a variety of architectures.
Delivers tools that facilitate the creation of product APIs and SDKs that are language independent across multiple operating systems.
...blahblahblahblah
Quote: i think Red Hats goin a lil too far with this enthusiast thing.
I mean cutting egde is cool, and bleeding edge is interesting, but carved up into tiny pieces edge isn't much fun.
It wasn't exactly Red Hat's fault. The 2.6 kernel has been in developement for some time and was assumed stable when finally released. The partition eating only happens on "some" older motherboards. The reason is due to a bug in the System bios that misreports information about the partition layout in an older format that XP still uses during bootup, but with has been replaced in every other OS by the use of the more reliable and modern method (LBA).
Basically:
1. Windows XP asks for partition info and gets: Sector 1 - yadda.. from the BIOS on drive C, then writes that into the partition table for the 'old' method.
2. You install Red Hat, which asks the hardware for info on the partition and writes that into the partition table, using the new method.
3. Windows XP boots, asks BIOS what the physical layout of the drive it is on is, looks in the drives partition table, finds information that is now incorrect and attempts to reload its bootloader from the physical location on the drive that 'used' to correctly refer to the logical location of that same data. Instead, the drive redirects it to the new 'logical' location pointed to by that info and Windows can't load.
This only happens on systems whose BIOS incorrectly report the 'true' physical layout of the drive, instead of the 'current' layout after being repartitioned. So, it is XP that is screwing up, not Linux. And it effects all Linux versons with the new kernel, since 2.6 tried to speed up loading by removing some files that would have normally checked for this BIOS problem and fixed it by writing what was actually incorrect info into the partition table for the old addressing method. Or at least that is what I understand about it anyway.
WINE and most others lack COM support. For most of us, COM and the scripting that depends on it is the #1 reason for using Mushclient.
MUSHclient's support of Lua in recent versions is not dependent upon COM, so that makes it a viable option to use MUSHclient on Linux (including scripting).