Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
On Sat, Jul 19, 2014 at 3:18 PM, Eric Auer wrote:
>
> Hi Jeremy,
>
> > In shell/command.c the following patch should fix the issue (assuming
> > switchar changed).
> > @@ -331,8 +331,10 @@
> > break;
> >case CMD_SPECIAL_DIR: /* pass '\\' & '.' too */
> > if(*rest == '\\' || *rest == '.' || *rest == ':') break;
> > +if (!isoptch(*rest) && *rest == '/') break;
> >default:/* pass '/', ignore ',', ';' & '=' */
> > -if(!*rest || *rest == '/') break;
> > +if(!*rest || isoptch(*rest)) break;
> > if(isargdelim(*rest)) {
> > rest = ltrimcl(rest);
> > break;
>
> Strange idea, why would "/" always be a switchar
> even if you explititly configure switchar to be
> something else? Which Windows versions do that?
>
I'm not sure what you are asking. The default switchar is '/' and so will
be treated as an option specifier instead of directory unless the switchar
is changed.
> And of course: Which software is known to set the
> switchar to for example "-" while at the same time
> expecting "/" to be still simultaneously valid...?
>
> Regards, Eric
>
>
The first part is so / treated same as \ (but not if it is currently the
switch character, which by default it is).
The second part is so it does not hard code / as the switchar.
Note unless the switchar support is compiled in, then FreeCom hard codes it
to '/'. There may be a few other places in FreeCom that expect / as the
switchar; the only one I know of is the help text.
Jeremy
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Hi Jeremy,
> In shell/command.c the following patch should fix the issue (assuming
> switchar changed).
> @@ -331,8 +331,10 @@
> break;
>case CMD_SPECIAL_DIR: /* pass '\\' & '.' too */
> if(*rest == '\\' || *rest == '.' || *rest == ':') break;
> +if (!isoptch(*rest) && *rest == '/') break;
>default:/* pass '/', ignore ',', ';' & '=' */
> -if(!*rest || *rest == '/') break;
> +if(!*rest || isoptch(*rest)) break;
> if(isargdelim(*rest)) {
> rest = ltrimcl(rest);
> break;
Strange idea, why would "/" always be a switchar
even if you explititly configure switchar to be
something else? Which Windows versions do that?
And of course: Which software is known to set the
switchar to for example "-" while at the same time
expecting "/" to be still simultaneously valid...?
Regards, Eric
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
On Fri, Jul 18, 2014 at 3:00 PM, Juan Manuel Guerrero
wrote:
> I do not know if this is the right place to report this FreCom issue and
> I do not know if this issue is already well known but I would like to
> report it anyway.
> Please inspect the following batch file:
>
> @echo off
> @echo %0
> :loop
> @echo %1
> shift
> if not "%1" == "" goto loop
> @echo finished with arguments
>
>
> command.com on MSDOS 6.22, Win98SE and WinXP and also cmd.exe of WinXP
> will produce the following output:
>test.bat
>./..
>../.
> if the batch file is started like this:
>test.bat ./.. ../.
>
> If I use FreeCom 0.84-pre2 XMS_Swap [August 28 2006 00:32:15] shipped
> with FreeDOS 1.1 and start the batch file in exactly the same way I get
> the following output:
>test.bat
>.
>/..
>..
>/.
> As can be seen, FreCom seems to interpret any slash as an option marker
> like in "/?" to get help. All microsoft command.com versions and also
> cmd.exe
> do interpret the slash as an option marker only if it is preceded by some
> kind of blank character. This makes it necessary to quote paths written in
> unix-style like:
>"../foo/bar/."
> if they shall be passed as arguments to a batch file to be processed by
> FreCom.
> Is this behavior a bug or a feature?
>
> Regards,
> Juan M. Guerrero
>
>
In shell/command.c the following patch should fix the issue (assuming
switchar changed).
@@ -331,8 +331,10 @@
break;
case CMD_SPECIAL_DIR: /* pass '\\' & '.' too */
if(*rest == '\\' || *rest == '.' || *rest == ':') break;
+if (!isoptch(*rest) && *rest == '/') break;
default:/* pass '/', ignore ',', ';' & '=' */
-if(!*rest || *rest == '/') break;
+if(!*rest || isoptch(*rest)) break;
if(isargdelim(*rest)) {
rest = ltrimcl(rest);
break;
I have uploaded a build to http://www.fdos.org/kernel/command/FreeCom/test/
commandx.com is same as command.com but compressed with UPX
Note this is very minimally tested build.
dif file has a few other minor changes [use switchar for help /? --> -?
and start towards help showing proper switchar]
To change the switchar add
?switchar=-
to config.sys (you can remove the prompt ? if you always want the switchar
changed)
Note: you will need to add a shell line using the proper switchar or you
may get errors about path when /P and /E are parsed as paths instead of
options.
I believe this is based on latest SVN sources, (the diff file is from svn
diff) as compiled with Open Watcom.
Jeremy
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 19.07.2014 07:35, schrieb Steve Nickolas: > On Sat, 19 Jul 2014, Mateusz Viste wrote: > >> Hi all, >> >> I think this problem goes beyond "path separators". As I understand it, >> any argument including a slash character will get exploded. So yes, this >> might be used as path separator, but not only. For eg. sed expects slash >> delimited values inside a single argument. >> >> @Juan - you also write about other "different issues and limitations" - >> could you please post us a list? Even if FreeCom is semi-maintained >> nowadays, it would still be interesting to know what kind of quirks you >> found there.. > command.com should not be splitting the strings at all, but should send > the parameters "in the raw", terminated (iirc) by a newline. It is for > the libc to parse them; if otherwise, that is a serious flaw. > > There *is* the option of 4DOS. > Thanks to pointing me to 4DOS. It was the shell I used everyday in the 80s when I worked on DOS. I had completely forgotten about it but it is nice to see that it is still available. It solves the problem. Regards, Juan M. Guerrero -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 19.07.2014 00:37, schrieb Ralf Quint: > On 7/18/2014 3:09 PM, Juan Manuel Guerrero wrote: >> This is not really disappointing. I was only testing for the >> possibility to recommend the FreeDOS 1.1 distribution as an >> alternative to WinXP and/or Win98SE to build DJGPP ports but this >> seems not really be possible due to different issues and limitations. >> Regards, Juan M. Guerrero > DOS internally should work with both back and forward slashes. Yes, I am aware of this. > "Any" DOS command shell, including MS-DOS 6.22 should not except the > forward slashes even in a batch file as you claim, "unless" the "switch > char" has been deliberately been changed to something else via INT21H, > function 37h... I have installed FreeDOS 1.1 9 or 10 months ago. I have played with it some days and not used it again until yesterday. I have certainly not recompiled any components of the distribution. I have also not installed any other program that should change the "switch char". No other programs have been installed except those installed by the distribution proper. All this means that I am not aware of having deliberately changed the "switch char". May be it is worth to inspect the FreeCom sources to check what "switch char" has been selected and what does change it if at all. Regards, Juan M. Guerrero -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] major paradigm shift - light processors from HP and memristors
Hi Jim, DOS fans, (your signature is too long! Who needs all those kilo mega giga tera numbers explained so often?) It seems that memristors are actually not really slow to write :-) The article that you cite says "Windows, Linux, HP-UX, Tru64, and NonStop" were in the experiments. It does not really explain in which way light is used - between chips? In the chips? To peripherals? TiO2 memristors seem to offer 5-10 times more memory per chip size in comparison to Flash or RAM. https://en.wikipedia.org/wiki/Memristor says that memristor storage was available on lab scale 2012 but real products are only expected by 2018. Note that MRAM (magnetoresistive) & PRAM (phase change) are already on the market with competitive specs. FeRAM is also available but less attractive. Real products seem to aim more at Flash SSD audience: https://en.wikipedia.org/wiki/MRAM#History https://en.wikipedia.org/wiki/Phase_change_memory#Timeline The technologies under development: CBRAM, ReRAM (or RRAM: memristors), SONOS; FJG, Racetrack- and Millipede-memory. Another possibility is "nvRAM" (brand name) which just copies RAM to Flash when power is lost. In any case, it is of course an interesting question: What would YOU do in which APPLICATION if you had all your data in RAM or RAMDISK? It can indeed shift the choice of preferred algorithms. It would also shift some OS performance questions, of course. Not sure how DOS is involved: If disk no longer is separate from RAM, would DOS itself care, performance-wise? See: https://en.wikipedia.org/wiki/Universal_memory And of course a question to those who already use SSD or RAMDISKs for most of their DOS activities, how has that changed the way you use DOS now? :-) Cheers, Eric > if you didn't know, HP has started inventing a light-based computer > using memristors instead of an SSD and it moves 6TB of data/sec, it's > based on a continuum and uses very little power. so we have a > paradigm shift here... should be out at end of decade. they showed it > at vegas, and are planning on putting it in cell phones. it has > multiple light processors. they need devs to make an OS for this > since it's memristors (storage) are essentially NVRAM with a delay on > writes (takes time to switch and the change is analog). > > http://www.hpl.hp.com/news/2008/apr-jun/memristor.html > http://www.businessweek.com/articles/2014-06-11/with-the-machine-hp-may-have-invented-a-new-kind-of-computer -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS JetDirect driver (was: Getting started)
Hi, On Sat, Jul 19, 2014 at 4:45 AM, Jim Michaels wrote: > - Original Message - > >> From: Steve Nickolas >> To: Technical discussion and questions for FreeDOS developers. >> >> Cc: >> Sent: Friday, July 18, 2014 11:21 AM >> Subject: Re: [Freedos-devel] FreeDOS JetDirect driver (was: Getting started) >> >> On Fri, 18 Jul 2014, Rugxulo wrote: >> >>> On Fri, Jul 18, 2014 at 10:26 AM, Jim Michaels >> wrote: a windows version of DJGPP is in the wings, based on cygwin I think. >> there's an alpha you can compile with cygwin. >>> >>> This is so wrong that I don't even know where to begin. >>> >>> DJGPP only runs on DOS (or similar like NTVDM or DOSEMU). It does not >>> use PE/COFF at all, nor DLLs, nor Win32 APIs. > > I know about PE's they are for windows Not only, no. There are many OSes that use PE, but the most popular is Windows (for various cpu architectures). You can (and people did) develop a PE loader or even DOS extender based upon PE. That may or may not come with some kind of Win32 API emulation. See WDOSX or HX. I even think TASM32.EXE (5.3) is some kind of hybrid (32RTM?). BTW, here's an old (circa 1999) thread about "the future of DJGPP". You may recognize some of the wanted features. http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp/1999/04/08/18:11:43 Obviously, in hindsight, nobody knew half of what was coming. > - the DJGPP compiler you are compiling itself will likely compile to a PE, > but the code it generates/targets is dos i386 and not a PE. Yes, I already mentioned Andrew Wu's cross-compiler. Yes, it's Windows (MinGW) hosted, and yes it seems to work correctly. This is good since Win64 doesn't support self-hosted DJGPP. Heck, it might even be faster (debatable! benchmark first!) than native DOS. https://github.com/andrewwutw/build-djgpp/releases http://www.bttr-software.de/forum/board_entry.php?id=13451#p13451 > for DJGPP, the host for the current stable version right now is windows XP or > DOS on i386 and the target is DOS i386. Yes, and in fact, most DJGPP ports of GNU stuff won't build easily without LFNs, hence XP (or similar) is implicitly required. Too bad Vista on up were so much worse. At least XP was bearable. > the new alpha cygwin DJGPP compiler's host is I think any version of windows > possibly even x64 cpu - > it must be compiled right now, a binary may be later. the target is still DOS > i386 to my knowledge. Can you point me to this mythical URL you keep mentioning? :-) > the cygwin-compiled version just allows folks who have 64-bit windows to > compile DOS programs > (so they can run them on a VM or whatever, Well, we already had OpenWatcom able to cross-compile to several targets, including DOS. But DJGPP is better in some ways. I'm glad we finally have a decent publicly available Windows cross-compiler binary. > I highly suggest windows 8/8.1 for VM stuff since those versions of windows > can share .VHD files' filesytem > with windows like a drive and this makes development a snap! Yes, sounds good, but I don't know of all the various emulators that support whatever formats. Anyways, IIRC, the FreeDOS networking guide just recommends setting up an FTP server to share files between host and guest. > - I may have to upgrade my windows now that win8 is more stable - I can work > around the flaws just to get that feature... xp mode was never stable and now > it's supported no more "XP Mode" felt like more of a marketing gimmick than anything. Plus it doubled your cpu and RAM requirements. And it wasn't even offered to home users, officially. > - mo more fixes to its bugginess and crashes - I really wanted to run dos > stuff on it! but it looks like > vbox+win8 for me pretty soon...) besides, win8/8.1 has the free hyper-v VM > and hyper-v VM server as well (both free). Hyper-V isn't necessarily going to work. I don't know if it supports DOS. I'd highly doubt it unless told otherwise. I heard FreeBSD runs okay, maybe some enterprise-y Linuxes too, but I dunno the details. Anyways, Hyper-V is Win8 Pro 64-bit with (advanced) VT-X only! So it's not for everybody, obviously. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] about pth and pthreads
Hi, On Sat, Jul 19, 2014 at 4:07 AM, Jim Michaels wrote: > > PTH for long-running math-type processes gives the equivalent performance of > coroutines, > where the thread runs until it blocks, then the other routine runs until it > blocks, etc. this can run > in user-space and requires no kernel mods. http://www.gnu.org/software/pth/ "GNU Pth - The GNU Portable Threads" " Pth is a very portable POSIX/ANSI-C based library for Unix platforms which provides non-preemptive priority-based scheduling for multiple threads of execution (aka ``multithreading'') inside event-driven applications. All threads run in the same address space of the server application, but each thread has it's own individual program-counter, run-time stack, signal mask and errno variable. " Also, see GNU Modula-2 (which AFAIK doesn't have a DJGPP binary, sadly): http://www.nongnu.org/gm2/gm2-libs-isopth.html > fsu pthreads, nice stable implmentation I hear, it's at > http://moss.csc.ncsu.edu/~mueller/pthreads/ and is from the Army. > did I say this already? I think I did (sorry if I did, hope this helps if I > didn't). > > no docs in it. Originally, I think FSU was written for GNAT Ada tasking. (But I don't know if that was ever properly supported under DJGPP. Looks like no.) It too is cooperative only, AFAIK. This was first used for FreeDOS in recent years in Khusraw's p7zip 9.13 since he cleaned it up and got it working again. (Thus instead of GNU pth + Watt-32, you only need FSU.) http://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/7zip/9.20.1/FSUPthreads314DJ.zip -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Hi, On Sat, Jul 19, 2014 at 12:00 AM, Mateusz Viste wrote: > > I think this problem goes beyond "path separators". As I understand it, any > argument including a slash character > will get exploded. So yes, this might be used as path separator, but not > only. For eg. sed expects slash > delimited values inside a single argument. sed can use other delimiters, if slash is too prohibitive. Sometimes that makes things easier to read and write. Just for silly example (tested under Cygwin): echo $PATH | sed -e '/.*\(\/cygdrive\/c\/rugxulo\/watcom19\/BINNT\).*/s//\1/' ... vs. ... echo $PATH | sed -e '\,.*\(/cygdrive/c/rugxulo/watcom19/BINNT\).*,s,,\1,' Oops. Or did you mean that this bug in FreeCOM might break sed invocations? I doubt it, the double quotes after -e probably protect it from munging. > @Juan - you also write about other "different issues and limitations" - could > you please post us a list? > Even if FreeCom is semi-maintained nowadays, it would still be interesting to > know what kind of quirks you found there.. The only one I'm aware of is the "read from NUL" bug, which Jeremy already fixed in his unofficial Git snapshots. (Yes, for some reason, DJGPP insists on reading from that, heh.) http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2014/03/28/16:38:35 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] major paradigm shift - light processors from HP and memristors
if you didn't know, HP has started inventing a light-based computer using memristors instead of an SSD and it moves 6TB of data/sec, it's based on a continuum and uses very little power. so we have a paradigm shift here... should be out at end of decade. they showed it at vegas, and are planning on putting it in cell phones. it has multiple light processors. they need devs to make an OS for this since it's memristors (storage) are essentially NVRAM with a delay on writes (takes time to switch and the change is analog). http://www.hpl.hp.com/news/2008/apr-jun/memristor.html http://www.businessweek.com/articles/2014-06-11/with-the-machine-hp-may-have-invented-a-new-kind-of-computer http://h30507.www3.hp.com/t5/Innovation-HP-Labs/The-Machine-HP-Labs-launches-a-bold-new-research-initiative-to/ba-p/165648#.U7SGevldU3I http://www.hpl.hp.com/news/ - Jim Michaels jmich...@yahoo.com j...@renewalcomputerservices.com http://RenewalComputerServices.com http://JesusnJim.com (my personal site, has software) --- IEC Units: Computer RAM & SSD measurements, microsoft disk size measurements (note: they will say GB or MB or KB or TB when it is IEC Units!): [KiB] [MiB] [GiB] [TiB] [2^10B=1,024^1B=1KiB] [2^20B=1,024^2B=1,048,576B=1MiB] [2^30B=1,024^3B=1,073,741,824B=1GiB] [2^40B=1,024^4B=1,099,511,627,776B=1TiB] [2^50B=1,024^5B=1,125,899,906,842,624B=1PiB] SI Units: Hard disk industry disk size measurements: [kB] [MB] [GB] [TB] [10^3B=1,000B=1kB] [10^6B=1,000,000B=1MB] [10^9B=1,000,000,000B=1GB] [10^12B=1,000,000,000,000B=1TB] [10^15B=1,000,000,000,000,000B=1PB] -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS JetDirect driver (was: Getting started)
- Original Message - > From: Steve Nickolas > To: Technical discussion and questions for FreeDOS developers. > > Cc: > Sent: Friday, July 18, 2014 11:21 AM > Subject: Re: [Freedos-devel] FreeDOS JetDirect driver (was: Getting started) > > On Fri, 18 Jul 2014, Rugxulo wrote: > >> Hi, Jim, >> >> On Fri, Jul 18, 2014 at 10:26 AM, Jim Michaels > wrote: >>> >>> a windows version of DJGPP is in the wings, based on cygwin I think. > there's an alpha you can compile with cygwin. >> >> This is so wrong that I don't even know where to begin. >> >> DJGPP only runs on DOS (or similar like NTVDM or DOSEMU). It does not >> use PE/COFF at all, nor DLLs, nor Win32 APIs. I know about PE's they are for windows - the DJGPP compiler you are compiling itself will likely compile to a PE, but the code it generates/targets is dos i386 and not a PE. don't worry. let me explain. cross compilers like DJGPP have 2 things, a host and a target. the target is the OS/cpu that will run the program. the host is the os/cpu combination that will run the compiler. you can host on windows and target for android on ARM7 cpu (or FreeDOS with FAT32!) with gcc (provided proper runtimes etc - that's where most of the compiler dev time is I would guess, making the runtimes and customizing libs to be os-specific). for DJGPP, the host for the current stable version right now is windows XP or DOS on i386 and the target is DOS i386. the new alpha cygwin DJGPP compiler's host is I think any version of windows possibly even x64 cpu - it must be compiled right now, a binary may be later. the target is still DOS i386 to my knowledge. the cygwin-compiled version just allows folks who have 64-bit windows to compile DOS programs (so they can run them on a VM or whatever, I highly suggest windows 8/8.1 for VM stuff since those versions of windows can share .VHD files' filesytem with windows like a drive and this makes development a snap! - I may have to upgrade my windows now that win8 is more stable - I can work around the flaws just to get that feature... xp mode was never stable and now it's supported no more - mo more fixes to its bugginess and crashes - I really wanted to run dos stuff on it! but it looks like vbox+win8 for me pretty soon...) besides, win8/8.1 has the free hyper-v VM and hyper-v VM server as well (both free). no worries. :-] get used to the host+target concept in cross compilers, you may run into it sometime. >> >> Sure, you can have some kind of bound / family (or whatever) .EXE that >> can run on two OSes (RSXNT). Sure, with other compilers (like >> OpenWatcom), you can use external API emulation (e.g. HX). Sure, you >> can use GCC to cross-compile from one OS to another. And yes, both >> Cygwin and DJGPP use GCC + BinUtils, but everything else is different >> (especially the libc). >> >> I don't know who told you that DJGPP was ever interested in Windows. >> If you have proof of that, I'd like to see it, but I'm not holding > my >> breath. :-) > > Prolly thinking MinGW? > > -uso. not mingw. DJGPP. anyway, mingw has been dropped in favor of mingw-w64 since it targets both 32 and 64-bit windows (and also has compilers for darwin/mac, linux, etc, but those are target=host). the windows compilers both target and host windows, and have 4 flavors (and are built on fedora I think?), (just count in binary to list them): i686 host, i686 target i686 host, x86_64 target x86_64 host, i686 target x86_64 host, x86_64 target MSVC also comes with like compilers (each in a separate dir). -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] about pth and pthreads
PTH for long-running math-type processes gives the equivalent performance of coroutines, where the thread runs until it blocks, then the other routine runs until it blocks, etc. this can run in user-space and requires no kernel mods. but threading requires kernel mods according to the pth documentation (it's a good technical training read on multithreading technology and how pth works). mostly, pth is best suited to event-driven applications. fsu pthreads, nice stable implmentation I hear, it's at http://moss.csc.ncsu.edu/~mueller/pthreads/ and is from the Army. did I say this already? I think I did (sorry if I did, hope this helps if I didn't). no docs in it. - Jim Michaels jmich...@yahoo.com j...@renewalcomputerservices.com http://RenewalComputerServices.com http://JesusnJim.com (my personal site, has software) --- IEC Units: Computer RAM & SSD measurements, microsoft disk size measurements (note: they will say GB or MB or KB or TB when it is IEC Units!): [KiB] [MiB] [GiB] [TiB] [2^10B=1,024^1B=1KiB] [2^20B=1,024^2B=1,048,576B=1MiB] [2^30B=1,024^3B=1,073,741,824B=1GiB] [2^40B=1,024^4B=1,099,511,627,776B=1TiB] [2^50B=1,024^5B=1,125,899,906,842,624B=1PiB] SI Units: Hard disk industry disk size measurements: [kB] [MB] [GB] [TB] [10^3B=1,000B=1kB] [10^6B=1,000,000B=1MB] [10^9B=1,000,000,000B=1GB] [10^12B=1,000,000,000,000B=1TB] [10^15B=1,000,000,000,000,000B=1PB] -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
