Barrapunto

Me parece que ofreces muy poca información. Cuéntanos que lenguage has utilizado, si usas bases de datos, librerías externas y cualquier factor que ayude a aclarar el asunto.
Para esta y cualquier otra consulta de soporte técnico que realices en Internet debe ofrecer el máximo de información posible.

Realmente si usas cygwin para el portado del programa no deberias tener "grandes" problemas... En principio cygwin incluye muchisimas las librerias portadas y ademas te proporcionara soporte para la API posix (con lo que no tendrias por que preocuparte "demasiado" por las llamadas al sistema).

No creo que pueda haber mucho escrito sobre como portar programas de unix a windows... se presupone que quien programa sabe que cosas son portables y cuales no (llamadas al sistema por ejemplo). En definitiva... viendo el codigo del programa... deberias saber que cosas son portables y cuales no (ya que algunas de ellas dependen incluso del compilador que uses...).

Un saludo!

El principal problema al migrar de Linux a Windows son las dependencias (sobre todo si hablamos de aplicaciones con interfaz gráfica). Recuerdo también que una vez tuve problemas al portar una aplicación debido a las diferencias en los juegos de carácteres entre Windows y Linux. Yo te recomiendo que estudies lo que necesita dicha aplicación para compilar e ir yendo poco a poco...

XD XD XD XD
Que miedo... ¡que nos invaden!

.

Cygwin es una maravilla. De hecho, te puedes compilar las X y el KDE y verlo funcionar sobre windows. Eso si, que nadie espere velocidad. A mi el KDE me iba lentísimo. Gestores de ventanas más ligeros, como fvwm, van mejor.

Había pensado en sugerir algún emulador sobre windows, como qemu o vmware, pero no creo que te resuelva el problema: puedes arrancar linux sobre windows, pero tendrás dificultades para sacar ficheros desde linux hasta el sistema de archivos de windows. Sí, puedes usar samba, como viene preconfigurado, pero aun así, para usuarios noveles, puede confundir. Y lo peor, va más lento que el cygwin.

Actualmente estoy haciendo esa tarea en la beca que se me concedió haya en Mayo en la Universidad.

Estoy migrando una aplicación que "corre" bajo HP-UX a Windows 2000 y la experiencia ha sido de lo más enriquecedora... aunque no ha sido tarea fácil (en estos momentos, la aplicación está migrada y ya está en explotación porque hay algunas pruebas que sólo puedo ver en entorno real pero los resultados están siendo satisfactorios... menos mal...). En primer lugar la documentación que proporciona Microsoft en el MSDN acerca de este asunto (http://msdn.microsoft.com/library/default.asp?url =/library/en-us/dnucmg/html/ucmglp.asp) es mala y en mi opinión escasa. Los ejemplos son breves y no profundizan lo suficiente como para hacerse una idea de por donde ir en la mayoría de los casos, por lo que vas a ciegas; para ejemplo, dedique practicamente una semana a darme cuenta de que iba a tener que fabricarme mi propio sistema de colas de mensajes compartidas porque aunque Windows dispone de un sistema de colas de mensajes, no es hasta la versión 3.0 de dicho sistema cuando se soporta la asignación de un número (id) a cada mensaje, y la aplicación a portar se basa en la recogida de mensajes de una cola con un id (cada vez que llega un mensaje a una cola MQ-Series el programa principal, un demonio, recoge la información y compone un mensaje que deja en una cola compartida y lanza un hilo, al que indica el identificador del mensaje que ha dejado en la cola compartida, que se encarga de procesar dicho mensaje) y como el Windows 2000 en el que funciona la aplicación no dispone de MSQM 3 pues no me servía... Así que tuve que currarme un sistema de cola compartida a base de memoria compartida y semáforos...
Y así el resto de cosas a portar (hilos, procesos, llamadas al sistema de log,...), que si bien no fueron tan traumáticos, me llevaron su tiempo.

En definitiva, he empleado mucho tiempo buscando documentación y ejemplos para llegar muchas veces a la conclusión de que lo mejor era probar con el ejemplo breve que disponía de MSDN o lo que había de pequeño ejemplo de las clases de algún profesor de una universidad o hacerlo a ciegas a ver que tal...

No es tarea fácil... pero tampoco es tarea difícil... el problema está en que Microsoft y los estándares no son muy amigos, por lo que aquello que parece de lo más evidente en Windows, no lo tienes y aquello que no te piensas que vaya a ser soportado si lo es... Vamos, que te va a tocar compilar muchas veces... pero te garantizo que aprenderás mucho :) Logicamente, cuanto mayor sea el nivel al que trabaje la aplicación, más fácil o más dificil será la tarea, pues todo dependerá de las librerias y frameworks que pueda estar usando la aplicación y si han sido portados a Windows o no, aunque tiene toda la pinta que es algun lenguaje sencillo como C por lo del make...
De hecho, voy a modificar la aplicación para que funcione como un servicio del sistema y se pueda arrancar, parar y reiniciar de forma segura; igualmente voy a aprovechar el sistema de gestión de eventos (sucesos) de Windows para la aplicación ; y ya que estoy un sistema de instalación/desinstalación de la aplicación :D (con InnoSetup). Y porque no se me ocurre nada más, pero ya que le he cogido el gustillo a la cosa...

