Slashdot Mirror

The one thing Cobol does well is formatted output. CSV is just a special formatted output.
http://www.csis.ul.ie/cobol/co...

Wouldn't it be better to write in a language where simple things DON'T need commenting?

You mean, like COBOL?

You didn't hurt my feelings. I haven't written a line of COBOL since the summer of 1988. Rather, I was objecting to arrant nonsense masquerading as authoritative-sounding statements. That kind of thing can harm the reputation of Slashdot, you know.

all ISAMs are relational databases

Any defense you attempt of that proposition will only land you deeper in the tall grass. ISAM can't be "used as" a relational database because it lacks the fundamental facilities.

The most widely accepted informed definition of the relational model is the three-part test Codd described in 1978: structure, operations, and constraints. ISAM includes no algebra and very little in the way of constraint enforcement. It also fails most of Codd's 12 rules.

I think you might mean that ISAM files have keys, and that ISAM files can be arranged in ways that mimic normal forms. The comparison is superficially appealing and logically vacant. Sorry.

However, secure code does not use the SQL front end as such.

Do please tell. I'd especially like to know what "as such" means in that sentence. Googling "isam db2 site:ibm.com" fails to turn up anything relevant. Searching DB2 Documentation for "isam"s turned up nothing.

I'm not against the idea of using stored procedures.... So long as the stored procedures are required to check the format of their parameters

No, that's unnecessary for purposes of security. Again, one of the three legs of the relational model is constraints. The DBMS is perfectly capable — more capable than the stored procedure, more than the application — of preventing inconsistent data from entering the database. It can't ensure correctness; no mere machine can. But only the DBMS can enforce referential integrity and declared constraints versus other contemporaneous processes.

But you're right that if the webserver can only execute stored procedures and has no other rights in the DBMS, then the data are absolutely safe from arbitrary manipulation through SQL injection. (Yes, I understand the procedure could be written to execute its parameters as code. But anyone letting data in any form be executed in a web environment might as well start looking for other work now. Why wait until the fan gets dirty?)

By contrast, no file system offers any such protection. If the webserver can access any part of the file, it can access the whole file. Own the server and you own the data.

SQL is too generic for a secure system

I don't know what that means. I can't even venture a guess. I guess Lisp is too generic too for a secure system. That explains why Paul Graham is sleeping under bridges instead of funding startups.

I'm amazed ... you're defending a COBOL as not being crippled ... you can do absolutely anything, just need the APIs

I'm not defending COBOL. I can think of a dozen problems with it. I'm ridiculing the crippled/generic taxonomy you proposed. C has no I/O capability and no memory management save static storage and the stack. What can anyone do with such a toy? Exactly the same is true for Java. COBOL on the other hand, like Pascal, at least defines I/O in the language. Even with the stdio library, can you do in C what COBOL does in 64 lines?

Your basic assertion seems to be that a simple system is less vulnerable than a complicated one. While that's partly true, I have to remind you of Einstein's dictum to make things as simple as possible but no simpler. When you recommend eschewing tcp/ip as "too complex", I see an invitation to reinvent it badly. It's not easy to improve on the socket mode

I don't know about BSD, but Linux now uses the 2Q allocator. This means that the cache will be released shortly, unless it is accessed a second time. This should prevent updatedb etc. from forcing out all other pages out of RAM by trying to cache the entire contents of the harddisk.

It's not a difficult language, only very clunky. I learned it by first lying to get a job, then writing programs with the manual beside me; and that was the IBM mainframe COBOL manual, not the easiest read in the world. Here is a link to where you can supposedly get a free COBOL compiler for Linux:

http://www.open-cobol.org/

And Wikipedia has a link to the following tutorial:

http://www.csis.ul.ie/cobol/default.htm

Apparently the object oriented pendant to C++ would have to be called "ADD 1 TO COBOL".

Better than COME FROM or PERFORM A THRU B.

For anyone who's curious about COBOL syntax, here's a sample named AcmeStockReorder.

Personally, I have only one question.

WHY IS THE PROGRAM SCREAMING AT ME?!?!

and, for the record, I wish to make the following statement.

MY BRAIN IS LEAKING - FOR THE LOVE OF GOD DO NOT LOOK AT THE CODE!! GAAH!!!

Have a nice day.

