Microsoft geeft documentatie pst-bestandsformaat vrij

Microsoft heeft deze week bekendgemaakt documentatie over zijn pst-bestandsformaat, dat wordt gebruikt om Outlook-data als mail en contacten op te slaan, vrij te geven. De documentatie wordt vrijgegeven onder Microsofts OSP.

Hoewel Microsoft voornemens is de documentatie te openbaren, heeft de softwaremaker zichzelf geen deadline gesteld wanneer dit moet zijn gebeurd. Wel benadert de fabrikant momenteel geïnteresseerde klanten en industrie-experts om feedback te krijgen op zijn plannen. Microsoft wil onder meer weten hoe technisch de documentatie moet zijn, meldt Ars Technica.

Als Microsoft de documentatie gereed heeft, zal het worden vrijgegeven onder de Open Specification Promise, een Microsoft-programma dat ontwikkelaars vrijwaart van juridische vervolging als zij specificaties gebruiken die onder OSP zijn vrijgegeven. De technische informatie zou in detail moeten uitwijzen hoe informatie is opgeslagen en hoe deze data vanuit andere applicaties kan worden benaderd.

Met behulp van de documentatie zouden ontwikkelaars dus gegevens uit pst-bestanden moeten kunnen lezen of er juist naartoe wegschrijven zonder juridische consequenties. Pst zou hierdoor in theorie als breder gebruikt bestandsformaat gebruikt kunnen gaan worden, ongeacht het platform of programmeertaal.

Reacties (119)

Mooi nieuws natuurlijk, meer openheid is altijd welkom. Toch verbaast het me dat dit nu pas komt, als je nagaat hoeveel PST-repareer programmatjes er al uit zijn (waarbij ik gemakshalve even vergeet dat de helft niet- of amper werkt). Sowieso zijn er al heel wat Microsoft formaten openbaar, ik zat laatst de specificaties van .doc bestanden (dus niet de .docx formaten) te bekijken. Met de overstap naar .docx, wat meer XML-based is, hebben ze het zichzelf dan toch heel wat gemakkelijker gemaakt.

Het libpst project zet zich al een hele tijd in voor documentatie van het bestandstype, zo te zien met name door Reverse Engineering.

Met .docx hebben ze het wiel opnieuw uitgevonden om concurrentie te hinderen. Er bestond al een goede open (ISO) standaard, voor Office documenten gebaseerd op XML. En Microsoft moest toch weer hun eigen standaard uitvinden en er op twijfelachtige wijze doorheen drukken.

Zelf zit ik meer te wachten op documentatie van het .mdb-formaat zoals gebruikt in MS Access. Op dit moment is het ongmogelijk om dat op een ander besturingsysteem dan Windows te lezen. De andere formaten waren al lang voordat de documentatie werd vrijgegeven doormiddel van reverse-engineering toegankelijk, maar dit bestandsformaat niet.

Met .docx hebben ze het wiel opnieuw uitgevonden om concurrentie te hinderen. Er bestond al een goede open (ISO) standaard, voor Office documenten gebaseerd op XML

Met de docx files hebben ze niet opnieuw het wiel uitgevonden. Microsoft ontwikkelde hun XML format al vanaf 1998 en gebruikte al een XML format in MS Office vanaf MS Office 2003. Office Open XML (o.a. docx files) is een ISO/IEC standaard ontwikkeld uit de interne opvolger daarvan. Je kunt ook nog delen van de markup van de MS Office 2003 files terugvinden in de Office Open XML markup.

En ODF was volstrekt niet een goede standaard maar een vooral een erg incompleet stel specs die alleen implementeerbaar zijn door OOo source code te gebruiken. Misschien dat ODF eindelijk wat wordt met versie 1.2 waar nu al 3 jaar aan gewerkt wordt.

Laten we het alsjeblieft niet meer hebben over ISO. De waarde van een ISO standaard is nagenoeg nul sinds MS besloot de organisatie te mollen voor een eigen doeleinden.

Dat ben ik niet geheel met je eens. Ondanks dat het natuurlijk zo is dat het introduceren van een nieuw bestandstypes ook nadelen met zich meebrengt, met name op het gebied van compatibiliteit, is het ook voor Microsoft zelf een enorme sprong vanaf het oude doc formaat. Het nieuwere .docx formaat is een ECMA-376 standaard, ook wel bekend als het Office Open XML dat gebruikt wordt vanaf Microsoft Office 2007. Dit formaat is tevens een ISO standaard en uitgebreid gedocumenteerd, dus ook toe te passen voor andere bedrijven en programma's die daar interesse naar hebben.

Verder is er een documentatie van mdb bestanden beschikbaar op deze pagina. Wel zul je goed met C/C++ of een andere programmeertaal aan de gang moeten om er iets mee te doen, maar dat zal bij ieder bestandsformaat zo zijn (op XML na, door de vele beschikbare libraries).

is het ook voor Microsoft zelf een enorme sprong vanaf het oude doc formaat. Het nieuwere .docx formaat is een ECMA-376 standaard, ook wel bekend als het Office Open XML dat gebruikt wordt vanaf Microsoft Office 2007.

Alleen is het Office Open XML [OOX] formaat weer wel sterk gebaseerd op het oude binaire formaat. En dat geeft Microsoft natuurlijk weer wel een voordeel.

Twee voorbeelden:

1. Er wordt, in de OOX-standaard gerefereerd aan VML een MS-only markup taal.
2. De standaard bevat willens en wetens referenties aan applicatie-specifieke implementaties (renders as Word 'XX bijvoorbeeld).

N.B. Mogelijk dat sommige van dit soort zaken reeds verwijderd zijn, maar ze had nooit in een ECMA-document mogen staan...

Dit formaat is tevens een ISO standaard en uitgebreid gedocumenteerd, dus ook toe te passen voor andere bedrijven en programma's die daar interesse naar hebben.

Op zich wel, alleen is het dan wel jammer dat de 'standaard' de (ongeschreven) regels die voor XML-documenten gelden schend - denk o.a. aan het human-readable zijn van de XML-serialisatie...

Alleen is het Office Open XML [OOX] formaat weer wel sterk gebaseerd op het oude binaire formaat. En dat geeft Microsoft natuurlijk weer wel een voordeel.

Een belangrijk doel van Office Open XML is het bieden van compatibiliteit met de oude binaire formaten. Dat betekent logische overeenkomsten (bijvoorbeeld in document structuur en ondersteuning van de features).

Er wordt, in de OOX-standaard gerefereerd aan VML een MS-only markup taal.

VML is een markup taal waarvan de specificaties door MS al 12 jaar geleden bij W3C zijn ingediend en als zodanig zijn de specificaties daarvan altijd al bekend. VML wordt bijvoorbeeld ook gebruikt door Google maps. Verder wordt er in de Office Open XML standaard niet aan dit formaat gerefereerd maar is de hele specificatie opgenomen en dus als standaard vastgelegd. (in het transitional gedeelte dus strict OOXML bevat geen VML)

De standaard bevat willens en wetens referenties aan applicatie-specifieke implementaties (renders as Word 'XX bijvoorbeeld).

Daarmee wordt het mogelijk om oude geconverteerde documenten heel precies te reproduceren. Omdat deze settings zijn gedefinieerd zijn ze volledig interoperabel tussen applicaties. Deze settings zijn ook transitional.

Overigens heb je bijvoorbeeld ODF bevat een vergelijkbaar mechnisme maar dan met willkeurige ongedefinieerde settings. In OOo heb je bijvoorbeeld settings vergelijkbaar met "renders als vorige versie". Deze ODF settings zijn ongedefinieerd en daardoor juist niet interoperabel. Je kunt dus nooit ODF bestanden volledig interoperabel maken die deze settings gebruiken terwijl OOXML bestanden juist wel interoperabel zijn.

Op zich wel, alleen is het dan wel jammer dat de 'standaard' de (ongeschreven) regels die voor XML-documenten gelden schend - denk o.a. aan het human-readable zijn van de XML-serialisatie...

Dat is ook niet waar. OOXML ongeveer net zo human readable als ODF. Het maakt echt weinig uit of je bijvoorbeeld </p> of </paragraph> gebruikt voor leesbaarheid.

[Reactie gewijzigd door Anoniem: 80466 op 27 oktober 2009 10:53]

Een belangrijk doel van Office Open XML is het bieden van compatibiliteit met de oude binaire formaten. Dat betekent logische overeenkomsten (bijvoorbeeld in document structuur en ondersteuning van de features).

Jammer dat men zich bij ontwerpen van een geheel nieuw bestandsformaat niet heeft laten leiden door logische requirements maar vanuit compatibiliteit van juist datgene wat al vijftien jaar om compatibiliteits-reden wordt meegezeuld.
Er zijn vele manieren om features te ondersteunen.

Het had echt anders gekund. Een gemiste kans.

Voor de rest lijkt mij de ODF <-> OOXML oorlog te off topic om hier op in te gaan.

[Reactie gewijzigd door Anoniem: 316446 op 27 oktober 2009 11:41]

De meest logische requirement is juist het compatible zijn met het meest gebruikte en populaire document formaat dat er is. Daarin is namelijk al gigintisch veel kapitaal geinvesteerd. Het is juist ODF waarbij het volstrekt onduidelijk is wat daaraan voor logische requirement daaraan ten grondslag ligt. Het is dus minder compatible, minder featurerijk en het is ook niet erg interoperabel.

Door die slechte compatibiliteit is ODF ook erg slecht bruikbaar als opvolger voor de binaire documentformaten omdat veel applicaties die nu binaire bestanden produeren niet makkelijk ODF kunnen implementeren. Het ondersteunt minder features en er is geen goede documentatie en er is nauwelijk goede tooling (API's).

Verder weet iedereen jaren dat het enomr vertraagde ODF 1.2 er aan komt en dat alle huidige ODF applicaties dan weer enorm (zeker voor spreadsheets) op de schop gaan. Ook geen positieve zaak.

Het is juist ODF waarbij het volstrekt onduidelijk is wat daaraan voor logische requirement daaraan ten grondslag ligt.

Ik snap niet zo goed waarom je ODF hierbij sleept? Kun je niet over OOXML schrijven zonder een ander formaat erbij te halen? Het lijkt zo OS-war-achtig waar veel fora mee vervuild worden.

Microsoft en haar fans tegen de rest van de wereld

Maar goed, schijnt zo te moeten, voor mij is die discussie dan minder interessant.

[Reactie gewijzigd door Anoniem: 316446 op 27 oktober 2009 12:18]

Laat hAl toch lekker in z'n fanboy-soep gaarkoken... Hij is een van de grootste MS fanboys die hier rondloopt en kan geen kritiek op MS aanzien, en gaat daarom maar een beetje ODF lopen flamen zonder bronvermelding. Dat doet ie altijd en dus ook hier weer.
Eigenlijk maakt ie alleen zichzelf maar belachelijk door dingen te roepen als "ODF heeft slechte compatibiliteit", terwijl iedere andere fabrikant van kantoorsoftware al ODF ondersteund.
"Ondersteund minder features"? Kom op zeg, features als "renders like MS Word 97" heeft niemand nodig...
"Bij ODF is er geen logische grondslag"? Wtf, zelfs een koe blaat nog zinniger dingen. Zo heb ik er ook nog een voor je: Bij MS is er altijd een logische grondslag voor beslissingen en dat is hun missie om de vendor lock-in zo groot mogelijk te houden.
Als er een 1.2 versie aankomt, zal dat ongetwijfeld compatible zijn met vorige versie. In ieder geval een stuk meer compatible dan dat onderlinge MS Office versies dat zijn, dus waarom het geen positieve zaak zou zijn...?
<flame>Voor OOXML is er overigens ook geen goede tooling, alleen maar MS apps, en MS apps zijn toch rotzooi.</flame>

Als je nog een keer complete bullshit loopt te posten, doe er dan een bronvermelding bij, in plaats de reacties te vervuilen met willekeurige rare hersenkronkels van een MS fanboy.

En ik meld alvast maar van tevoren dat hAl hier ongetwijfeld een reactie op zal posten, en ik er niet op inga, ik heb geen zin meer in z'n vervelende geflame altijd...

Gek he dat de marktleider zich niet door Open office een bestandsformaat laat opleggen!

Verklaar je nader?

Zoals jij het zegt lijkt het alsof bij Microsoft marktpositie een beweegreden is om een ISO standaard links te laten liggen.

Dat is een interessante visie, die ik nog nergens bevestigd heb gezien.

Welke redenen heb jij om aan te nemen dat dit zo is?

[Reactie gewijzigd door Anoniem: 316446 op 27 oktober 2009 12:19]

Uiteraard is dat een reden.

als je een kleine speler bent, dan is het belangrijk dat je zoveel mogelijk andere formaten ondersteunt, omdat gebruikers anders geen goed gebruik kunnen maken van je software.

Als je de marktleider bent met een zeer grote voorsprong op de rest, en dus de de-factor standaard, dan hoef je je niet druk te maken over andere kleine standaardjes die vrijwel niet gebruikt worden.

Dan hoef je je alleen druk te maken over de functionaliteit die jij zelf in je standaard nodig hebt.

Als een bestaande of nieuwe standaard niet voldoende functionaliteit biedt, dan maak je gewoon je eigen standaard.

Vrijwel alle succesvolle standaarden zijn gemaakt door monopolisten of zeer grote marktleiders.

Vrijwel alle succesvolle standaarden zijn gemaakt door monopolisten of zeer grote marktleiders.

Veel succesvolle standaarden zijn gemaakt door samenwerkingsverbanden uit de industrie, regelmatig zijn ook universiteiten en maatschappelijke organisaties betrokken.

Hoe meer partijen betrokken zijn, hoe meer kans op succes voor een standaard.

(een heel ander beeld dan jij oproept)

[Reactie gewijzigd door Anoniem: 316446 op 27 oktober 2009 13:05]

Op dit moment is het ongmogelijk om dat [mdb bestanden] op een ander besturingsysteem dan Windows te lezen

mdbtools anyone?

Wordt o.a. gebruikt door Kexi, zie bijvoorbeeld de Northwind database geimporteerd vanaf Access.

Van de oude bestandsformaten doc, xls enzo was al veel te veel bekent bij concurrenten. Als vendor-lock-in werkte dat niet meer goed genoeg. Daarom hebben ze de OO XML standaarden bedacht. Daarin zitten dan weer onhebbelijkheidjes in zoals

De standaard bevat willens en wetens referenties aan applicatie-specifieke implementaties (renders as Word 'XX bijvoorbeeld).

zoals Little Penguin hierboven vermeld

die concurrenten dan weer opnieuw moeten interpreteren.

[Reactie gewijzigd door BeosBeing op 27 oktober 2009 14:29]

misschien dat er nu meer programma's komen die PST bestanden kunnen repareren als er iets mis gegaan is het meegeleverde softwarestukkie doet niet altijd zn best

als je met pst's van enkele GB's knoeit, dan vind ik dat de user wel eens met z'n neus op de feiten gedrukt mag worden

Helaas hebben sommige gebruikers de neiging om werkelijk alle mail die ze ooit gehad hebben te bewaren. En ja, dan krijg je PST-files van gigabytes groot ja. Zeker omdat nu met Outlook 2007 de maximumgrootte is verhoogd van 4 GB naar 20 GB per stuk.

Echt, bij vorige werkgevers heb vele gebruikers gezien met GB's aan PST-file op hun homefolder. De grootste die ik tot nu toe ben tegengekomen was 55 GB (in verschillende PST's). Die man had ál zijn mail sinds 1999 bewaard... met attachments en al.

[Reactie gewijzigd door wildhagen op 27 oktober 2009 10:47]

Gek he, als je als bedrijf tot 7 jaar terug al je zakelijke e-mail moet bewaren van de Belastingdienst. Zelf heb ik ook al m'n mail nog van tot voor de eeuw-wisseling, wat is daar mis mee? Moet kunnen toch?

Die bewaarplicht van 7 jaar geld alleen voor mail die relevant is voor de bedrijfsvoering, niet voor mails uit de categorie 'mooie vakantiefoto''s, uitnodigingen voor borrels/recepties, en leuke filmpjes van collega's' (want ook die stonden erin).

Daarnaast heb je dit soort belangrijke mails centraal in een backup-archief staan, niet in losse PST-files bij elke gebruiker.

[Reactie gewijzigd door wildhagen op 27 oktober 2009 11:06]

Maar het moet kunnen toch? Was de reactie van man-o-script. Ik ben het met hem eens. Er zijn allerlei redenen denkbaar waarom iemand zijn emails wil bewaren. Ikzelf doe dat ook, maar ik bewaar ze in een IMAP-folder op de mailserver, omdat die onder mijn eigen beheer staat. Echter zou dat niet zo zijn, dan zou ik ook met een storage op de computer werken.

En dan heb je als gewone gebruiker met Outlook op het werkstation niet veel keus als pst.

Als gebruiker zonder Outline kun je ook een offline storage instellen, bijvoorbeeld Thunderbird kan dat ook.

Wat is daar het probleem? Juist, de mailclient.
Als hij niet met grote bestanden overweg kan.....dan moet ie het in kleinere bestanden opslaan? (of zou dat te logisch zijn?)

Het formaat dat op (sommige) unix varianten word gebruikt vind ik wel iets hebben....gewoon de rauwe mails opslaan per stuk.
Erg makkelijk als er iets mis zou gaan....1 mailtje mogelijk stuk, de rest doet het altijd.
Misschien kost het iets meer ruimte....maar het werkt

Ik heb al mijn mail die ik sinds eind 2007 (toen ik hier als systeembeheerder in dienst kwam) bewaard. Dit is nu ongeveer 8GB. De reden dat ik dit bewaar, is omdat er handleidingen tussen zitten van enkele software pakketten, licentie overeenkomsten etc etc.

en ik kijk regelmatig naar dat soort documenten. Waarom zou ik het uitprinten als ik het digitaal heb? Daarnaast is het handig om je mail te bewaren, want sommige gebruikers beweren dan iets wat ik nooit gemailed heb, of verdraaien het (mens-eigen denk ik). Ik kan ze dan al mijn mails naar hun laten zien als dat echt nodig is (tot nu toe 2 keer voorgekomen, maar toch).

Ze hangen alleen niet standaard in outlook, maar staan op een externe harde schijf, en ik heb een kopie per jaar die apart liggen.

Sommige mensen (zoals ik) vinden het heel erg fijn dat data bewaard word. Ik hoef het niet op een netwerkschijf te plaatsen (daar heb ik totaal 25MB staan), ik maak de kopie zelf wel.

[Reactie gewijzigd door ArawnofAnnwn op 27 oktober 2009 11:10]

55GB over zo'n lange periode is helemaal niet zoveel, ligt er denk ik erg aan wat voor een werk je doet. Ik werk net iets meer dan 2 jaar bij mijn huidige werkgever en moest onlangs verplicht opschonen omdat ik ook al aan de 50GB 'grens' zat. Dan hebben we het nog niet over de mailboxen van onze CAD-ers en grafisch ontwerpers Overigens helemaal niet zo'n slechte oplossing, het alternatief wat de meeste mensen doen is al die mailtjes printen en in een map stoppen, dan is het digitaal beheren toch wel de meer gewenste methode toch?

Die attachments zijn natuurlijk de echte ruimtevreters. Binnen veel bedrijven is het heel gewoon om als volgt te communiceren: een e-mail zonder body, maar met een Powerpoint presentatie van 4 MB eraan met daarin een 8-tal korte punten met een mooi plaatje als achtergrond.

Mijn eerste gebruik van e-mail was op Fidonet, en daar keek je wel link uit om 'grote' berichten te maken als je dat vervolgens met een 14K4 modem moest gaan versturen.

Tegenwoordig is iedereen zo gewend aan breedband dat je je er nauwelijks meer bewust van bent welke enorme hoeveelheden data je verstuurd om relatief weinig informatie door te geven.

Mail als archief werkt eigenlijk heel erg slecht, ik heb tenminste de zoek-functionaliteit van Outlook (2003) nooit echt kunnen gebruiken. Zeker als de 'echte' informatie niet in de e-mail staat maar in de attachment moet je al andere dingen gaan gebruiken om de boel wel te kunnen doorzoeken.

om in outlook te zoekn gebruik in Xobni Plus, werkt prima. Je kunt dan meteen de Windows indexer vertellen dat Outlook niet meer ge-indexed hoeft te worden, scheelt weer tijd.

Ik heb mail op m'n eigen server gelimiteerd tot berichten van een MB of 5 a 10 (weet niet meer exact waar ik m op heb gezet). Als verzenders dan hun bericht weer terug krijgen met de melding dat het te groot is, laten ze het volgende keer wel uit hun hoofd om idioot grote mails te versturen. Email is nooit bedoelt geweest voor grote verzendingen

Zeker omdat nu met Outlook 2007 de maximumgrootte is verhoogd van 4 GB naar 20 GB per stuk.

Met Outlook 2003 was dat al hoor. Outlook XP (2002) en lager was de maximum grootte van de PST nog 2 GB en met Outlook 2003 is dat verhoogd naar 20 GB.

Ik snap anders wel waarom mensen al hun emails met attachments bewaren...

Op die manier is hun data namelijk perfect gearchiveerd, en super makkelijk terug te vinden. Ze kunnen niet alleen makkelijk zoeken, maar hebben ook in de bijbehorende email ook nog wat extra commentaar bij de documenten staan.

Wat je hier eigenlijk ziet, is dat Outlook een behoefte opvult wat betreft metadata bij bestanden. Dat werkt weliswaar niet perfect, maar wel veeel beter dan de bestanden kaal op een folder op de harddisk opslaan.

Als een applicatie tussen de .pst en de gebruiker zit (net zoals MySQL/InnoDB tussen een of andere ibdata1 file en de gebruiker zit), moet de applicatie dat ondervangen. Bijvoorbeeld uit zichzelf de bestanden binnen proporties houden of dingen niet toestaan.

Blijkbaar is .pst de MyISAM onder de mail-opslagformaten

Zelf heb ik ook gigantisch veel e-mail, maar dan wel op een IMAP-server in Maildir formaat + Dovecot indexes op een transactioneel bestandssysteem. Nooit meegemaakt dat iets kapot ging.

[Reactie gewijzigd door Sfynx op 27 oktober 2009 17:51]

Als je goed met je pst bestanden omgaat en je gebruikers dit ook leert hoef je geen pst bestanden te repareren

Het is in de eerste plaats natuurlijk bezopen dat een applicatie z'n data bestanden zelf aan gort kan trekken... een bedrijfskritisch systeem zoals email moet gewoon robuust werken...

Dan kunnen je gebruikers ook niks fout doen.. regel 1 in systeembeheer: bescherm de gebruiker voor z'n eigen dommigheid.

[Reactie gewijzigd door cappie op 27 oktober 2009 10:43]

In een bedrijf word meestal dan ook met Exchange werkt, en die slaat zijn dat niet in een PST op, maar in een EDB-file (Embedded Database) op de server.

Een PST-file moet je gewoon zoveel mogelijk zien te verrmijden eigenlijk. Het is inderdaad niet het meest stabiele bestandsformaat wat ooi bestaan heeft.

Daarnaast wordt er normaal gesproken alsnog een normaal .pst bestand aangemaakt. EDB is volgens mij ook meer bedoelt als backup/sync mogelijkheid, dan als het werkelijke werkbestand.

[Reactie gewijzigd door MicGlou op 27 oktober 2009 11:48]

Nee, EDB is absoluut niet bedoelt als backup/sync mogelijkheid, maar echt als werkbestand.

Maar een mailbox van 500MB is niet voldoende om je archief in op te slaan.
Daar gebruiken mensen dan meestal een PST voor.

Maar PST files zijn in een enterprise omgeving inderdaad bronnen van problemen. Vandaar dat wij het onmogelijk hebben gemaakt om PST files te gebruiken, en een 3rd party oplossing hebben voor de lange termijn archivering.

Ik zeg het misschien wat kort, maar EDB wordt praktisch niet ingezet voor gebruik op een workstation, dan functioneert het mijn inziens toch nog altijd meer als een backup database, immers wordt persoonlijke archivering etc in het PST bestand gedaan. Volgens mij is het ook nog zo dat EDB ook meer is toegespits met gebruik van mobile devices e.d.

PST heb je wel mee te maken als je moet archieveren (wat je wel moet als je een restricitie hebt op de grote van je mailbox)...

Bij de meeste bedrijven heb je een nogal lage limiet op de mailbox. Om je mail te archiveren moet je dan wel met PST werken.

Kom nou. Het zou niet nodig moeten zijn om je gebruikers te trainen hoe ze met een bestand moeten omgaan dat door hun mailclient achter de schermen wordt gebruikt.

Pst zou hierdoor in theorie als breder gebruikt bestandsformaat gebruikt kunnen gaan worden, ongeacht het platform of programmeertaal.

PST is nou niet bepaald legendarisch op het gebied van performance en betrouwbaarheid... Ik weet niet of de wereld hier wel op zit te wachten.

Wel als je op een Mac werkt, want zelfs Microsoft Entourage kan niet overweg met .pst-bestanden!

Lol.. dat is een gemis

Vaag hoor... vooral als je je bedenkt dat het beiden van MS is.
Btw nooit gesnapt waarom niet alles hetzelfde heet:

Word 2007 (win) --> Word 2008 (mac)
Excel .....

En dan is het alternatief voor Outlook ineens Entourage.

Waarschijnlijk omdat Outlook allerlei systeem-DLL's (mis)bruikt en dus niet makkelijk te porten valt.

Lijkt mij dat MS de code van die Windows-systeem-dll's wel heeft en dit dan kan gebruiken...
Ik denk eerder dat MS de Mac als een bedreiging ziet voor bedrijfsomgevingen. Zolang ze geen Outlook ondersteuning bieden in het Office pakket wordt de Mac als minder handig gezien in bedrijfsoplossingen met Exchange voor mail en agenda. Nu Apple in 10.6 Exchange volledig ondersteund in Mail en iCal, zie je dat MS ook meegaat in Office, omdat anders mensen geen Office meer nodig hebben...

Mac en Windows hebben een verschillende doelgroep en gebruikersinterface. Het is niet zo vreemd dat een fabrikant verschillende versies uitbrengt om een goede aansluiting op het OS te kunnen bieden.

Maar dat rechtvaardigt niet dat .pst-bestanden op een Mac niet herkend worden door Entourage. Ik vermoed dat Microsoft dat uit concurrentieoverwegingen zo doet.

En dan is het alternatief voor Outlook ineens Entourage

Gelukkig gaat het vanaf de volgende Office for Mac-versie weer wel gewoon Outlook heten, aldus Microsoft zelf.

Ik denk dat het met de documentatie makkelijker wordt om PST te importeren naar een ander mail programma die een betrouwbaarder formaat gebruikt

Dit kun je ook doen met de beschikbare API. Beschikking over het PST is wel nodig indien je naar een ander platform gaat, of indien je de API wil uitbreiden.

Het is dus winst, als tot op het kleinste detail-niveau de technische documentatie wordt vrijgegeven.

Dit kun je ook doen met de beschikbare API.

Daar heb je niks aan als je geen (werkende) Outlook hebt op het systeem.

Vandaar dat ik zei dat het bekend gemaakte bestandsformaat als toevoeging handig is.

Het is in ieder geval een enorme winst als je een ander mailprogramma gaat gebruiken die de PST-bestanden probleemloos kan inlezen en omzetten.

Ik ben geen voorstander van al je mails in 1 bestand weg te schrijven. Geraakt het bestand corrupt dan ben je alles kwijt, het zal niet de eerste keer zijn.

Ik werk op mac en daar heeft Entourage ook de vervelende eigenschap van alle mails in grote files te bewaren. Met als gevolg dat mijn 10gig mailbox elke uur door timemachine wordt geupdate! Zo krijg je timemachine op 1 of 2 dagen wel vol! Maar de nieuwe Entourage (of outlook) zou ook losse files gaan ondersteunen zoals MAIL doet.

Weet niet precies wat je bedoelt met losse files. Outlook 2007 heeft namelijk ook gewoon de mogelijkheid meerdere files te gebruiken. Ik heb zelf per email adres een datafile.

Hij doelt op het feit dat meerdere mails in één enkel bestand opgeslagen worden, in tegenstelling tot bijvoorbeeld het Maildir formaat waarin elke mail één bestand is.

Dit kan efficiënt worden gebackupped, is simpel genoeg om met de hand te repareren en een corrupt bestand kost je slechts één mailtje. Er zijn natuurlijk ook nadelen aan, zoals verlies van ruimte door de cluster grootte van je filesystem, en slechte performance bij grote aantallen e-mail (ook afhankelijk van het filesystem).

[Reactie gewijzigd door Yggdrasil op 27 oktober 2009 10:44]

Efficient backuppen van losse bestanden van een paar kb groot? Ik heb nog nooit een backup pakket gezien die dat efficient kan.
Als een director moet backuppen met 9000 kleine bestandjes of met 1 groot bestand van 2gb groot, weet ik wel welke van de 2 er eerder klaar is.

Het enige waar losse bestanden efficient voor zijn is voor het restoren, niet voor het backuppen

en dan is 9000 bestandjes nog maar een kleine mailbox.

50.000 tot 100.000 mails, is bij ons heel normaal.

Een incrementele backup is wel véél makkelijker bij losse bestanden. Anders moet je een binary diff doen met dat ene grote bestand, en dan weet ik nog zo net niet wie er eerder klaar is.

- Het complete idee achter een backup is, dat je er mogelijk zaken uit wilt kunnen restoren, en niet dagen lang in je backup moet zoeken om dat ene mailtje terug te vinden die je per ongeluk gedelete hebt.

- Voor een efficiente tool die kleine bestanden backupt moet je misschien eens kijken naar tar, wat al vele tientallen jaren dienst doet als uitstekend backup programma. Oh wacht, het ging hier over MS, die hebben geen handige commandline tools, alleen maar ingewikkelde gui onzin

- Het backuppen van losse bestanden is veel efficienter, want een hoop backup tools kijken of een bestand verandert is bij het maken van een volgende backup, zodat ze ongewijzigde bestanden niet hoeven te backuppen. Aangezien je gigabytes grote bestand altijd verandert, wordt het iedere keer in z'n geheel gebackupt (aangezien het formaat toch niet goed te lezen is door 3rd party tools), in plaats van een paar kb als er 1 nieuw mailtje binnen is gekomen.

Met losse files bedoelt hij gewoon per mail een bestand. Als er dan een bestand corrupt raakt ben je hooguit één mail kwijt en niet alles tegelijk.

Losse bestanden hebben ook genoeg nadelen. Het inlezen van veel losse bestanden gaat (iig op klassieke harddisks) een stuk langzamer. Daarnaast nemen deze meer ruimte in beslag (door de cluster grootte).

Boeien. Ruimte zat en als je mails zo groot zijn dat ze niet snel genoeg worden ingelezen dan heb je een heel ander probleem.

De voordelen van losse bestanden wegen imho ruim op tegen alles in een file kwakken. Als het echt te groot wordt dan zip je gewoon even alle mail van een jaar / kwartaal, mailbox, whatever je handig vindt.

Klassieke harddisks zijn over 10 jaar toch verdwenen. SSD's worden steeds groter en goedkoper. Om dan te optimaliseren voor een verouderde technologie lijkt me een beetje onzinnig. Ook is die harddisk space die je meer kwijt bent niet relevant meer met de huidige opslagcapaciteit. En als het echt uit maakt, maak je de clustergrootte gewoon kleiner

Op zich is het een goede stap dat dit formaat openbaar wordt, maar het zou een nog veel betere stap zijn als Microsoft het fabriekseigen MS-exchange formaat zou vervangen door het open IMAP-formaat en mee zou werken aan CalDAV (of een ander/beter alternatief om kalenders te delen - maar wel via een publiek orgaan [IETF/W3C oid...])

Exchange is veel meer dan alleen mail en agenda's. Mijn gevoel zegt (zonder dat ik dat kan onderbouwen) dat het extreem moeilijk zal zijn om dit soort grote wijzigingen in de Exchange architectuur door te voeren zonder de mooie dingen van Exchange kapot te maken (integratie in ongeveer alles...). Overigens kun je al gewoon met een IMAP client tegen Exchange aanpraten, dus het is niet zo dat Outlook de enige bruikbare Exchange client is als je enkel mail en agenda's wilt gebruiken.

Exchange is veel meer dan alleen mail en agenda's.

Maar wat is het dan meer (behalve contacts?)

Ik zie het probleem niet direct namelijk, ook met een gesplitste communicatie kun je nog steeds zorgen voor een mooie integratie aan de client en server kant...

Mijn punt is namelijk dat Microsoft minder aan het verzinnen van eigen standaarden moet doen en meer de open IETF/W3C/OASIS standaarden moet gebruiken...

bv: Unified Messaging, Unified communications, synchroniseren van je anti-spam whitelist met de Exchange Edge servers.
Hoe wou je dat met IMAP doen?

Als je zuiver en alleen mail wilt ophalen en verzenden dan is IMAP(4) prima.
Maar het mist gewoon alle geavanceerde functionaliteit.

Er zijn toevoegingen waarin voor Unified Messaging/Communications IMAP een functie vervult.
http://wikis.sun.com/disp...fied+Messaging+Technology
zelf even verder googelen
http://www.google.nl/search?q=Unified+Messaging+imap

Wat betreft SPAM, dat kan goed server-side en client-side ingesteld worden als aanvulling op elkaar.

Dus ik denk dat de meeste zaken wel gedaan kunnen worden zonder Exchange, want in feite is Exchange een verzameling van functionaliteiten onder een productnaam.

Dit is een voordeel voor Exchange, maar het kan ook als nadeel worden gezien (indachtig Johan Cruijff). Immers als je de totaal-oplossing Exchange gebruikt, dan kun je moeilijk voor de aparte onderdelen iets anders kiezen. Een totaal-oplossing is makkelijker maar beperkt de vrijheid

[Reactie gewijzigd door Anoniem: 316446 op 28 oktober 2009 08:39]

(integratie in ongeveer alles...)

alles... zolang het maar MS is...

het zou een nog veel betere stap zijn als Microsoft het fabriekseigen MS-exchange formaat zou vervangen door het open IMAP-formaat en mee zou werken aan CalDAV

We hebben het over pst, wat een bestandsformaat is. Dat heeft weinig te maken met een netwerkprotocol zoals IMAP. IMAP bepaalt hoe iets over het netwerk gaat, niet over hoe een server het opslaat.

Daarnaast is IMAP zeker niet heilig. Niet dat het slecht is, maar MAPI (waarmee Exchange en Outlook communiceren) bieden zeker wel voordelen om efficienter met netwerk- en serverresources om te springen.

[Reactie gewijzigd door Anoniem: 19339 op 27 oktober 2009 15:34]

Iedereen hierboven ziet er wel leuke voordelen in voor conversie naar andere formaten. Ik zelf denk dat vooral virusmakers er erg blij mee zullen zijn, want nu hoeven ze niet meer die lastige Outlook security te omzeilen, maar kunnen ze in één keer alsnog bij alle e-mailadressen op een computer komen.

Euh, PST's hebben niks met security van Outlook an sich te maken. Dat word namelijk echt niet in PST's opgeslagen, hooguit een wachtwoord op die PST's.

Outlook security, bijvoorbeeld geblokkeerde attachments, word grotendeels in de registry geregeld.

En dat is allemaal allang gedocumenteerd, niet alleen bij de Knowledge Base van Microsoft zelf, maar op tig andere sites.

Ik denk dat Dennis het anders bedoeld. Als je via de API Outlook benaderd krijg je allerlei beveiligingsmeldingen en een time-out van 1 minuut om te reageren. Als een virus gewoon rechtstreeks zijn mail in de Outbox kan droppen, zal Outlook bij het opstarten uit zichzelf de mail gaan verzenden.
Dus er is wel weer een klein gaatje bijgekomen om spam-mail te versturen.

Een mail dat in de outbox is gezet buiten de API om is niet bekend in de tabellen die de outbox vanuit de software beheren. Ik weet niet of Outlook dat dan zal zien, laat staan versturen.

In elk geval is het voor Microsoft een kleine moeite om, als dit security-issue bestaat, om dat te repareren.

En waarom is dat een gaatje? Je kunt toch ook gewoon via de API versturen? Met die meldingen zal het wel mee vallen, want je moet toch op een of andere manier mail kunnen versturen via die API.

Het zou wel fijn zijn als je zonder problemen je adresboek, email en andere zaken kunt inlezen in een ander programma dan outlook. Het huidige converteer-exporteer-importeer principe laat te wensen over.

Sws. het backuppen van Outlook is tragisch slecht geregeld.

En dat voor een business app.

De bedoeling is dat je outlook gebruikt als frontend van Exchange. Volgens mij is de backup van exchange prima. In een zakelijke omgeving wil je gewoon de mail centraal opslaan.

Daarnaast. De meeste applicaties hebben geen backup functie. De meeste mensen maken backups van hun belangrijke bestanden (inclusief pst files) of van hun hele machine. Ik zou gek worden als ik bij elk programma apart een backup moet gaan maken.....

Die bedoeling heeft Outlook zeker niet exclusief.

Iedereen moet weleens Outlook opnieuw installeren, vanwege herinstallatie oid. Het is fijn als je dan makkelijk je bestanden opnieuw inlezen kan.

Tenzij iemand kan uitleggen hoe je dat nu het beste kan doen.

Als je Outlook gewoon herinstalleert (zoals in bv Office verwijderen en terug installeren) blijven alle bestanden staan... geen werk hier dus.

Ik bedoel ook als je Windows opnieuw moet installeren..

als jij een nieuwe autoradio koopt dan komt hij ook direct op met je voorkeurszenders van de oude radio ?????

Ik moet hem toch wel even opnieuw programmeren hoor.

als je de hele boel onderuit schopt dan is het niet zo gek dat je even je instellingen weer terug moet zetten.

Eigenlijk vind ik het "backuppen" van outlook bestanden eerder handig om van outlook af te komen. Zo'n lekker programma is het nou ook weer niet, dus als je je pst files gewoon in Thunderbird zou kunnen importeren zou dat de wereld vooruit helpen

Outlook is ook gewoon een applicatie voor privé mail hoor, het wordt geleverd in alle office-pakketten, ook in het standaard pakket.

Dat Outlook ook door veel bedrijven gebruikt wordt lijkt mij meer een logische keuze gebaseerd op een aantal kenmerken van het programma; Email, contactpersonen en agenda gecombineerd in één programma. Andere email clients hebben die combinatie niet (missen bijvoorbeeld een agenda-functie) en moeten dus draaien naast een andere applicatie (zoals een agenda).

Het was fijn geweest als Microsoft een fatsoenlijk export- en backupfunctie ingebouwd had, dan hadden ze van mij dat bestandsformaat niet openbaar hoeven maken:)

In alle pakketten zit Outlook, behalve het pakket voor 'Thuisgebruik en Studenten': het privé-pakket dus. (Bron: http://office.microsoft.c...ducts/FX101635841043.aspx)

Met de Exchange-integratie ligt de focus echt op zakelijk gebruik. Voor privé-gebruik werkt Windows (Live) Mail waarschijnlijk handiger. Mensen gebruiken Outlook vaak thuis omdat ze het gewend zijn van het werk, echt niet omdat ze alle functies nodig hebben.

Zou er dan een methode komen om met Rsync wél netjes een pst te syncen?

Het zou nog gemakkelijker zijn dat elk mailprogramma alle mogelijke soorten konden inlezen. Dat zou lekker werken met importeren en exporteren. Hier ben ik in ieder geval al blij mee dat ze hem vrijgeven. Hopelijk duurt het niet lang voordat programma's zoals windows mail dit bestandstype kunnen uitlezen.

Nu .edb nog!

En wat voor nut zou het hebben om het .edb formaat open te maken?

Net als het open maken van alle anderen formaten: de bestanden kunnen gebruiken in andere programma's, zodat je je MS software zou kunnen inruilen voor die van de concurrent als dat nodig is, ipv vast te zitten aan een complete MS omgeving omdat je je mail niet van exchange naar een andere omgeving kunt krijgen, en daarom tot in het einde der tijden een exchange server nodig hebt (omdat je anders alle oude mail kwijt bent), met bijbehorende client (outlook) en vanwege die client windows systemen, etc etc etc...

en .dbx

en .exe kan dat eigenlijk wel?

Een .exe bestand, is opgebouwd volgens het PE/COFF formaat. Dit formaat beschrijft eigenlijk hoe de diverse onderdelen/secties van een programma aan elkaar gerelateerd zijn. De daadwerkelijke instructies voor de CPU bestaan gewoon uit x86 en x64 bineaire instructies... Dit geld in ieder geval voor native applicaties.

.Net executables hebben ook een PE header + wat native code die zaken afvangt zoals het ontbreken van het .net framework (dat je bijvoorbeeld een melding krijgt om deze te downloaden), maar de rest van het bestand bestaat uit MSIL code.

Over het PE/COFF formaat is al heel veel informatie te vinden. Ook op MSDN: http://msdn.microsoft.com/en-us/magazine/cc301805.aspx en http://support.microsoft....spx?scid=kb;en-us;q121460

Het is misschien niet "open" als de defintie die hier tegenwoordig voor gehanteerd wordt, maar MS geeft er in ieder geval behoorlijk wat informatie over vrij en er is veel over te vinden vanuit derden. Je moet natuurlijk wel wat kaas gegeten hebben van de materie om het te begrijpen ... dit is wel even wat anders dan het uitlezen van een XML bestand zeg maar

[Reactie gewijzigd door Laurens-R op 27 oktober 2009 11:31]