Un saludo y si necesitas algo, pregunta; aprovecha que alguien ya ha perdido el tiempo en la búsqueda de la respuesta ;)

PD: También es cierto que la aplicación que practicamente he terminado de migrar es en C y mezclarla con C++ no era buena idea por lo que quizás me he complicado un poco al mantenerla lo más "C-only" posible; pero tampoco creo que haya muchas más facilidades en caso de ser C++
PD2: Ahora sí, ruego al moderador, borre el anterior, se me debió de quedar pillado el navegador...

Actualmente estoy haciendo esa tarea en la beca que se me concedió haya en Mayo en la Universidad.

Estoy migrando una aplicación que "corre" bajo HP-UX a Windows 2000 y la experiencia ha sido de lo más enriquecedora... aunque no ha sido tarea fácil (en estos momentos, la aplicación está migrada y ya está en explotación porque hay algunas pruebas que sólo puedo ver en entorno real pero los resultados están siendo satisfactorios... menos mal...). En primer lugar la documentación que proporciona Microsoft en el MSDN acerca de este asunto (http://msdn.microsoft.com/library/default.asp?url =/library/en-us/dnucmg/html/ucmglp.asp) es mala y en mi opinión escasa. Los ejemplos son breves y no profundizan lo suficiente como para hacerse una idea de por donde ir en la mayoría de los casos, por lo que vas a ciegas; para ejemplo, dedique practicamente una semana a darme cuenta de que iba a tener que fabricarme mi propio sistema de colas de mensajes compartidas porque aunque Windows dispone de un sistema de colas de mensajes, no es hasta la versión 3.0 de dicho sistema cuando se soporta la asignación de un número (id) a cada mensaje, y la aplicación a portar se basa en la recogida de mensajes de una cola con un id (cada vez que llega un mensaje a una cola MQ-Series el programa principal, un demonio, recoge la información y compone un mensaje que deja en una cola compartida y lanza un hilo, al que indica el identificador del mensaje que ha dejado en la cola compartida, que se encarga de procesar dicho mensaje) y como el Windows 2000 en el que funciona la aplicación no dispone de MSQM 3 pues no me servía... Así que tuve que currarme un sistema de cola compartida a base de memoria compartida y semáforos...
Y así el resto de cosas a portar (hilos, procesos, llamadas al sistema de log,...), que si bien no fueron tan traumáticos, me llevaron su tiempo.

En definitiva, he empleado mucho tiempo buscando documentación y ejemplos para llegar muchas veces a la conclusión de que lo mejor era probar con el ejemplo breve que disponía de MSDN o lo que había de pequeño ejemplo de las clases de algún profesor de una universidad o hacerlo a ciegas a ver que tal...

No es tarea fácil... pero tampoco es tarea difícil... el problema está en que Microsoft y los estándares no son muy amigos, por lo que aquello que parece de lo más evidente en Windows, no lo tienes y aquello que no te piensas que vaya a ser soportado si lo es... Vamos, que te va a tocar compilar muchas veces... pero te garantizo que aprenderás mucho :) Logicamente, cuanto mayor sea el nivel al que trabaje la aplicación, más fácil o más dificil será la tarea, pues todo dependerá de las librerias y frameworks que pueda estar usando la aplicación y si han sido portados a Windows o no, aunque tiene toda la pinta que es algun lenguaje sencillo como C por lo del make...
De hecho, voy a modificar la aplicación para que funcione como un servicio del sistema y se pueda arrancar, parar y reiniciar de forma segura; igualmente voy a aprovechar el sistema de gestión de eventos (sucesos) de Windows para la aplicación ; y ya que estoy un sistema de instalación/desinstalación de la aplicación :D (con InnoSetup). Y porque no se me ocurre nada más, pero ya que le he cogido el gustillo a la cosa...