Learning COBOL is pretty simple. There is a great tutorial at http://www.csis.ul.ie/cobol/default.htm. COBOL is meant to be an easy language to learn. It's not object-oriented, it doesn't have a scope, so it is obsolete by today's programming standards. The one problem I've found with most COBOL programs is that they were written by very old school programmers that would code values directly into the program (rather than in a configuration file or table). There is usually a veil of secrecy too, mostly for the purpose of job security, but sometimes just because the programmer has forgotten whatever they programmed, and didn't bother commenting.

You can make some useful call graphs with codeviz + graphviz. I sometimes find this useful for tracing the heirarchy of abstraction through a set of C source files.

http://www.csn.ul.ie/~mel/projects/codeviz/

Take a look at this conference, on auditory display: ICAD2005 and this cool paper from about 1996.

This Far Side is also pretty good - "Einstein discovers that time is actually money"

Personal skill at art is something that is teachable and can be learned. Objects look the way they do because of where they are in relation to the viewer and what their dimensions are. Similarly light has rules which you can learn if you are to duplicate the illusion of light in a 2d representation like a drawing. Textures also have rules and so on. It's all about drawing what you see and not what you think is there. Sure there are people who have this ability from early on but the rest of us can learn very quickly.

Math is also teachable, but that doesn't mean that everyone has a mathematician inside them.

Your viewpoint seems to be heavily influenced by Drawing on the Right Side of the Brain, which presumes as a basic tenet that drawing is teachable. Perhaps your mistake is then making the leap that "skill at art" is teachable. While the book offers encouragement to those who (think they) can't draw, it does not address the not-so-encouraging point that spatial intelligence can't really be taught (but maybe simulated). In the visual arts, observation requires more than just the sense of sight, and even the vital criteria of awareness, sensitivity, presence of mind, and technical ability don't inherently translate to the ability to transcode your sensory input into something personal, meaningful, powerful, and coherent; the ability to do so is "skill at art".

A great deal more can said about this, but in essence I must respectfully disagree with your hypothesis.

As for the question of what non-artists need to build consumable graphic art, lots of people have offered useful nuggets of advice, but I would add: learn some basic color theory, and appreciate the value of understatement.

In particular, read section 6 in this part of the original documentation.

Hydan merely takes this technique that was invented by Eric in 1986, and turns it into a general-purpose Steganography algorithm. It is not anything new.

Never heard of Windows Meta Files (.wmf) ?. They were quite popular for storing vector graphics in the days of 3.0 and 3.11. You can probably still find some if you look hard enough, but of course nobody uses them anymore these days.

Take your paranoid fantasies somewhere where people don't know enough to refute them.

First, when you compile an EXE file with MS tools, it follows a format called the Portable Executable format[1]. You can verify this by opening up the EXE in a hex editor. There are a few headers, a few sections for code and data, and maybe a debug section. There isn't a section called ".backdoor" or ".spyonuser". By examining it very carefully, it might be possible to determine which version of Windows produced it and what compiler, but you aren't going to find your MAC address, name, street address, and favorite color anywhere.

Second, if you're talking about a network backdoor, that's extremely unlikely also. You can see someone using a backdoor on a Backdoors aresimple packet dump. Set up a packet sniffer between your computer and your internet connection and watch for strange packets. Write a virus or something, and see if someone from MS makes a connection to your computer. If you're so paranoid as to think that MS has trojaned all the routers, switches and hubs in the world so as to make it completely impossible to trace, go see a psychiatrist.

[1] - Reference for the PE format: here

Could somebody please tell me whether they've pam_ified LoginWindow on OS X after 1.28? What's the point of including pam in your system, linking ssh and the rest of them against it, but not linking LoginWindow (the main login screen on OSX) to pam, thus making it useless for centralizing authentication.

pam_smb works a treat on OSX, I can authenticate ssh logins to our NT domain, but the actual local login window on OSX takes not a blind bit of notice of pam, making it not-so-useful.

Does anyone know of a similar tool for Java? I'm currently doing a project where I need to read/debug loads of Java code. This doesn't bother me, but I could use all the help I can get and after reading the Codeviz' homepage, I'm sure such a tool would be useful in a Java environment.

via the Pluggable Authentication Modules (PAM).

pam_smb
PAM module list

America's privatized health care has created the world's leading health care industry. Why do you think every foreigner who can afford to, comes to US clinics for surgeries or treatments?

That's a common misperception.Ex. 1 Ex. 2 Ex. 3 Among many, I'll let you do the Googling.

