Win3x.Org

Euh... tu as pris des chaines façon C ? Dans ce cas strcmp doit faire:

BOUCLE
-Lire un char dans la chaine 1
-Comparer à 0
-Si = on sort
-Sinon:
--Lire un char de la chaine 2
--Comparer à la chaine 1
--Si = passer au suivant
--Sinon sortie de boucle

Euh... je verrai si j'ai le temps de te coder ça ce soir.
Sinon, une implémentation avec des chaines pascal pourrait être intéressante. Pour info, pascal met la longueur de la chaine de 0à 255 dans la première case du tableau et pas de 0 à la fin. C'est plus simple pour certaines choses. Enfin, je vais voir ce que je peux faire.
Par contre, je ne fais pas de malloc et ce genre de trucs

vu qu'on est sous DOS on peut utiliser l'interruption 21h pour allouer de la mémoire...
de plus si j'arrive à avoir beaucoup de fonction utile on pourra refaire en asm plein de chose..dont le parser si on veut en faire un TSR (parce que 64 ko...)


----
Publié: mardi 5 juin 2007 19:53

NOUVELLE VERSION: 0.2.x ?

bon je ne sais pas vraiment quel est le numéro..je propose 0.2 à voir
en effet j'ai entièrement refais ls en asm..pas encore la couleur(çà vient) et les arguments(là çà va être plus long).

Bref au final il y a:
la branche 0.1.x en C, très complet mais volumineux
" " 0.2.x en asm, peu de possibilitées, mais très compact
(400 octects!!! alors que le ls C fait 52 ko) et plus rapide.

Au final je compte faire disparaitre définitivement le ls C.
J'ai en effet une lib de fonctions asm, qui grossit de jour en jour et je compte mettre ce fameux C à la poubelle pour la plupart de mes projets.

Si il y a des programmeurs asm x86 16 bits intéressés pour cette lib envoyez moi un mp


PS: je mettrai la version 0.2.0 de ls asm en ligne d'ici demain ou après demain.


----
Publié: mardi 5 juin 2007 20:02

ABANDON:

voilà...c'est triste à dire mais malgrès les résultats concluants sur le PC de Pulkomandy j'abandonne le développement de cette lib...
....en partie

pour faire bref disons que je me suis rendu compte que celà créait des .exe très lourds (pour un vieux disque dur), 150 ko sans aucune autre fonctions que les miennes...
de plus je n'ai pas réussi la mise en place d'interruption pour gérer çà et çà n'aurait quasiment pas d'intérêt..


cependant: j'ai décidé et fait une ébauche de programme .com (donc en asm, très rapide ET TRES PETITS <<<< important )
que l'on pourrait lancer via des batchs ou autre, mais qui resterait limités, fenêtres statiques, menus. Mais celà risque de ne pas être très efficace si il y a des appels répétés..mais bon afficher une fenêtre ou deux peut être utile dans un batch (ou dans un script fait avec le language que développe
Maxoul, dont j'ai perdu le nom d'ailleurs )

faut d'abord que je trouve le moyen de récupérer les arguments de la ligne de commande

>>> si des personnes seraient intéressées pour des morceaux de sources de ma lib C je peux les envoyer par mp, donc prévenez moi (avant que tout parte à la poubelle ou dans le dossier "projets abandonnés")

Ben ouais, on peut passer à 0.2 maintenant que luDOS 0.1 est sorti

Le language de Maxoul sera soit BiP, soit MéPI, ça reste à voir.
Il sera peut-être possible d'intégrer des choses dans l'interpréteur de ce langage aussi...
Enfin on en est pas encore là

tr16 a écrit :

ABANDON:

voilà...c'est triste à dire mais malgrès les résultats concluants sur le PC de Pulkomandy j'abandonne le développement de cette lib...
....en partie

pour faire bref disons que je me suis rendu compte que celà créait des .exe très lourds (pour un vieux disque dur), 150 ko sans aucune autre fonctions que les miennes...

Dommage Tr16 ça partait bien!

Sinon tu peux limiter la taille des exe de deux façons:
- enlever la table des symbols. Il y a des utilitaires pour ça.
- ne linker qu'avec les librairies dont tu as vraiment besoin. Il faut que tu dépouille la Libc en petits morceaux ou que tu utilise des morceaux du code source de cette librairie et tu ne linke qu'avec ceux là, et tu empèche d'inclure la Libc en changeant le PATH pour le répertoire local.
Normalement ça devrait te redonner quasiment la même taille qu'avec un exe issue de l'assembleur.

Citation :

de plus je n'ai pas réussi la mise en place d'interruption pour gérer çà et çà n'aurait quasiment pas d'intérêt..

Tu utilises quel compilo?

nasm

corwintirnanog a écrit :

Dommage Tr16 ça partait bien!

Sinon tu peux limiter la taille des exe de deux façons:
- enlever la table des symbols. Il y a des utilitaires pour ça.
- ne linker qu'avec les librairies dont tu as vraiment besoin. Il faut que tu dépouille la Libc en petits morceaux ou que tu utilise des morceaux du code source de cette librairie et tu ne linke qu'avec ceux là, et tu empèche d'inclure la Libc en changeant le PATH pour le répertoire local.
Normalement ça devrait te redonner quasiment la même taille qu'avec un exe issue de l'assembleur.

tu me parles à moitié en chinois là....mais je veux bien essayer..si tu m'expliques en fait je voudrais surtout trouver un moyen d'interfacer de l'asm avec du c sous turbo c ou borland (bref un compilateur 16 bits), j'y gagnerai énormément en performance et taille