Un saludo y si necesitas algo, pregunta; aprovecha que alguien ya ha perdido el tiempo en la búsqueda de la respuesta ;)

PD: También es cierto que la aplicación que practicamente he terminado de migrar es en C y mezclarla con C++ no era buena idea por lo que quizás me he complicado un poco al mantenerla lo más "C-only" posible; pero tampoco creo que haya muchas más facilidades en caso de ser C++
PD2: Ahora sí, ruego al moderador, borre el anterior, se me debió de quedar pillado el Firefox (y encima que ultimamente la conexión de Ya.com no va bien...)

Según el diccionario de la RAE.

hereje.
(Del prov. eretge).
1. com. Persona que niega alguno de los dogmas establecidos por una religión.
2. com. Persona que disiente o se aparta de la línea oficial de opinión seguida por una institución, una organización, una academia, etc.

Y el programa al final no será un apostata
apostatar.
(Del lat. apostatāre).
4. intr. Abandonar un partido para entrar en otro, o cambiar de opinión o doctrina
(supongo que será algo asi como cambiar de de SO)

Con el titulo Unix Code Migration Guide [microsoft.com] Microsoft publico hace unos años una guia para la conversion de codigo fuente desde sistemas Unix-like a Windows, con ejemplos de codigo.

Sobra decir que es igualmente valido para portar de WinAPI a cualquier otro sistema que cumpla POSIX y cubre casi todos los aspectos que puedas imaginar, lo cual lo hace muy util.

Suerte :).

(Después de varios intentos fallidos ayer de publicar esto, por fin, creo que lo voy a conseguir... lego tarde pero llego)

Actualmente estoy haciendo esa tarea en la beca que se me concedió haya en Mayo en la Universidad.