Contrary to your claim, free-market privatization has proven to be the biggest asset of every American endeavor it has been a part of.

This somewhat true, however, it is not free-market. This is total corporate welfare/subsidies on a mass scale. Take, for example, the Marshal Plan. After WWII, there was plenty of money in Europe for the reconstruction, but U.S. planners preferred that wealthy Europeans put their money in U.S. banks, while American companies reconstructed Europe. Who paid for the reconstruction? U.S. tax payers. So U.S. tax payers paid for the reconstruction of Europe and American construction companies made tons of money. And so did U.S. banks, who benefited from the huge influx of European money. That is not "free-market" by any stretch.

If you want a really well-constructed picture of all this, check out Understanding Power by Noam Chomsky.

this is the potential future of computer science in the United States

My aren't WE large headed!! This does not just happen across the pond there, it happens in Europe too. In fact, MS has offered academic institution(s) here in Ireland _really_ cheap setups in the past, and there were 2 reasons.

o To lock them in (obviously)
o To test out NT in a large network enviornment

And boy was NT tested (some of the curses thrown at it were impressive. It caused an awful lot of hassle, never mind that the default setup allowed students to format the harddrive)

Now, the Computer Systems degree I'm doing in the University of Limerick, Ireland use a mix of Red Hat and Windows, and I believe that the Computer and Electrical Engineers use the same mix, but aside from that, the rest of the college use Win2k workstations with Active Directory and Exchange Server, which was a direct upgrade from the previous infrastructure... so I guess the lock-in worked

But that's an old story. Even the translation of complete sentences is fairly feasible in terms of syntactic structure.

Harder to translate are things like discourse markers ("then", "because") because they are highly ambiguous and you would have to understand the text in a way. I have tried to guess these discourse markers with machine learning model in my thesis about rhetorical analysis with support vector machines (shameful self-promotion), and I got around 62 percent accuracy. While that's probably better than or similar to competing approaches, it's still not good enough for a reliable translation.

And that's just one example for the hurdles in the field. The need for understanding of the text kept the field from succeeding commercially. Machine Translation in these days is a good tool for translators, for example in Localization.

But a higher level scripting language should be as close to english (or another human language) as possible.

I certainly don't look forward to COBOLScript.

Human languages are an ambigious mess. Computers only want unambigious constructs. Having programmed in COBOL and and a few so called "fourth generation languages", let me say that writing in something that is close to English is really irritating. It's never quire English enough to allow me to express myself. You end up having to learn a specialized language that isn't really quite English. If I'm going to learn a specialized language, I might as well learn something that is easy to type and easy to scan visually.

Perl is a big, complex language, yes. But like real languages, you can learn it with very simple steps. You can get complex, productive things done with a just a quick introduction. If you want more power, it will take more learning, but it's available. Perl 6 aims to accomplish this evem better tham Perl 5.

Yes, the example given in the article are a bit convoluted. The entire point of the article is to explore all of Perl 6, not just the commonly used bits. In fact, one of main goals of Perl 6 is to make the common case and the introductory case less confusing than in Perl 5. Really. And everything revealed so far has supported this, it's just that Larry doesn't make it too clear.

Take for example expressing that a function takes three arguments in Perl 5. The best you can do is:

sub my_function($$$) {
....my($arg1, $arg2, $arg3) = @_;
}