Pour le Chinois
- quand j'utilisais Turbo C il y avait un utilitaire nommé "strip" ou quelque chose comme ça. Mais c'était il y a bien longtemps, aujourd'hui je n'ai plus Turbo C, j'utilise seulement DJGPP.
En BCC essaye l'option -v- mais là aussi je ne suis pas sûr, il faudra que tu cherches sur Internet.

- Pour la librairie fais des essais avec l'option -L pour BCC, tu vas vite voir que ça change tout sur un programme qui ne fait pas appel à la librairie.
par exemple si tu es en c:\test tu mets l'option de chemin de librairie comme ça: bcc32 -L\test essai.c

- pour l'interface entre C et assembleur il y a deux chemins possibles
1) Tu utilises des instructions du genre "inline":
asm("mov ax, 0") ;
Mais c'est spécifique à ton compilo.

2) Tu utilises un appel à un programme en assembleur:
Dans ton programme en C tu ecris par exemple:
int toto ;
my_pg_in_asm(toto) ; // appel au programme ASM

et dans ton programme en assembleur tu:
- mets un blanc souligné (un underscore pour les Anglopathes) avant la première lettre soit _my_pg_in_asm

- Il faut que ta convention d'appel soit compatible entre ton programme en C et celui en assembleur. Il y a seulement 2 conventionts d'appel soit C soit Pascal. Windows utilise la convention Pascal. Ca influe sur la façon dont tu accèdes à tes données locales, par exemple le "toto" plus haut.
Grosso modo les donnés locales de ton PG en C sont poussées dans la pile suivant en certain ordre en convention C et dans l'autre en convention Pascal. Cherche sur Wikipedia.

Par contre rien ne change lors de l'accès aux données statiques ce qui alors plus facile. Tes données statiques doivent cependant elles aussi être préfixées par un blanc souligné.

- Il faut revenir en fin de programme asm à ton PG en C, la aussi ça dépends de ton compilo.

Désolé de la taille du post.

Jean-Pierre

Bon voilà comme promis ls.COM <--- important( )

Ne prend pas (encore) en compte les arguments, n'affiche pas le nombre de dossier et de fichiers, pas de couleurs, pas de pause...

juste un affichage des fichiers normaux et des dossiers

---> il est pas complétement pourri, il met un \ devant les dossiers quand même 8) , mais je vous avez prévenu quand asm çà va être moins glorieux.


PS: ceci est le version 0.2.0, elle ne vise qu'à être testée pour recencer des bugs si il y a. Elle est déconseillée pour une utilisation normale (possibilité de débordement en mémoire(à vérifier), peu ergonomique).

De plus elle n'a pas été optimisée ce qui fait qu'elle prendra environ 100 octects de plus que la prochaine version.


EN PREPARATION:
0.2.1: ajout de la couleur selon l'extension(40 %)
0.2.2: prise en compte des arguments ? (10 %)


>>>>>> cette version fonctionne à priorie sur des processeurs:
8086 ?,8186,8286.

Fonctionne sous: DOS, version 3.0 recommandée, fonctionnement sur les versions précendentes non garanti

Et les sources sont ouvertes?

ben vu que ma lib asm est en constante modification(et buguée) je ne vois pas trop l'intérêt de passer des codes foireux pour le moment(mais çà va pas durer)

donc non pour le moment, je les mettrai peut être dans une 1 heure ou 2,quand j'aurais fait le ménage


----
Publié: Jeu 07 Juin 2007 18:07

salut tout le monde j'ai une bonne nouvelle...

voici TEST.COM (nom très original..)

bon concrétement çà remplit votre écran de visage souriant...

(pour ceux qui croivent que je me moque d'eux ou qui ne voient pas le rapport avec LudOS lisez la suite).

Sans passer par les détails techniques, disons que ce programme initialise une interruption (FDh) qui affiche un visage souriant donc pour remplir votre ecran le programme appelle cette interruption: 2000 fois!

bon le rapport avec ludos et que je pensais mettre des interruptions pour ma lib graphique ou le parser de Pulkomandy après l'avoir réécrit en asm.

>>>> si vous testez le programme je ne suis pas responsable des dégats possibles, normalement cette interruption est inutilisée sous DOS (testez uniquement sous dos ou un émulateur).



PS: le problème c'est que une fois le programme terminée...ben le code de l'interruption disparait (pouf plus rien et c'est embêtant)

donc je pensais à :

on met un TSR contenant le code de toute les interruptions LUDOS

PROBLEME: comment on fait un TSR !!!!! HELP


Bon soyons sérieux si quelqu'un sait çà serait très utile pour améliorer ludOS
(notre propre lib C et asm utilisant NOTRE interruption LudOS oh joie, oh miracle......heu m'embale un peu là )


Le test si çà intéresse des gens
(çà m'étonnerait beaucoup... bon allez un slogan " un écran joyeux et simpatique!" heu vous en voulez toujours pas ?)
http://www.mediamax.com/tr16/Hosted/TEST.COM

OBJECTIF:

à terme mettre en place un ensemble d'interruption spécifique à ludOS comme l'int 21h pour DOS.
Elles pourront servir pour des libs graphiques ou pour d'autre language.
Celà permettra: diminuer la taille d'exe justement (adieu les 150 ko pour ma lib graphique tout est dans l'interruption).

Cependant il faudra que tout celà prenne maximun 10 ko je pense pour que l'on puisse la garder sasn géner le DOS.
donc on pourra privilégier:
système ludOS: parser, crypteur ?
micro lib: ?



De plus il suffirait que l'interruption garde un espace de mémoire que le shell pourrait utiliser pour stocker les messages des pipes !!
On pourrait créer des fonctions C si besoin pour interfacer.

Bref, c'est parti...