Estoy migrando una aplicación que "corre" bajo HP-UX a Windows 2000 y la experiencia ha sido de lo más enriquecedora... aunque no ha sido tarea fácil (en estos momentos, la aplicación está migrada y ya está en explotación porque hay algunas pruebas que sólo puedo ver en entorno real pero los resultados están siendo satisfactorios... menos mal...). En primer lugar la documentación que proporciona Microsoft en el MSDN acerca de este asunto (http://msdn.microsoft.com/library/default.asp?url =/library/en-us/dnucmg/html/ucmglp.asp) es mala y en mi opinión escasa. Los ejemplos son breves y no profundizan lo suficiente como para hacerse una idea de por donde ir en la mayoría de los casos, por lo que vas a ciegas; para ejemplo, dedique practicamente una semana a darme cuenta de que iba a tener que fabricarme mi propio sistema de colas de mensajes compartidas porque aunque Windows dispone de un sistema de colas de mensajes, no es hasta la versión 3.0 de dicho sistema cuando se soporta la asignación de un número (id) a cada mensaje, y la aplicación a portar se basa en la recogida de mensajes de una cola con un id (cada vez que llega un mensaje a una cola MQ-Series el programa principal, un demonio, recoge la información y compone un mensaje que deja en una cola compartida y lanza un hilo, al que indica el identificador del mensaje que ha dejado en la cola compartida, que se encarga de procesar dicho mensaje) y como el Windows 2000 en el que funciona la aplicación no dispone de MSQM 3 pues no me servía... Así que tuve que currarme un sistema de cola compartida a base de memoria compartida y semáforos...
Y así el resto de cosas a portar (hilos, procesos, llamadas al sistema de log,...), que si bien no fueron tan traumáticos, me llevaron su tiempo.

En definitiva, he empleado mucho tiempo buscando documentación y ejemplos para llegar muchas veces a la conclusión de que lo mejor era probar con el ejemplo breve que disponía de MSDN o lo que había de pequeño ejemplo de las clases de algún profesor de una universidad o hacerlo a ciegas a ver que tal...

No es tarea fácil... pero tampoco es tarea difícil... el problema está en que Microsoft y los estándares no son muy amigos, por lo que aquello que parece de lo más evidente en Windows, no lo tienes y aquello que no te piensas que vaya a ser soportado si lo es... Vamos, que te va a tocar compilar muchas veces... pero te garantizo que aprenderás mucho :) Logicamente, cuanto mayor sea el nivel al que trabaje la aplicación, más fácil o más dificil será la tarea, pues todo dependerá de las librerias y frameworks que pueda estar usando la aplicación y si han sido portados a Windows o no, aunque tiene toda la pinta que es algun lenguaje sencillo como C por lo del make...
De hecho, voy a modificar la aplicación para que funcione como un servicio del sistema y se pueda arrancar, parar y reiniciar de forma segura; igualmente voy a aprovechar el sistema de gestión de eventos (sucesos) de Windows para la aplicación ; y ya que estoy un sistema de instalación/desinstalación de la aplicación :D (con InnoSetup). Y porque no se me ocurre nada más, pero ya que le he cogido el gustillo a la cosa...

Un saludo y si necesitas algo, pregunta; aprovecha que alguien ya ha perdido el tiempo en la búsqueda de la respuesta ;)

PD: También es cierto que la aplicación que practicamente he terminado de migrar es en C y mezclarla con C++ no era buena idea por lo que quizás me he complicado un poco al mantenerla lo más "C-only" posible; pero tampoco creo que haya muchas más facilidades en caso de ser C++
PD2: Ahora sí, ruego al moderador, borre el anterior, se me debió de quedar pillado el Firefox, aunque entre la conexión de Ya.com y que la web de barrapunto le cuesta años cargarla no sé yo que será...
PD3: Después de cinco intentos...

Saludos!! En principio, estoy de acuerdo con otros que te han respondido anteriormente: no das datos que puedan ayudar a que te ayuden, pero ... Puedes intentarlo con: CYGWIN, MinGW o MinGW/MSYS: 1) Como ya han dicho otros, la opción más comoda es CYGWIN. Te da una capa POSIX que te evitará tener que portar las llamadas al sistema; además tienes todas las librerías que te puedan hacer falta y más 2) MinGW + MSYS http://www.mingw.org, que ha sido recientemente PODM proyect of the month en SourceForge ... que no tiene que ver con playgirl of the month :-D) MinGW es un puerto de gcc para Windows que te permite generar aplicaciones nativas (dependientes del c runtime de Windows msvcrt.dll), etc Si tu codigo es ANSI c/c++ no debería darte problemas de portabilidad. El tema de las llamadas al sistema es otro asunto: tendrías que cambiarlas por las equivalentes en la API de Win32. MSYS te permite ejecutar la cadena típica ./configure make [...] En cuanto a "make install" normalmente copia librerías/ejecutables en algun lugar en el que el SO los pueda encontrar, por lo que probablemente no te haga falta pues eso suerte!!