(The "...." represents spaces because Slashdot's code filter is crap.)

In this example, Perl will not check that callers do the right thing. In Perl 6, you get this:

sub my_fuction($arg1, $arg2, $arg3) {
}

A clear improvement, and Perl will actually verify that callers do the right thing when calling you, usually catching an error at compile time!

In general Lary's Apocalypses have been a bit obscure. He's focusing on the big picture and the little details. Damien's Exegesis's is generally alot easier to read for people less interested in deep thought and more interested in concrete details. Wait a week or two for Exegesis 6 and give that a read. I think you'll find that the common case is slightly simplier and more obvious than in Perl 5, while the system also allows for more complex expressions that weren't well supported in the Perl 5.

A quick google search for "A86 footprint" finds this documentation, dated 1995.

That's not quite 15 years ago.

braz's article cleaned up, and with links for easy clicking (and AC to avoid karma-whoring)...
========

Congratulations to Mel Gorman for actually managing to get down to this low a level and still explain it sensibly.

Here are the links for interested readers:
The kerneltrap article

Actual documentation:
The documentation comes in two parts. The first is "Understanding the Linux Virtual Memory Manager" and it does pretty much as described. It is available in three formats, PDF, HTML and plain text.
"Understanding the Linux Virtual Memory Manager" as PDF, HTML, and Text.
The second part is a code commentary which is literally a guided tour through the code. It is intended to help decipher the more cryptic sections as well as identify the code patterns that are prevalent through the code. I decided to have the code separate from the first document as maintaining the code in the document would be too painful Code Commentary on the Linux Virtual Memory Manager
"VM Code Commentary" as PDF, HTML, and Text.

braz's article cleaned up, and with links for easy clicking (and AC to avoid karma-whoring)...
========

Congratulations to Mel Gorman for actually managing to get down to this low a level and still explain it sensibly.

Here are the links for interested readers:
The kerneltrap article

Actual documentation:
The documentation comes in two parts. The first is "Understanding the Linux Virtual Memory Manager" and it does pretty much as described. It is available in three formats, PDF, HTML and plain text.
"Understanding the Linux Virtual Memory Manager" as PDF, HTML, and Text.
The second part is a code commentary which is literally a guided tour through the code. It is intended to help decipher the more cryptic sections as well as identify the code patterns that are prevalent through the code. I decided to have the code separate from the first document as maintaining the code in the document would be too painful Code Commentary on the Linux Virtual Memory Manager
"VM Code Commentary" as PDF, HTML, and Text.

braz's article cleaned up, and with links for easy clicking (and AC to avoid karma-whoring)...
========

Congratulations to Mel Gorman for actually managing to get down to this low a level and still explain it sensibly.

Here are the links for interested readers:
The kerneltrap article

Actual documentation:
The documentation comes in two parts. The first is "Understanding the Linux Virtual Memory Manager" and it does pretty much as described. It is available in three formats, PDF, HTML and plain text.
"Understanding the Linux Virtual Memory Manager" as PDF, HTML, and Text.
The second part is a code commentary which is literally a guided tour through the code. It is intended to help decipher the more cryptic sections as well as identify the code patterns that are prevalent through the code. I decided to have the code separate from the first document as maintaining the code in the document would be too painful Code Commentary on the Linux Virtual Memory Manager
"VM Code Commentary" as PDF, HTML, and Text.

braz's article cleaned up, and with links for easy clicking (and AC to avoid karma-whoring)...
========

Congratulations to Mel Gorman for actually managing to get down to this low a level and still explain it sensibly.

Here are the links for interested readers:
The kerneltrap article

Actual documentation:
The documentation comes in two parts. The first is "Understanding the Linux Virtual Memory Manager" and it does pretty much as described. It is available in three formats, PDF, HTML and plain text.
"Understanding the Linux Virtual Memory Manager" as PDF, HTML, and Text.
The second part is a code commentary which is literally a guided tour through the code. It is intended to help decipher the more cryptic sections as well as identify the code patterns that are prevalent through the code. I decided to have the code separate from the first document as maintaining the code in the document would be too painful Code Commentary on the Linux Virtual Memory Manager
"VM Code Commentary" as PDF, HTML, and Text.

braz's article cleaned up, and with links for easy clicking (and AC to avoid karma-whoring)...
========

Congratulations to Mel Gorman for actually managing to get down to this low a level and still explain it sensibly.

Here are the links for interested readers:
The kerneltrap article

Actual documentation:
The documentation comes in two parts. The first is "Understanding the Linux Virtual Memory Manager" and it does pretty much as described. It is available in three formats, PDF, HTML and plain text.
"Understanding the Linux Virtual Memory Manager" as PDF, HTML, and Text.
The second part is a code commentary which is literally a guided tour through the code. It is intended to help decipher the more cryptic sections as well as identify the code patterns that are prevalent through the code. I decided to have the code separate from the first document as maintaining the code in the document would be too painful Code Commentary on the Linux Virtual Memory Manager
"VM Code Commentary" as PDF, HTML, and Text.

braz's article cleaned up, and with links for easy clicking (and AC to avoid karma-whoring)...
========

Congratulations to Mel Gorman for actually managing to get down to this low a level and still explain it sensibly.

Here are the links for interested readers:
The kerneltrap article

Actual documentation:
The documentation comes in two parts. The first is "Understanding the Linux Virtual Memory Manager" and it does pretty much as described. It is available in three formats, PDF, HTML and plain text.
"Understanding the Linux Virtual Memory Manager" as PDF, HTML, and Text.
The second part is a code commentary which is literally a guided tour through the code. It is intended to help decipher the more cryptic sections as well as identify the code patterns that are prevalent through the code. I decided to have the code separate from the first document as maintaining the code in the document would be too painful Code Commentary on the Linux Virtual Memory Manager
"VM Code Commentary" as PDF, HTML, and Text.

• USS Constellation (NCC-1017)
• USS Constitution (NCC-1700)
• USS Defiant (NCC-1764)
• USS Enterprise (NCC-1701)
• USS Excalibur (NCC-1664)
• USS Exeter (NCC-1672)
• USS Farragut (NCC-1647)
• USS Hood (NCC-1703)
• USS Intrepid (NCC-1831)
• USS Lexington (NCC-1709)
• USS Potemkin (NCC-1657)
• USS Republic (NCC-1371)
• USS Yorktown (NCC-1717)

The site also gives episode references for each of these ships. This is what it says about the Exeter:

NCC-1672 Encyc., TOS "Court Martial"
(identified by wall status display)
Captain Ronald Tracey TOS "The Omega Glory"
Abandoned in orbit around Omega I

Today, Aspirin® is a registered trademark of Bayer AG in Germany and more than 80 other countries. In countries where Aspirin® is not protected by trademark status, such as the United States, the term Aspirin® can be used generically for all products containing the active substance acetylsalicylic acid. However, genuine Aspirin®, renowned the world over, is only available with the Bayer Cross.

After WWI the trademark was lost by Germany in the USA, UK and France (the victors) where aspirin has entered the language as a generic name. In 1994 Bayer bought back the Bayer Aspirin trademark in the USA from Sterling Drug, who had held it since 1918.

...but, if I may be so bold, I don't watch much TV. Perhaps some of your countrymen and women should follow that example.

Ahh yes - I'd heard that in the land of the free, there were so many channels, that you were all too busy switching through 100s of channels to watch any TV ;-P

Assuming a system which supports PAM, eg Linux, Solaris or others, then pam_smb may be what you want. Pam really is rather nice for allowing the administer to setup the authentication she wants.

-Windows users need a seperate account on *nix boxes
pam_smb will help you here a lot. :)

