Slashdot Mirror

Say what you want, the Unix trademark is owned by The Open Group.


The suit by SCO against IBM, if it involved Unix, then The Open Group has the final say.

Say what you want, the Unix trademark is owned by The Open Group.


The suit by SCO against IBM, if it involved Unix, then The Open Group has the final say.

... according to RMS .DLLs don't count as shared libraries, since you can obtain the adress and call it directly.

So... anyone care to explain to me how *nix manages the magic of executing code contained within an SO without knowing what it's address is? That's pretty damn impressive...

Sarcasm aside, I doubt that this was RMS's response. Whatever the OS - *nix, Windows, MacOS, Be, whatever - shared libraries offer a fairly uniform subset of capabilities. The two most basic are the ability to load a shared library into your memory space, and to get the address of a variable or block of code contained within the libary. Both of these are pretty much required in order to make used of a shared library.

Don't feel like you need to take my word for it, though:

... according to RMS .DLLs don't count as shared libraries, since you can obtain the adress and call it directly.

So... anyone care to explain to me how *nix manages the magic of executing code contained within an SO without knowing what it's address is? That's pretty damn impressive...

Sarcasm aside, I doubt that this was RMS's response. Whatever the OS - *nix, Windows, MacOS, Be, whatever - shared libraries offer a fairly uniform subset of capabilities. The two most basic are the ability to load a shared library into your memory space, and to get the address of a variable or block of code contained within the libary. Both of these are pretty much required in order to make used of a shared library.

Don't feel like you need to take my word for it, though:

... according to RMS .DLLs don't count as shared libraries, since you can obtain the adress and call it directly.

So... anyone care to explain to me how *nix manages the magic of executing code contained within an SO without knowing what it's address is? That's pretty damn impressive...

Sarcasm aside, I doubt that this was RMS's response. Whatever the OS - *nix, Windows, MacOS, Be, whatever - shared libraries offer a fairly uniform subset of capabilities. The two most basic are the ability to load a shared library into your memory space, and to get the address of a variable or block of code contained within the libary. Both of these are pretty much required in order to make used of a shared library.

Don't feel like you need to take my word for it, though:

... according to RMS .DLLs don't count as shared libraries, since you can obtain the adress and call it directly.

So... anyone care to explain to me how *nix manages the magic of executing code contained within an SO without knowing what it's address is? That's pretty damn impressive...

Sarcasm aside, I doubt that this was RMS's response. Whatever the OS - *nix, Windows, MacOS, Be, whatever - shared libraries offer a fairly uniform subset of capabilities. The two most basic are the ability to load a shared library into your memory space, and to get the address of a variable or block of code contained within the libary. Both of these are pretty much required in order to make used of a shared library.

Don't feel like you need to take my word for it, though:

COM (including DCOM, Service Control Manager, Structured Storage, Monikers and Automation), MS-RPC, Registry, and the Windows NT® Distributed Security provider

COM (including DCOM, Service Control Manager, Structured Storage, Monikers and Automation), MS-RPC, Registry, and the Windows NT® Distributed Security provider

or the horrific MS-RPC protocols

That's not MS's fault...they are binary compatible with DCE. Function names and everything are all the same. I know, I suffered for years as a DCE programmer.

Totally agree that SOAP is cool.

The ability of this algorithm to generate "globally" or "universally" unique identifiers relies in part on the fact that network adapters contain a node address which is issued in blocks to network card manufacturers by the IEEE, so is guaranteed to be unique. Here's some info about UUID generation.

While processor IDs can be used to identify a system, there currently isn't widespread use of these numbers in standard software components.

Hi Michael!

This is a huge problem for linux. We need a standard API for companies to seriously be able to develop software in linux.

Linux has a lot of problems, and this is not a member of that set. Strictly speaking, X is not part of linux. You might mean, "We had some problems getting our product to work in a linux environment," but I would appreciate if you would say that. It would be one thing if you were Netscape, and not some extreme late-comer with a high priced product. I disagree that having companies develop seriously for linux is any particular help (see: jouraling file systems, web servers, the OS itself), but, let me see if I can offer some solutions.

You can: buy a copy of.. MOTIF!

Or you can use GTK, (which runs on unix, windows, and beos) or Qt, (runs on unix and windows). As someone else pointed out, any distro that has X is prolly gonna include both of these toolkits.

Also, you fail to mention which sort of API you're looking for, but I'm assuming the gui-toolkit kind of thing. Please clarify a little if I'm wrong.

To preserve our freedoms by convincing corporations to free their software, we need to have a unified, standard, rock solid API for developing large scale applications.

Are you just trolling here? :P

way to implement Canvas, so of course they asked me about the API. The response - that there is no really standard XFree86 api that is supported by the linx community

Now I know this is a troll. Management asked you about an API? Uh uh, no way. Managers don't ask about things like APIs. :P And, duh, giving them the response 'there isn't one' is dumb on two counts. Dumb one, because it's just plain false - you can certainly use the athena widget set if you need guaranteed compliance, and dumb two because, even if it was true, you coulda just lied about it. Lucky for you, it wasn't true, just wrong.

ut, if we could've gone straight into the API and began hacking away, I'm sure those months could've been spent porting to a native app.

Look, are you suggesting that porting something from the MSFC to X should be as easy as a recompile? I mean, aren't you ignoring the fact that what you're REALLY facing is not 'lack of a standard linux/X api" but rather "the quagmire of bullshit one must deal with when porting ANY application to Win32 to Unix (or vice versa)?" I mean, come on, does your application run on some X emulation layer in windows? Noooo, it doesn't (wild guess, there), so it doesn't use any sort of X API, so having one for linux would have saved you exactly dick.

And of course whatever we decide on as a standard will have to be GPL'd..

From the canvas download page:

4.You may not modify, rent, resell for profit, distribute or create derivative works based on the Software or any part thereof.

So you can include it as part of your $375.00 gimp clone? No thankee.

Also, on mention of netscape, does anyone know how the original netscape did it? Did they write their own toolkit for each OS?

--
blue