Re: [Lazarus] FPC arm building issue
Seems like you're just getting a broken revision. This: zipper.pp(2721) Error: Error while assembling exitcode 1 zipper.pp(2721) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted paszlib\units\arm-linux\zipper.s: Assembler messages: paszlib\units\arm-linux\zipper.s:3325: Error: immediate expression requires a # prefix -- `cmp r8,INVALID' is something that should NEVER happen because it happens at .s generated by the compiler. Just report or wait for fix. -- View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-FPC-arm-building-issue-tp4033590p4033593.html Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus IDE in Italian: who asked for it ?
2013/9/25 duilio foschi > after installation, my Lazarus IDE (1.0.12) is in Italian. > > This means that Lazarus has been correctly localized but ... I never > asked for it :) > > I prefer to have Lazarus IDE in English. > > How do I switch to English ? > > Thank you > > Duilio > Ciao Duilio! I too. Go to Strumenti->Opzioni->Ambiente->Desktop->Inglese (hanno tradotto anche questo eheh) Anyway, I prefer english for better support. Best regards, Kjow www.kjow.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Lazarus IDE in Italian: who asked for it ?
after installation, my Lazarus IDE (1.0.12) is in Italian. This means that Lazarus has been correctly localized but ... I never asked for it :) I prefer to have Lazarus IDE in English. How do I switch to English ? Thank you Duilio -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] FPC arm building issue
Hi all, I'm trying to compile FPC svn trunk (r25569) for android-arm and linux-arm under Windows 8, but I have some troubles. Reverting to r24523, all works well! 1) arm-linux make clean crossall crossinstall OS_TARGET=linux CPU_TARGET=arm CROSSOPT="-CfVFPV3 -OoFASTMATH -CpARMV6" INSTALL_PREFIX=c:\Develop3\fpc\fpctrunk PP=C:\Develop3\fpc\fpctrunk\bin\i386-win32\fpc.exe CROSSBINDIR=C:\Android\NDK\android-ndk-r8e\toolchains\arm-linux-androideabi-4.4.3\prebuilt\windows-x86_64\arm-linux-androideabi\bin-arm-linux BINUTILSPREFIX=arm-linux- ... ... ... Compiling .\paszlib\src\zip.pas Compiling .\paszlib\src\ziputils.pas Assembling ziputils Assembling zip Compiling .\paszlib\src\unzip.pas Assembling unzip Compiling .\paszlib\src\zipper.pp Compiling .\paszlib\src\zstream.pp Writing Resource String Table file: zstream.rst Assembling zstream Writing Resource String Table file: zipper.rst Assembling zipper zipper.pp(2721) Error: Error while assembling exitcode 1 zipper.pp(2721) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted paszlib\units\arm-linux\zipper.s: Assembler messages: paszlib\units\arm-linux\zipper.s:3325: Error: immediate expression requires a # prefix -- `cmp r8,INVALID' make[3]: *** [smart] Error 1 make[3]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src/packages' make[2]: *** [packages_smart] Error 2 make[2]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src' make[1]: *** [build-stamp.arm-linux] Error 2 make[1]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src' make: *** [crossall] Error 2 c:\Develop3\fpc\svn_sources\fpctrunk_src> 2) arm-android make clean crossall crossinstall OS_TARGET=android CPU_TARGET=arm CROSSOPT="-CfVFPV3 -OoFASTMATH -CpARMV6" INSTALL_PREFIX=c:\Develop3\fpc\fpctrunk PP=C:\Develop3\fpc\fpctrunk\bin\i386-win32\fpc.exe CROSSBINDIR=C:\Android\NDK\android-ndk-r8e\toolchains\arm-linux-androideabi-4.4.3\prebuilt\windows-x86_64\bin BINUTILSPREFIX=arm-linux-androideabi- ... ... ... make[3]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src/packages' make[2]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src' make rtl_all FPC=c:/Develop3/fpc/svn_sources/fpctrunk_src/compiler/ppcrossarm.ex e FPCFPMAKE=c:/Develop3/fpc/svn_sources/fpctrunk_src/compiler/ppc.exe RELEASE=1 make[2]: Entering directory `c:/Develop3/fpc/svn_sources/fpctrunk_src' make -C rtl all make[3]: Entering directory `c:/Develop3/fpc/svn_sources/fpctrunk_src/rtl' make -C android all make[4]: Entering directory `c:/Develop3/fpc/svn_sources/fpctrunk_src/rtl/androi d' C:/Develop3/fpc/Utils/bin/i386-win32/gmkdir.exe -p c:/Develop3/fpc/svn_sources/f pctrunk_src/rtl/units/arm-android C:\Android\NDK\android-ndk-r8e\toolchains\arm-linux-androideabi-4.4.3\prebuilt\w indows-x86_64\bin/arm-linux-androideabias.exe -o c:/Develop3/fpc/svn_sources/fp ctrunk_src/rtl/units/arm-android/prt0.o arm/prt0.as process_begin: CreateProcess((null), C:\Android\NDK\android-ndk-r8e\toolchains\a rm-linux-androideabi-4.4.3\prebuilt\windows-x86_64\bin/arm-linux-androideabias.e xe -o c:/Develop3/fpc/svn_sources/fpctrunk_src/rtl/units/arm-android/prt0.o arm/ prt0.as, ...) failed. make (e=2): Impossibile trovare il file specificato. make[4]: *** [prt0.o] Error 2 make[4]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src/rtl/android ' make[3]: *** [android_all] Error 2 make[3]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src/rtl' make[2]: *** [rtl_all] Error 2 make[2]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src' make[1]: *** [build-stamp.arm-android] Error 2 make[1]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src' make: *** [crossall] Error 2 c:\Develop3\fpc\svn_sources\fpctrunk_src> Note: i386-win32 and x86_64-win64 are ok (with both r25569 and r24523)! e.g. make clean all install OS_TARGET=win32CPU_TARGET=i386 INSTALL_PREFIX=c:\Develop3\fpc\fpctrunk PP=C:\Develop3\fpc\Bootstrap\ppc386.exe AND make clean crossall crossinstall OS_TARGET=win64 CPU_TARGET=x86_64 INSTALL_PREFIX=c:\Develop3\fpc\fpctrunk PP=C:\Develop3\fpc\Bootstrap\ppc386.exe ... ... ... Installation package winunits-jedi for target x86_64-win64 succeeded Skipped package x11 which has been disabled for target x86_64-win64 Skipped package xforms which has been disabled for target x86_64-win64 Installing package zlib Installation package zlib for target x86_64-win64 succeeded Skipped package zorba which has been disabled for target x86_64-win64 Installing package fpc-all Installation package fpc-all for target x86_64-win64 succeeded make[4]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src/packages' make[3]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src' make[2]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src' make[1]: Leaving directory `c:/Develop3/fpc/svn_sources/fpctrunk_src' c:\Develop3\fpc\svn_sources\fpctrunk_src> Thank you! Kjow -- ___ Lazarus mailing list
Re: [Lazarus] Memory leak in PascalScript
2013/9/25 Flávio Etrusco > On Wed, Sep 25, 2013 at 12:27 AM, silvioprog wrote: > > Hello, > > > > Can you help me to fix this issue?: > > > > https://github.com/remobjects/pascalscript/issues/61 > > > > Thank you! > > > > -- > > Silvio Clécio > > My public projects - github.com/silvioprog > > > > -- > > I guess the fpc-pascal list is a better place for this post. > > Best regards, > Flávio Yes. Thank you Flávio, I'll do it. -- Silvio Clécio My public projects - github.com/silvioprog -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Memory leak in PascalScript
On Wed, Sep 25, 2013 at 12:27 AM, silvioprog wrote: > Hello, > > Can you help me to fix this issue?: > > https://github.com/remobjects/pascalscript/issues/61 > > Thank you! > > -- > Silvio Clécio > My public projects - github.com/silvioprog > > -- I guess the fpc-pascal list is a better place for this post. Best regards, Flávio -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What's behind an IP address
On 25.09.2013 15:56, Antonio Fortuny wrote: Hi Folks. This is specifically neither a Lazarus nor an FPC question but because I'm using a Lazarus project (along with Synapse) I ask this question: Having an IP address, which could be the best question to ask to that IP to know what's behind this address ? - Echo (ICMP 7) is not sufficient - Get an SSH connection: if it answers then should be almost certainly a Unix box otherwise can be a Win box - if it a Win box, how to confirm ? Thanks a lot, Antonio. nmap detect the OS and sometimes service versions -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] ide automaximizing on startup
> > What OS? > Debian Linux testing (GTK2) > Have you tried to close the IDE and delete the environmentoptions.xml? > I have now, and that actually seems to have taken care of the problem. Thank you very much! -SG -- Seth Grover ΜΟΛΩΝ ΛΑΒΕ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What's behind an IP address
On 25/09/13 13:56, Antonio Fortuny wrote: > Hi Folks. > > This is specifically neither a Lazarus nor an FPC question but > because I'm using a Lazarus project (along with Synapse) I ask this > question: Having an IP address, which could be the best question to > ask to that IP to know what's behind this address ? - Echo (ICMP 7) > is not sufficient - Get an SSH connection: if it answers then should > be almost certainly a Unix box otherwise can be a Win box - if it a > Win box, how to confirm ? > > Thanks a lot, > > Antonio. > I guess some of this could be of help : https://www.google.co.uk/search?q=os+fingerprinting&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&channel=fflb&gws_rd=cr&ei=X-BCUoURh67RBfzjgKAB :) -L. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] What's behind an IP address
Hi Folks. This is specifically neither a Lazarus nor an FPC question but because I'm using a Lazarus project (along with Synapse) I ask this question: Having an IP address, which could be the best question to ask to that IP to know what's behind this address ? - Echo (ICMP 7) is not sufficient - Get an SSH connection: if it answers then should be almost certainly a Unix box otherwise can be a Win box - if it a Win box, how to confirm ? Thanks a lot, Antonio. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
What has this to do with Lazarus? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 09/25/2013 01:39 PM, Nikolay Nikolov wrote: 15 years ago is 1998, so yes. Maybe it was even earlier? Probably. In fact, 15 years ago the product using the 68K version of the library was released. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 25.9.2013 г. 14:14 ч., Michael Schnell wrote: On 09/25/2013 01:00 PM, Nikolay Nikolov wrote: Real mode or DPMI? IMHO, real mode is doable, DPMI - not so much (at least not without using a certain DPMI host with special modifications). Did DPMI even exist at this time ? 15 years ago is 1998, so yes. Maybe it was even earlier? IIRC it was a native 8088 chip -> http://en.wikipedia.org/wiki/Intel_8088 Real mode it is, then. DPMI requires 286+ and the DOS extender that FPC uses is 386+. Borland Pascal 7 had a 16-bit (286+) DPMI dos extender. We can implement that as well, as soon as the i8086 large memory model is finished. The Open Watcom linker we're using already supports the DOS/16M extender binary format I think. Nikolay -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 09/25/2013 01:00 PM, Nikolay Nikolov wrote: Real mode or DPMI? IMHO, real mode is doable, DPMI - not so much (at least not without using a certain DPMI host with special modifications). Did DPMI even exist at this time ? IIRC it was a native 8088 chip -> http://en.wikipedia.org/wiki/Intel_8088 -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 25.9.2013 г. 14:01 ч., Michael Schnell wrote: More than 15 Years ago I on DOS did do the first tests for my preemptive multitasking library (in C), that that finally works (up til now) in an 68K product. :-) Real mode or DPMI? IMHO, real mode is doable, DPMI - not so much (at least not without using a certain DPMI host with special modifications). Nikolay -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
More than 15 Years ago I on DOS did do the first tests for my preemptive multitasking library (in C), that that finally works (up til now) in an 68K product. :-) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 09/25/2013 12:20 PM, Reinier Olislagers wrote: You do know there already is a GO32v2 compiler? I suppose same does create 32 bit code usable in a DOS-alike environment, and thus could be a target for allowing linking to an internal-user-land-thread enabled version of pthreadlib (while I don't think anybody ever bothered to do a 16 bit version of such a library. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
Nikolay Nikolov wrote: On 09/25/2013 11:26 AM, Michael Schnell wrote: On 09/24/2013 10:58 AM, Nikolay Nikolov wrote: When you try to create a thread, your program terminates and writes a message that threading is not supported. While this absolutely does make sense, one could think about alternatives. AFAIK, (at least for some archs) there is a variant of the pthread (="POSIX thread") library, that internally does "user-land multithreading". IIRC, the original POSIX definition was done with exactly this in mind and, regarding Linux, the original Linux implementations (aka "Linux Threads") was not fully compatible with POSIX. Only some years ago, the Linux changed it's way of Kernel-based thread handling to the POSIX compatible "NPTL" implementation. Thus it should be possible to link fpc projects to a user-land thread enabled version of pthreadlib and allow for working with TThread in DOS. I've actually thought about implementing some sort of multithreading for DOS for a long time. The problems are the following: 1) DOS functions are not reetrant and are thus not safe to call from different threads. There's an undocumented InDOS flag that indicates whether a DOS function is safe to call: http://stanislavs.org/helppc/int_21-34.html But the RTL currently doesn't check it before every call and normally it's only used when writing TSRs. It's more complex than that: there's undocumented provision in DOS for context switching under certain well-defined conditions, and each context can invoke int 21h irrespective of other contexts' states. That sort of thing was used fairly extensively by- for example- IBM real-time control executives (RIC card etc.) but it wasn't until the 1990s that it leaked to general knowledge see Ralph Brown's list). 2) In DPMI protected mode applications (such as go32v2), you cannot modify the return address from within an interrupt handler, which means you cannot implement your task scheduler as a timer interrupt handler, because you won't be able to switch to a different context from there. Doing this would require modifications to the DPMI host (cwsdpmi.exe) and will not work if another DPMI host is active (such as when running in a windows dos prompt, etc.) 3) Even if you solve 2), DPMI requires that all code and data touched from an interrupt handler to be locked, so that it cannot be swapped out. This is a tedious and error prone task to do from a high level language such as pascal. You should ensure that your entire scheduler's code and data are locked. An alternative option is to switch to a DPMI host, that doesn't support swapping (i.e. cwsdpr0.exe), but then you lose the virtual memory support (and thus the ability to run on machines that don't have enough memory). 2) and 3) do not apply to 16-bit MS-DOS. Another option is to implement cooperative multitasking, which would require each thread to call periodically an yield function. This solves 1), 2) and 3), but threaded code written for other OSes will require modifications to run under DOS. However, that's still better than not running at all. The DPMI issue sounds... interesting, but if I recall correctly what you do is provide a per-thread entry point analogous to a unix signal. A preemption interrupt transfers control to this, and then a coroutine mechanism- outside the ISR- transfers control to the most deserving thread. Sorry if that's a bit vague, it's been many years since I played with this. Implementation left as an exercise :-) Whether it's really worth tackling, and whether any implementation can be really reliable, are questions to be considered. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 25/09/2013 12:15, Michael Schnell wrote: > On 09/25/2013 10:51 AM, Hans-Peter Diettrich wrote: >> >> Do you mean DOS as a (16 bit) OS, or as a DOS-Box (terminal)? > > Of course limited to a "DOS box" this would make no sense at all. > > I did not do a research on in what environments such pthreadlib could > work. I suppose you need a 32 bit DOS extender. You do know there already is a GO32v2 compiler? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 09/25/2013 10:51 AM, Hans-Peter Diettrich wrote: Do you mean DOS as a (16 bit) OS, or as a DOS-Box (terminal)? Of course limited to a "DOS box" this would make no sense at all. I did not do a research on in what environments such pthreadlib could work. I suppose you need a 32 bit DOS extender. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 09/25/2013 11:26 AM, Michael Schnell wrote: On 09/24/2013 10:58 AM, Nikolay Nikolov wrote: When you try to create a thread, your program terminates and writes a message that threading is not supported. While this absolutely does make sense, one could think about alternatives. AFAIK, (at least for some archs) there is a variant of the pthread (="POSIX thread") library, that internally does "user-land multithreading". IIRC, the original POSIX definition was done with exactly this in mind and, regarding Linux, the original Linux implementations (aka "Linux Threads") was not fully compatible with POSIX. Only some years ago, the Linux changed it's way of Kernel-based thread handling to the POSIX compatible "NPTL" implementation. Thus it should be possible to link fpc projects to a user-land thread enabled version of pthreadlib and allow for working with TThread in DOS. I've actually thought about implementing some sort of multithreading for DOS for a long time. The problems are the following: 1) DOS functions are not reetrant and are thus not safe to call from different threads. There's an undocumented InDOS flag that indicates whether a DOS function is safe to call: http://stanislavs.org/helppc/int_21-34.html But the RTL currently doesn't check it before every call and normally it's only used when writing TSRs. 2) In DPMI protected mode applications (such as go32v2), you cannot modify the return address from within an interrupt handler, which means you cannot implement your task scheduler as a timer interrupt handler, because you won't be able to switch to a different context from there. Doing this would require modifications to the DPMI host (cwsdpmi.exe) and will not work if another DPMI host is active (such as when running in a windows dos prompt, etc.) 3) Even if you solve 2), DPMI requires that all code and data touched from an interrupt handler to be locked, so that it cannot be swapped out. This is a tedious and error prone task to do from a high level language such as pascal. You should ensure that your entire scheduler's code and data are locked. An alternative option is to switch to a DPMI host, that doesn't support swapping (i.e. cwsdpr0.exe), but then you lose the virtual memory support (and thus the ability to run on machines that don't have enough memory). 2) and 3) do not apply to 16-bit MS-DOS. Another option is to implement cooperative multitasking, which would require each thread to call periodically an yield function. This solves 1), 2) and 3), but threaded code written for other OSes will require modifications to run under DOS. However, that's still better than not running at all. Nikolay -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 25/09/2013 11:29, Reinier Olislagers wrote: > On 25/09/2013 10:51, Hans-Peter Diettrich wrote: >> Michael Schnell schrieb: >> Do you mean DOS as a (16 bit) OS, or as a DOS-Box (terminal)? > > As the thread indicates: DOS as in 16 bit DOS, runnable on an 8086 > processor. Yes, the compiler could run in the DOSBox product (which > emulates the environment 16 bit DOS runs under) but not in a cmd/command > window/"DOS" window on e.g. x64 Windows Vista+ Oops, sorry. No idea if the compiler could run on 8086, I seem to remember Nikolay implemented a cross compiler because (I think) the compiler needed more memory than could easily be gotten from DOS... Anyway, obviously the resulting code /is/ targeted for 8086... -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 25/09/2013 10:51, Hans-Peter Diettrich wrote: > Michael Schnell schrieb: > Do you mean DOS as a (16 bit) OS, or as a DOS-Box (terminal)? As the thread indicates: DOS as in 16 bit DOS, runnable on an 8086 processor. Yes, the compiler could run in the DOSBox product (which emulates the environment 16 bit DOS runs under) but not in a cmd/command window/"DOS" window on e.g. x64 Windows Vista+ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
Michael Schnell schrieb: On 09/24/2013 10:58 AM, Nikolay Nikolov wrote: When you try to create a thread, your program terminates and writes a message that threading is not supported. While this absolutely does make sense, one could think about alternatives. AFAIK, (at least for some archs) there is a variant of the pthread (="POSIX thread") library, that internally does "user-land multithreading". IIRC, the original POSIX definition was done with exactly this in mind and, regarding Linux, the original Linux implementations (aka "Linux Threads") was not fully compatible with POSIX. Only some years ago, the Linux changed it's way of Kernel-based thread handling to the POSIX compatible "NPTL" implementation. Thus it should be possible to link fpc projects to a user-land thread enabled version of pthreadlib and allow for working with TThread in DOS. Do you mean DOS as a (16 bit) OS, or as a DOS-Box (terminal)? I doubt that a DOS OS supports threading at all (scheduling...). What's a thread worth when it never executes? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
Michael Schnell wrote: On 09/24/2013 10:58 AM, Nikolay Nikolov wrote: When you try to create a thread, your program terminates and writes a message that threading is not supported. While this absolutely does make sense, one could think about alternatives. AFAIK, (at least for some archs) there is a variant of the pthread (="POSIX thread") library, that internally does "user-land multithreading". IIRC, the original POSIX definition was done with exactly this in mind and, regarding Linux, the original Linux implementations (aka "Linux Threads") was not fully compatible with POSIX. Only some years ago, the Linux changed it's way of Kernel-based thread handling to the POSIX compatible "NPTL" implementation. Thus it should be possible to link fpc projects to a user-land thread enabled version of pthreadlib and allow for working with TThread in DOS. The change happened at different times on different architectures. I've definitely had to write (Lazarus) code to take this into account, since the PID behaviour differed. But since AIUI LinuxThreads generally attempted to use multiple processes, getting that to work on DOS might be a problem. It would probably be easier to start off with coroutines, and then to change them into real threads by preemption. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why development remains constant for msdos?
On 09/24/2013 10:58 AM, Nikolay Nikolov wrote: When you try to create a thread, your program terminates and writes a message that threading is not supported. While this absolutely does make sense, one could think about alternatives. AFAIK, (at least for some archs) there is a variant of the pthread (="POSIX thread") library, that internally does "user-land multithreading". IIRC, the original POSIX definition was done with exactly this in mind and, regarding Linux, the original Linux implementations (aka "Linux Threads") was not fully compatible with POSIX. Only some years ago, the Linux changed it's way of Kernel-based thread handling to the POSIX compatible "NPTL" implementation. Thus it should be possible to link fpc projects to a user-land thread enabled version of pthreadlib and allow for working with TThread in DOS. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