I've used this a lot, to allow several of our Linux servers to share usernames + passwords with our NT domain.

I found it tricky to setup and a little flaky to start with - but once its up + running then it works wonderfully.

Take a look at it here.

We found a pam module that allows any pam enabled program/OS to use the Windows Active Directory for password authentication using pam_smb.

Further information can be found at: http://www.csn.ul.ie/~airlied/pam_smb/

Hope this helps.

Todd Volz
Graceland University
CS Lab Administrator

SDL provides kind of a minimal interface, which makes it really easy to pick up and learn. If you want to expose / accelerate all the features that DirectX does, you'd need a significant rewrite or extension of the SDL API.

SDL has had the ability to create OpenGL contexts for a long time. And we're talking about Direct3D, not DirectX, so the DirectDraw example doesn't apply.

You haven't done much (if any) research, have you? Actually, if you were half-way involved in a corporate environment that took linux seriously, you might have had a clue in the first place. So let's start building a reply:

The linux desktop is going nowhere fast, and for most of these projections to come true there would have to be a mass migration to the linux desktop which will not happen.

Debatable. But you are probably correct that there will not be a mass migration to a Linux desktop, at least in a short period of time. But you can't deny the efforts being made to push in that direction. With a few moves in the right direction I think Linux has a pretty good chance.

OEMS are stepping away from the linux desktop not towards it, so you will not be seeing "dual boots".

OEMs screwed it up all on their own. I recently ordered a Dell i8k laptop back when they were still "offerring" Linux preinstalled. If I chose Linux, Dell told me it would take 2-3 weeks to ship. However a Windows version could be shiped the next day. And do you seriously think Microsoft would let a OEM ship anything dual-booted with Windows?!?

I look back at the NT 4 domain model, and it wasn't great, but its better than anything in the linux camp.

You haven't played much with Samba, have you? Samba can completely replace NT4, Warp, and Netware services. That's the server side. On the client side there's Pam_Smb which can allow Linux to authenticate to NT/2000 domains. Red Hat 7.2 even gives you this option during install now.

And now with AD you have highly scalable enterprise ready directory services and no way to truly integrate linux.

