|
| Integration af nye systemer i WIN32, er de~ Fra : Per Pedersen |
Dato : 15-11-03 19:29 |
|
Hej gruppe
Inden jeg går igang med det helt store project, integration i WIN32, af et
system som er meget tilsvarende, AmigaOS Datatypes,.bestående af et Main
Library, og et antal sub Libraries, som gør det ethvert F.eks. Grafik, eller
billedbehandlingsprogram, muligt at læse og skrive enhver GFX filtype som
brugeren har en datatype installeret for, det samme gæler andre typer af
programmer.
Det system her, er et af dem som jeg for alvor savner i Windows.
Det at skrive de nødvendige rutiner til, håndtering, læsning og skrivning er
ikke noget problem i sig selv, jeg har fremragende materiale om hele AmigaOS
Datatypes systemet liggende, og jeg har så også disassembleret hele
molevitten, for at studere dets virke nøjere, jeg har siden 1990, kodet en
hel del MC680x0 Assembler, men er det overhovedet muligt at gennemføre sådan
et project, eller må jeg nøjes med at bygge en konverter.
På forhånd tak for en hel bunke af gode og kreative svar.
Mvh
Per Pedersen
| |
Bertel Brander (17-11-2003)
| Kommentar Fra : Bertel Brander |
Dato : 17-11-03 00:29 |
|
Per Pedersen wrote:
> Hej gruppe
>
> Inden jeg går igang med det helt store project, integration i WIN32, af et
> system som er meget tilsvarende, AmigaOS Datatypes,.bestående af et Main
> Library, og et antal sub Libraries, som gør det ethvert F.eks. Grafik, eller
> billedbehandlingsprogram, muligt at læse og skrive enhver GFX filtype som
> brugeren har en datatype installeret for, det samme gæler andre typer af
> programmer.
>
> Det system her, er et af dem som jeg for alvor savner i Windows.
>
> Det at skrive de nødvendige rutiner til, håndtering, læsning og skrivning er
> ikke noget problem i sig selv, jeg har fremragende materiale om hele AmigaOS
> Datatypes systemet liggende, og jeg har så også disassembleret hele
> molevitten, for at studere dets virke nøjere, jeg har siden 1990, kodet en
> hel del MC680x0 Assembler, men er det overhovedet muligt at gennemføre sådan
> et project, eller må jeg nøjes med at bygge en konverter.
>
Jeg er ikke sikker på at jeg helt forstår hvad det er du vil lave.
Vil du lave et system der gør at hvis nogen laver en ny fil-type,
f.ex et nyt billed format, så kan brugeren instalere et bibliotek
som gør at alle eksisterende Windows applikationer kan læse, ændre
og skrive billeder i dette format?
Hvis det er det der er formålet er jeg ikke sikker på at det er muligt.
Så vidt jeg ved skriver og læser de fleste billed behandlings programmer
selv filen, og konverterer det til et format som det kan bruge internt.
Jeg ved næsten ikke noget om OLE og COM, men så vidt jeg ved er det en
måde at løse problemet på. Her instalerer brugeren et applikation der
kan arbejde med bestemte fil-formater, denne applikation kan så køre
i andre applikationer.
/b
| |
Per Pedersen (17-11-2003)
| Kommentar Fra : Per Pedersen |
Dato : 17-11-03 02:51 |
|
> Jeg er ikke sikker på at jeg helt forstår hvad det er du vil lave.
>
> Vil du lave et system der gør at hvis nogen laver en ny fil-type,
> f.ex et nyt billed format, så kan brugeren instalere et bibliotek
> som gør at alle eksisterende Windows applikationer kan læse, ændre
> og skrive billeder i dette format?
>
> Hvis det er det der er formålet er jeg ikke sikker på at det er muligt.
Det er lige præcist formålet, da jeg har mange tusinde datafiler liggende,
som der ikke findes et Windooze program som kan forstå, deriblandt
IFF-ANIM5, IFF-ANIM7, IFF-FTXT, IFF-SMUS, og det er en træls afærre at
skulle konvertere dem alle enkeltvis.
> Så vidt jeg ved skriver og læser de fleste billed behandlings programmer
> selv filen, og konverterer det til et format som det kan bruge internt.
Ja, og Nej, det kræver selvfølgeligt at formatet er direkte understøttet,
ellers er du lige vidt.
> Jeg ved næsten ikke noget om OLE og COM, men så vidt jeg ved er det en
> måde at løse problemet på. Her instalerer brugeren et applikation der
> kan arbejde med bestemte fil-formater, denne applikation kan så køre
> i andre applikationer.
Det var da måske en mulighed, så det vil jeg da undersøge nærmere.
Mvh
Per Pedersen
| |
Mogens Hansen (17-11-2003)
| Kommentar Fra : Mogens Hansen |
Dato : 17-11-03 07:04 |
|
"Per Pedersen" <perpedersen33@hotmail.com> wrote in message
news:3fb82971$0$7844$ba624c82@nntp04.dk.telia.net...
[8<8<8<]
> Det er lige præcist formålet, da jeg har mange tusinde datafiler liggende,
> som der ikke findes et Windooze program som kan forstå, deriblandt
> IFF-ANIM5, IFF-ANIM7, IFF-FTXT, IFF-SMUS, og det er en træls afærre at
> skulle konvertere dem alle enkeltvis.
Prøv at kigge hos LeadTools ( http://www.leadtools.com), de har biblioteker
til at konveretere grafik.
Lyder http://www.leadtools.com/sdk/raster/formats/raster-format-iff.htm som
noget der passer ?
Venlig hilsen
Mogens Hansen
| |
Jonas Meyer (17-11-2003)
| Kommentar Fra : Jonas Meyer |
Dato : 17-11-03 10:10 |
|
"Per Pedersen" <perpedersen33@hotmail.com> wrote in message news:<3fb82971$0$7844$ba624c82@nntp04.dk.telia.net>...
> > Jeg er ikke sikker på at jeg helt forstår hvad det er du vil lave.
> >
> > Vil du lave et system der gør at hvis nogen laver en ny fil-type,
> > f.ex et nyt billed format, så kan brugeren instalere et bibliotek
> > som gør at alle eksisterende Windows applikationer kan læse, ændre
> > og skrive billeder i dette format?
> >
> > Hvis det er det der er formålet er jeg ikke sikker på at det er muligt.
>
> Det er lige præcist formålet, da jeg har mange tusinde datafiler liggende,
> som der ikke findes et Windooze program som kan forstå, deriblandt
> IFF-ANIM5, IFF-ANIM7, IFF-FTXT, IFF-SMUS, og det er en træls afærre at
> skulle konvertere dem alle enkeltvis.
Jeg har lidt svært at se, præcis hvorfor det ikke skulle være muligt.
Du laver bare en dll med et tilpas abstrakt API. Så kan programmerne
benytte det api. Når brugeren henter den opdaterede dll, så får alle
programmerne mulighed for at læse de nye filformater.
Kig på
www.imagelib.org
Der ligger et opensource projekt med præcis det formål. Og ja,
man vil kunne lave sit program således at det automatisk understøtter
nye formater, når librariet bliver udvidet. Ydermere kan du udvide det
med loaders til dine egne formater.
Dog skal det også siges at det ikke er perfekt, der er stadig mangler
i projektet, men de ret begrænsede.
| |
Bertel Brander (17-11-2003)
| Kommentar Fra : Bertel Brander |
Dato : 17-11-03 20:27 |
|
Jonas Meyer wrote:
> "Per Pedersen" <perpedersen33@hotmail.com> wrote in message news:<3fb82971$0$7844$ba624c82@nntp04.dk.telia.net>...
>
>>>Jeg er ikke sikker på at jeg helt forstår hvad det er du vil lave.
>>>
>>>Vil du lave et system der gør at hvis nogen laver en ny fil-type,
>>>f.ex et nyt billed format, så kan brugeren instalere et bibliotek
>>>som gør at alle eksisterende Windows applikationer kan læse, ændre
>>>og skrive billeder i dette format?
>>>
>>>Hvis det er det der er formålet er jeg ikke sikker på at det er muligt.
>>
>>Det er lige præcist formålet, da jeg har mange tusinde datafiler liggende,
>>som der ikke findes et Windooze program som kan forstå, deriblandt
>>IFF-ANIM5, IFF-ANIM7, IFF-FTXT, IFF-SMUS, og det er en træls afærre at
>>skulle konvertere dem alle enkeltvis.
>
>
> Jeg har lidt svært at se, præcis hvorfor det ikke skulle være muligt.
>
> Du laver bare en dll med et tilpas abstrakt API. Så kan programmerne
> benytte det api. Når brugeren henter den opdaterede dll, så får alle
> programmerne mulighed for at læse de nye filformater.
>
Som jeg forstod OP, ville han have at eksisterende applikationer skulle
bruge hans API, det tror jeg vil være svært.
Man kan naturligvis godt lave nye applikationer der bruger et bestemt
API til at læse/skrive filer.
/b
| |
Per Pedersen (18-11-2003)
| Kommentar Fra : Per Pedersen |
Dato : 18-11-03 01:19 |
|
> > Jeg har lidt svært at se, præcis hvorfor det ikke skulle være muligt.
> >
> > Du laver bare en dll med et tilpas abstrakt API. Så kan programmerne
> > benytte det api. Når brugeren henter den opdaterede dll, så får alle
> > programmerne mulighed for at læse de nye filformater.
> >
>
> Som jeg forstod OP, ville han have at eksisterende applikationer skulle
> bruge hans API, det tror jeg vil være svært.
>
> Man kan naturligvis godt lave nye applikationer der bruger et bestemt
> API til at læse/skrive filer.
>
> /b
>
Hej Bertel
Du har forstået mig helt rigtigt, og jeg er helt med på din besvarelse.
Jeg funderer nu istedet i en lidt anden form for integration, men også den
ide skal undersøges lidt dybere først.
Det drejer sig om en slags handler, som man så kan sætte op, som ethvert
andet program, til at tage sig af alt hvad der hedder EA IFF 85, og løbende
konvertere til et andet brugbart format, det er så at sige det samme system,
men jeg behøver så ikke at ligge og rode inde i Windows.
Hele ideen opstod fordi jeg gerne ville kunne bruge de gamle data, uden
først at skulle ligge og konvertere løbende, og er jo i bund og grund, bare
en automatisering af konverteringsprocessen.
Mvh
Per Pedersen
| |
Andreas Lind Peterse~ (18-11-2003)
| Kommentar Fra : Andreas Lind Peterse~ |
Dato : 18-11-03 15:58 |
|
> Du har forstået mig helt rigtigt, og jeg er helt med på din besvarelse.
>
> Jeg funderer nu istedet i en lidt anden form for integration, men også den
> ide skal undersøges lidt dybere først.
>
> Det drejer sig om en slags handler, som man så kan sætte op, som ethvert
> andet program, til at tage sig af alt hvad der hedder EA IFF 85, og løbende
> konvertere til et andet brugbart format, det er så at sige det samme system,
> men jeg behøver så ikke at ligge og rode inde i Windows.
>
> Hele ideen opstod fordi jeg gerne ville kunne bruge de gamle data, uden
> først at skulle ligge og konvertere løbende, og er jo i bund og grund, bare
> en automatisering af konverteringsprocessen.
Du kan da (tastemæssigt) hurtigt konvertere en større omgang billeder
med ImageMagicks convert-værktøj (kommandolinje). Jeg kunne ikke forestille
mig andet, end at ImageMagick understøtter EA IFF 85, men er ikke sikker.
Hvis du har cygwin installeret, kan du fx køre
for img in *.iff; do convert $f `basename $f .iff`.png ; done
Hvis dine billeder ligger i en eller anden subdirectorystruktur, kan du
sige
mkdir konverterede_billeder
for img in `find /cygdrive/c/gamle_billeder -name '*.iff'`
do
convert $f konverterede_billeder/`basename $f .iff`.png
done
Ovenstående kan gøres endnu mere raffineret, så det bevarer directory-
strukturen, men det finder du nok selv ud af :)
Se:
http://www.cygwin.com/
http://www.imagemagick.org/
Mange hilsner,
Andreas Lind Petersen
| |
Per Pedersen (18-11-2003)
| Kommentar Fra : Per Pedersen |
Dato : 18-11-03 20:15 |
|
"Andreas Lind Petersen" <skrog@brok.diku.dk> skrev i en meddelelse
news:slrnbrkcu5.mj.skrog@brok.diku.dk...
> > Du har forstået mig helt rigtigt, og jeg er helt med på din besvarelse.
> >
> > Jeg funderer nu istedet i en lidt anden form for integration, men også
den
> > ide skal undersøges lidt dybere først.
> >
> > Det drejer sig om en slags handler, som man så kan sætte op, som ethvert
> > andet program, til at tage sig af alt hvad der hedder EA IFF 85, og
løbende
> > konvertere til et andet brugbart format, det er så at sige det samme
system,
> > men jeg behøver så ikke at ligge og rode inde i Windows.
> >
> > Hele ideen opstod fordi jeg gerne ville kunne bruge de gamle data, uden
> > først at skulle ligge og konvertere løbende, og er jo i bund og grund,
bare
> > en automatisering af konverteringsprocessen.
>
> Du kan da (tastemæssigt) hurtigt konvertere en større omgang billeder
> med ImageMagicks convert-værktøj (kommandolinje). Jeg kunne ikke
forestille
> mig andet, end at ImageMagick understøtter EA IFF 85, men er ikke sikker.
>
> Hvis du har cygwin installeret, kan du fx køre
>
> for img in *.iff; do convert $f `basename $f .iff`.png ; done
>
> Hvis dine billeder ligger i en eller anden subdirectorystruktur, kan du
> sige
>
> mkdir konverterede_billeder
> for img in `find /cygdrive/c/gamle_billeder -name '*.iff'`
> do
> convert $f konverterede_billeder/`basename $f .iff`.png
> done
>
> Ovenstående kan gøres endnu mere raffineret, så det bevarer directory-
> strukturen, men det finder du nok selv ud af :)
>
> Se:
> http://www.cygwin.com/
> http://www.imagemagick.org/
>
> Mange hilsner,
> Andreas Lind Petersen
Hej Andreas
Du har ganske som så mange andre, desværre misforstået hele EA IFF 85
formatet, hvilket jeg kort har beskrevet i et tidligere indlæg, noget som
selv såkaldte "proffer" også gør i flæng, det er ikke nødvendigvis billeder
der er tale om, men mange forskelige slags data, F.eks. er IFF-FTXT et
formateret tekst format, IFF-DR2D, et format til vektorgrafik, IFF-SAMP, et
format til samplet lyd, IFF-FANT, et format til film, IFF-8SVX, endnu et
format til lyd, IFF-SMUS, et format til MIDI, og der er mange mange flere,
så det her med at bilde folk ind, at ".IFF" automatisk betyder bitmapgrafik,
det er ikke en tidligere Amigabruger der hat startet det, nok snarre een som
aldrig har haft med AmigaOS at gøre.
Det er ikke selve konverteringen der volder problemer, det er en smal sag,
med den rigtige dokumentation på de forskellige formater, og den er at finde
i RKRM sættet til AmigaOS.
Jeg har efterhånden haft en kamp så stor, med Windows, hvor programmer
bruger ".IFF", og i dokumentationen skriver at det altid er det ene, eller
det andet, F.eks. ACDSee, PSP, og CoolEdit, hvilket jo ikke er tilfældet. og
når selv programmører der bliver betalt for deres arbejde klokker sådan i
det, gider nok ikke sætte sig dybere ind i tingene, så er der jo ikke andet
at gøre, end selv at lave noget der fungerer ordentligt.
Jeg har i sin tid lært følgende:
Hvis en variabel ikke er A eller B, så lad være med at være sikker på at den
er C, så er det født til at skulle gå galt på et tidspunkt.
Mvh
Per Pedersen
| |
Bertel Brander (18-11-2003)
| Kommentar Fra : Bertel Brander |
Dato : 18-11-03 20:17 |
|
Per Pedersen wrote:
>>>Jeg har lidt svært at se, præcis hvorfor det ikke skulle være muligt.
>>>
>>>Du laver bare en dll med et tilpas abstrakt API. Så kan programmerne
>>>benytte det api. Når brugeren henter den opdaterede dll, så får alle
>>>programmerne mulighed for at læse de nye filformater.
>>>
>>
>>Som jeg forstod OP, ville han have at eksisterende applikationer skulle
>>bruge hans API, det tror jeg vil være svært.
>>
>>Man kan naturligvis godt lave nye applikationer der bruger et bestemt
>>API til at læse/skrive filer.
>>
>>/b
>>
>
>
> Hej Bertel
>
> Du har forstået mig helt rigtigt, og jeg er helt med på din besvarelse.
>
> Jeg funderer nu istedet i en lidt anden form for integration, men også den
> ide skal undersøges lidt dybere først.
>
> Det drejer sig om en slags handler, som man så kan sætte op, som ethvert
> andet program, til at tage sig af alt hvad der hedder EA IFF 85, og løbende
> konvertere til et andet brugbart format, det er så at sige det samme system,
> men jeg behøver så ikke at ligge og rode inde i Windows.
>
> Hele ideen opstod fordi jeg gerne ville kunne bruge de gamle data, uden
> først at skulle ligge og konvertere løbende, og er jo i bund og grund, bare
> en automatisering af konverteringsprocessen.
>
Måske kan du mounte et drev med din filer? Så applikationerne blot ser
filerne som bitmaps (.bmp-filer) eller hvad der der nu er passende.
Så vidt jeg ved findes der et unix filformat (måske fra star office ?)
som man kan læse på Windows ved at mounte dem vha. en deamon.
Jeg ved ikke hvordan man gør, og jeg tror ikke at det er helt let, men
hvis det var let ville det jo ikke være sjovt. Det vil sansynligvis
være lettere at konvertere dem alle en gang for alle.
Problemet er jo at finde en måde at kile sig ind mellem de fysiske
filer og de programmer der skal kunne bruge filerne.
/b
| |
Thomas Krog (17-11-2003)
| Kommentar Fra : Thomas Krog |
Dato : 17-11-03 13:43 |
|
> Det er lige præcist formålet, da jeg har mange tusinde datafiler liggende,
> som der ikke findes et Windooze program som kan forstå, deriblandt
> IFF-ANIM5, IFF-ANIM7, IFF-FTXT, IFF-SMUS, og det er en træls afærre at
> skulle konvertere dem alle enkeltvis.
Paint Shop Pro kan godt hente iff og der står den kan håndtere bitmap, audio
og multimedia. Jeg skal ikke kunne sige om den kan klare de specifikke
formater du nævner men måske det var et forsøg værd at hente en demo fra:
http://www.paintshoppro.dk/
| |
Per Pedersen (17-11-2003)
| Kommentar Fra : Per Pedersen |
Dato : 17-11-03 15:52 |
|
"Thomas Krog" <rick@kampsax.dtu.dk> skrev i en meddelelse
news:bpafli$2u5f$1@gnd.k-net.dk...
> > Det er lige præcist formålet, da jeg har mange tusinde datafiler
liggende,
> > som der ikke findes et Windooze program som kan forstå, deriblandt
> > IFF-ANIM5, IFF-ANIM7, IFF-FTXT, IFF-SMUS, og det er en træls afærre at
> > skulle konvertere dem alle enkeltvis.
>
> Paint Shop Pro kan godt hente iff og der står den kan håndtere bitmap,
audio
> og multimedia. Jeg skal ikke kunne sige om den kan klare de specifikke
> formater du nævner men måske det var et forsøg værd at hente en demo fra:
>
> http://www.paintshoppro.dk/
>
>
Hej Thomas
Jeg har allerede forsøgt med PSP, og det tilhørende AnimationShop, og hvad
IFF-ILBM angår, da går det fint, men IFF-ANIM, den går desværre ikke.
Tak for forslaget.
Mvh
Per Pedersen.
| |
Per Pedersen (17-11-2003)
| Kommentar Fra : Per Pedersen |
Dato : 17-11-03 16:17 |
|
Hej
Det ser ud til at EA IFF 85, er et meget misforstået format, ihvertfald når
vi snakker Windows, IFF er ikke en filtype i sig selv, jævnfør Appendix A i
"Amiga Rom Kernel Reference Manual", Devices, er det en container, en måde
at strukturere data på, hvad en EA IFF 85 fil så indeholder, det er der
ingen der kan sige noget om, før de har læst filens header.Et kig i samme
manuals, IFF FORM and Chunk Registry, fortæller en hel del om hvordan
formatet er brugt.
Fremfor at navngive en fil ".IFF", så bør man bruge det faktiske indhold,
altså, SMUS, ANIM, 8SVX, OSV, ".8SVX". De her navne er faktisk at finde i
filerne, byte 9-12, big endian byteorden.
Det gør det så ikke nemmere, måden Windows er opbygget på, at filerne, fra
AmigaOS normalt ikke er navngivet med et postfix.
Hvis der er nogen der har noget at spørge om, så er de velkomne.
Mvh
Per Pedersen
| |
|
|