We can argue about your definition of "truly", or I can go back to my Perl scripts that work with AD just fine.

Here's the SDL doc project.

Here's an article comparing X-based programming to SDL-based programming.

You can use OpenGL techniques in SDL, so here's some OpenGL stuff for you...

This NeHe page comes complete with a version of the infamous Gears ported to SDL.

Finally, if you really want to start getting the best out of it, you'd better get on hardware acceleration. Either switch to one of the latest commercial distributions (RH 7.1 and Mandrake 8.0 do 3d out of the box), or use the source, luke.

• Lisp
• Forth, and this other Forth one and this one. mmm forth, every good programmer should learn this beauty.
• x86 Assembly pretty boring stuff
• Pascal, well not my favorite either
• Cobol (this list while compile in cobol).
• Fortan. They say it still outcranks C in some areas if you can believe it. (I don't)

Also don't forget that there is also a groupware client for KDE that looks to be coming along nicely. It's called Aethera and currently at version 0.9.1. From what I've read it's a fork of a very early version of Magellan, which is more of a KDE PIM application.

The link for Aethera is: http://www.thekompany.com/projects/aethera/

And for Magellan: http://zamolxe.csis.ul.ie/

I've never used any of the programs mentioned, I've just been reading all the talk about them. But everyone seems to be focusing on GNOME and Evolution without any mention of KDE or Aethera or Magellan. So I'm mentioning them here. :-)

redundant to Transgaming's work in porting the DirectX multimedia API for Wine?

SDL has been in the making for many many years. Transgaming, for all their promises, is a very new project and is still in its infancy.

Over the years, SDL has evolved into a very stable and powerful multimedia library with some very nice functionality (especially when all the add-on libraries are taken into account).

As far as platform support, SDL has it in spades... SDL runs quite nicely on BeOS, Win32, MacOS and pretty much every *nix variant.

I would wager that SDL is the most used Linux multimedia library. The games and applications listed on the SDL site are but a drop in the bucket compared to those that I have found listed on Freshmeat and even projects on SourceForge.

I, myself, have had quite a bit of experience with SDL. My educational typing game, Tux Typing is powered by SDL. I have also begun writing some little example apps in SDL (including a multi-windowed SDL app).

While I agree this was a pretty stupid question to be featured on the "Ask Slashdot" section... from the many inane and less-than-informed comments I can see that quite a few people really don't know what SDL is, what it is being used for, and where it is going.

So, to anyone interrested, I'd say take a look at the doc pages, code tutorials here, as well as checking out the latest stable release version 1.2.

C.

C.

Never heard of Magellan? Blame slashdot. It's the KDE2 Outlook replacement. Evolution ain't got nothing on the most current Magellan snapshot...

Never heard of Magellan? Blame slashdot. It's the KDE2 Outlook replacement. Evolution ain't got nothing on the most current Magellan snapshot...

For compatibility, mostly. New pre-Windows users are used to Office, having Office on Linux makes it easier for them. Certain legal companies and publishers require documents to be in Office format. There are MS Word converters for Unix, but having the full application can still be nice.

Its GPLed, granted it needs work. So scoot onto the abiword mailing list and cvs down the latest version, get hacking on it and sort it out.

ole2 is fully sorted out with libole2, excel is being handling by gnumeric.

What is not handled by wv is not by lack of documentation or design, its simply a matter of spending some time at it. Easy peasy. Info on the MSDN docs can be got from here. They can be gotten off the MSDN 1998 July cd, or you can get some of them from wotsit.org. I even wrote ivt2html for you to convert the office.ivt file into html. Like what else do you need.

90% of all the hard work has been done, wv can parse fast and simple with no bother to it, which was a nightmare to do, it can construct the correct PAP (paragraph properties) and CHP (character properties) for a given run of text. Feed you the correct characters and charset and font, the TAP (table properties), graphic properties and handle to graphics. The correct OLE handle for embedded objects. Document properties etc. There is an example html conversion program included for reference (wvHtml).

I put together libwmf to convert wmf file into something useful as well. Theres a half done implementation of an Escher (the graphics for Office) importer floating around in there as well.

Theres also an implementation of a Summary Stream displayer for all ole2 documents.

I even bust my ass and dragged together the right bunch of motivated people to help implement the decryption module for word 97, 95 and 6, and that was not fun at all to say the least

The hard work is done, if you want something improved you have a very very solid base to work from. Yes the spec is confusing, yes its not a great format, yeah is sort of moves over time, but in a fairly rational way that can be supported with some work. There are any number of equally crap formats with weak documentation supported in various tools.

There is just this false myth that the Microsoft formats are inpenetrable and/or not available. Just download wv, fair enough there might be problem documents, if there are, just debug wv and get onto the abiword list and work it out with them. If something fails it can be fixed and improved, its not a case of "ah well, its a MS format, nothing can be done". If you truly want to handle Microsoft formats there are a number of people working on it that you can help.

So its right there for the right bunch of motivated people to work on. C.

Its GPLed, granted it needs work. So scoot onto the abiword mailing list and cvs down the latest version, get hacking on it and sort it out.

ole2 is fully sorted out with libole2, excel is being handling by gnumeric.

What is not handled by wv is not by lack of documentation or design, its simply a matter of spending some time at it. Easy peasy. Info on the MSDN docs can be got from here. They can be gotten off the MSDN 1998 July cd, or you can get some of them from wotsit.org. I even wrote ivt2html for you to convert the office.ivt file into html. Like what else do you need.

90% of all the hard work has been done, wv can parse fast and simple with no bother to it, which was a nightmare to do, it can construct the correct PAP (paragraph properties) and CHP (character properties) for a given run of text. Feed you the correct characters and charset and font, the TAP (table properties), graphic properties and handle to graphics. The correct OLE handle for embedded objects. Document properties etc. There is an example html conversion program included for reference (wvHtml).

I put together libwmf to convert wmf file into something useful as well. Theres a half done implementation of an Escher (the graphics for Office) importer floating around in there as well.

Theres also an implementation of a Summary Stream displayer for all ole2 documents.

I even bust my ass and dragged together the right bunch of motivated people to help implement the decryption module for word 97, 95 and 6, and that was not fun at all to say the least

The hard work is done, if you want something improved you have a very very solid base to work from. Yes the spec is confusing, yes its not a great format, yeah is sort of moves over time, but in a fairly rational way that can be supported with some work. There are any number of equally crap formats with weak documentation supported in various tools.

There is just this false myth that the Microsoft formats are inpenetrable and/or not available. Just download wv, fair enough there might be problem documents, if there are, just debug wv and get onto the abiword list and work it out with them. If something fails it can be fixed and improved, its not a case of "ah well, its a MS format, nothing can be done". If you truly want to handle Microsoft formats there are a number of people working on it that you can help.

So its right there for the right bunch of motivated people to work on. C.

Its GPLed, granted it needs work. So scoot onto the abiword mailing list and cvs down the latest version, get hacking on it and sort it out.

ole2 is fully sorted out with libole2, excel is being handling by gnumeric.

What is not handled by wv is not by lack of documentation or design, its simply a matter of spending some time at it. Easy peasy. Info on the MSDN docs can be got from here. They can be gotten off the MSDN 1998 July cd, or you can get some of them from wotsit.org. I even wrote ivt2html for you to convert the office.ivt file into html. Like what else do you need.

90% of all the hard work has been done, wv can parse fast and simple with no bother to it, which was a nightmare to do, it can construct the correct PAP (paragraph properties) and CHP (character properties) for a given run of text. Feed you the correct characters and charset and font, the TAP (table properties), graphic properties and handle to graphics. The correct OLE handle for embedded objects. Document properties etc. There is an example html conversion program included for reference (wvHtml).

I put together libwmf to convert wmf file into something useful as well. Theres a half done implementation of an Escher (the graphics for Office) importer floating around in there as well.

Theres also an implementation of a Summary Stream displayer for all ole2 documents.

I even bust my ass and dragged together the right bunch of motivated people to help implement the decryption module for word 97, 95 and 6, and that was not fun at all to say the least

The hard work is done, if you want something improved you have a very very solid base to work from. Yes the spec is confusing, yes its not a great format, yeah is sort of moves over time, but in a fairly rational way that can be supported with some work. There are any number of equally crap formats with weak documentation supported in various tools.

There is just this false myth that the Microsoft formats are inpenetrable and/or not available. Just download wv, fair enough there might be problem documents, if there are, just debug wv and get onto the abiword list and work it out with them. If something fails it can be fixed and improved, its not a case of "ah well, its a MS format, nothing can be done". If you truly want to handle Microsoft formats there are a number of people working on it that you can help.

So its right there for the right bunch of motivated people to work on. C.