Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PCBoard 15.3 source v0.004
47 views
Skip to first unread message
Trifle Menot
Feb 26, 2013, 8:15:19āÆPM2/26/13
to
Compiles and works. Archive includes compiler and library for building.
v0.004:
All build paths are relative now, you can extract the archive to any
desired location.
Patched source files to work around Borland compiler bug tickled by
NTVDM. Now you can build on WINXP, without DOSBox.
ed2k://|file|PCBoard%2015.3%20source%20code%20v0.004.zip|25893726|3F682E866794414A012F74295B335A78|h=AITR6VVLDS52J4FE7UED44VY3K5UYM3T|/
Efudd
Feb 26, 2013, 8:24:43āÆPM2/26/13
to
I was sitting here fixing the relative path thing in my diffs as you typed
this... :-)
-e
Trifle Menot
Feb 26, 2013, 9:04:47āÆPM2/26/13
to
On Tue, 26 Feb 2013 17:24:43 -0800 (PST), Efudd <jason...@gmail.com>
wrote:
>this include the pplc bits I added?
No. I wanted to fix the relative path build first. Also builds on
WINXP now, without DOSBox.
>You've confirmed it works [builds] for you?
Yes.
I extracted the archive into \tmp\xxx, and moved all my top level \b.
\lib, and \pcbsrc directories to a place where they couldn't be touched,
just to be sure I didn't miss anything. Build successful.
Then I restored my top level directories to their original place in c:\
and built again from there. Both builds produced a pcboardm.exe of the
same size, 976,480 bytes.
>I was sitting here fixing the relative path thing in my diffs as you typed
>this... :-)
Using \PCBS\ as you did, I don't think you ever built .\main, did you?
It was pretty messed up for a relative path build, as it was. Fixed now
though.
If you can apply your pplc work to v0.004 and diff it, I will bundle it
into v0.005.
wrote:
>this include the pplc bits I added?
WINXP now, without DOSBox.
>You've confirmed it works [builds] for you?
I extracted the archive into \tmp\xxx, and moved all my top level \b.
\lib, and \pcbsrc directories to a place where they couldn't be touched,
just to be sure I didn't miss anything. Build successful.
Then I restored my top level directories to their original place in c:\
and built again from there. Both builds produced a pcboardm.exe of the
same size, 976,480 bytes.
>I was sitting here fixing the relative path thing in my diffs as you typed
>this... :-)
It was pretty messed up for a relative path build, as it was. Fixed now
though.
If you can apply your pplc work to v0.004 and diff it, I will bundle it
into v0.005.
Efudd
Feb 26, 2013, 9:11:11āÆPM2/26/13
to
On Tuesday, February 26, 2013 9:04:47 PM UTC-5, Trifle Menot wrote:
>
> >You've confirmed it works [builds] for you?
> Yes.
At this point, I'm assuming you parsed 'it' as v0.004 vs. my PPLC bits.
>
> >You've confirmed it works [builds] for you?
> Yes.
...snip...
> Using \PCBS\ as you did, I don't think you ever built .\main, did you?
> It was pretty messed up for a relative path build, as it was. Fixed now
> though.
I went when I first built main close to a year ago.
> If you can apply your pplc work to v0.004 and diff it, I will bundle it
> into v0.005.
-e
Trifle Menot
Feb 26, 2013, 9:28:24āÆPM2/26/13
to
On Tue, 26 Feb 2013 18:11:11 -0800 (PST), Efudd <jason...@gmail.com>
wrote:
>On Tuesday, February 26, 2013 9:04:47 PM UTC-5, Trifle Menot wrote:
>>
>> >You've confirmed it works [builds] for you?
>> Yes.
>
>At this point, I'm assuming you parsed 'it' as v0.004 vs. my PPLC bits.
Right. I've not tried to add any of your work yet.
>> Using \PCBS\ as you did, I don't think you ever built .\main, did you?
>> It was pretty messed up for a relative path build, as it was. Fixed now
>> though.
>
>Both main and pplc build in my tree... I fixed paths to match my needs as
>I went when I first built main close to a year ago.
>
>> If you can apply your pplc work to v0.004 and diff it, I will bundle it
>> into v0.005.
>
>ACKd. Had to reinstall ed2k... waiting for it to download now.
The build is easier now. I added a batch file to build all the library
pieces. Please see src153.txt for new instructions. It also mentions
pcbxdot. I planned to put that in the archive too, but that crashed dos
pkzip (out of memory), and pcbxdot is still not in the archive. So now
I have a documentation bug in src153.txt. :-\
Maybe I'll get around to using better .zip packer for the next archive
version.
wrote:
>On Tuesday, February 26, 2013 9:04:47 PM UTC-5, Trifle Menot wrote:
>>
>> >You've confirmed it works [builds] for you?
>> Yes.
>
>At this point, I'm assuming you parsed 'it' as v0.004 vs. my PPLC bits.
>> Using \PCBS\ as you did, I don't think you ever built .\main, did you?
>> It was pretty messed up for a relative path build, as it was. Fixed now
>> though.
>
>Both main and pplc build in my tree... I fixed paths to match my needs as
>I went when I first built main close to a year ago.
>
>> If you can apply your pplc work to v0.004 and diff it, I will bundle it
>> into v0.005.
>
>ACKd. Had to reinstall ed2k... waiting for it to download now.
pieces. Please see src153.txt for new instructions. It also mentions
pcbxdot. I planned to put that in the archive too, but that crashed dos
pkzip (out of memory), and pcbxdot is still not in the archive. So now
I have a documentation bug in src153.txt. :-\
Maybe I'll get around to using better .zip packer for the next archive
version.
Efudd
Feb 27, 2013, 12:54:23āÆAM2/27/13
to
On Tuesday, February 26, 2013 9:28:24 PM UTC-5, Trifle Menot wrote:
> >> If you can apply your pplc work to v0.004 and diff it, I will bundle it
> >> into v0.005.
>
> >> If you can apply your pplc work to v0.004 and diff it, I will bundle it
> >> into v0.005.
>
> The build is easier now. I added a batch file to build all the library
> pieces. Please see src153.txt for new instructions. It also mentions
> pcbxdot. I planned to put that in the archive too, but that crashed dos
> pkzip (out of memory), and pcbxdot is still not in the archive. So now
> I have a documentation bug in src153.txt. :-\
.. Ok, built v0.004 on fresh install of WinXP SP3. That went very smooth.
> pieces. Please see src153.txt for new instructions. It also mentions
> pcbxdot. I planned to put that in the archive too, but that crashed dos
> pkzip (out of memory), and pcbxdot is still not in the archive. So now
> I have a documentation bug in src153.txt. :-\
You did well.
1) I've patched in my PPLC changes.
2) I moved all of my changes to relative pathing.
3) I've done a teeny bit of cleanup in the pcboard mak file.
4) I got rid of the *.lib->*.386 stuff you were doing. This was just
and edit of your new batch script and a modification to the pcboard
makefile, compile.bat and renaming a file in MAIN/153. I'm going to
say we don't care about TC30 at this point and removed the conditional
the forced that rename. .LIB is more natural to linker/etc anyway.
At some point, I'll do further cleanup and likely just get rid of all
of the TC30 conditionals/directories/etc.
5) I had to patch LIB/SOURCE/COUNTRY to include an additional component for
PPLC.
5) I had to patch MAIN/SOURCE/PPL/SCRMISC.CPP to add another conditional for
PPLC.
LIB, MAIN and PPLC all build now. It's late, so I'll do a unified diff
tomorrow and validate it against a fresh copy of 0.004 then post it.
As an aside, in looking at PCBXDOT that you provided elsewhere, the contents
of pcbkit_l that I made for PPLC is very different than what they were
shipping. So, I probably should rename the pcbkit_l I make in the PPLC
makefile just for future posterity.
Their PCBKIT_L is simply most of LIB/SOURCE/TOOLKIT/ as a single library.
Their kit does include 2 things we don't appear to have source for: COMMDRV.OBJ
and FOSSIL.OBJ.
-e
Trifle Menot
Feb 27, 2013, 9:59:38āÆAM2/27/13
to
On Tue, 26 Feb 2013 21:54:23 -0800 (PST), Efudd <jason...@gmail.com>
wrote:
>4) I got rid of the *.lib->*.386 stuff you were doing. This was just
>and edit of your new batch script and a modification to the pcboard
>makefile, compile.bat and renaming a file in MAIN/153. I'm going to
>say we don't care about TC30 at this point and removed the conditional
>the forced that rename. .LIB is more natural to linker/etc anyway.
When I compiled with TC30 it produced an executable that crashed. So I
abandoned that idea and focused on BC31.
>At some point, I'll do further cleanup and likely just get rid of all
>of the TC30 conditionals/directories/etc.
If you want to. I wanted to have the whole thing building so I could
hack on the source and see the result. I don't care how messy the build
system is.
>5) I had to patch LIB/SOURCE/COUNTRY to include an additional component for
>PPLC.
>5) I had to patch MAIN/SOURCE/PPL/SCRMISC.CPP to add another conditional for
>PPLC.
>
>LIB, MAIN and PPLC all build now. It's late, so I'll do a unified diff
>tomorrow and validate it against a fresh copy of 0.004 then post it.
>
>As an aside, in looking at PCBXDOT that you provided elsewhere, the contents
>of pcbkit_l that I made for PPLC is very different than what they were
>shipping. So, I probably should rename the pcbkit_l I make in the PPLC
>makefile just for future posterity.
>
>Their PCBKIT_L is simply most of LIB/SOURCE/TOOLKIT/ as a single library.
>Their kit does include 2 things we don't appear to have source for: COMMDRV.OBJ
>and FOSSIL.OBJ.
COMMDRV is the modem multiport board support. CDC omitted that from the
source, we can never build it. Doesn't matter anyway, nobody's going to
use PCBoard in a high density modem setup. There is code that provides
fossil support for standard COM ports, I use it. Perhaps FOSSIL.OBJ was
the fossil interface to COMMDRV, so that won't matter either.
wrote:
>4) I got rid of the *.lib->*.386 stuff you were doing. This was just
>and edit of your new batch script and a modification to the pcboard
>makefile, compile.bat and renaming a file in MAIN/153. I'm going to
>say we don't care about TC30 at this point and removed the conditional
>the forced that rename. .LIB is more natural to linker/etc anyway.
abandoned that idea and focused on BC31.
>At some point, I'll do further cleanup and likely just get rid of all
>of the TC30 conditionals/directories/etc.
hack on the source and see the result. I don't care how messy the build
system is.
>5) I had to patch LIB/SOURCE/COUNTRY to include an additional component for
>PPLC.
>5) I had to patch MAIN/SOURCE/PPL/SCRMISC.CPP to add another conditional for
>PPLC.
>
>LIB, MAIN and PPLC all build now. It's late, so I'll do a unified diff
>tomorrow and validate it against a fresh copy of 0.004 then post it.
>
>As an aside, in looking at PCBXDOT that you provided elsewhere, the contents
>of pcbkit_l that I made for PPLC is very different than what they were
>shipping. So, I probably should rename the pcbkit_l I make in the PPLC
>makefile just for future posterity.
>
>Their PCBKIT_L is simply most of LIB/SOURCE/TOOLKIT/ as a single library.
>Their kit does include 2 things we don't appear to have source for: COMMDRV.OBJ
>and FOSSIL.OBJ.
source, we can never build it. Doesn't matter anyway, nobody's going to
use PCBoard in a high density modem setup. There is code that provides
fossil support for standard COM ports, I use it. Perhaps FOSSIL.OBJ was
the fossil interface to COMMDRV, so that won't matter either.
VinylDoctor
Feb 27, 2013, 10:54:15āÆAM2/27/13
to
On Wednesday, February 27, 2013 6:59:38 AM UTC-8, Trifle Menot wrote:
> On Tue, 26 Feb 2013 21:54:23 -0800 (PST), Efudd <jason...@gmail.com> wrote: >4) I got rid of the *.lib->*.386 stuff you were doing. This was just >and edit of your new batch script and a modification to the pcboard >makefile, compile.bat and renaming a file in MAIN/153. I'm going to >say we don't care about TC30 at this point and removed the conditional >the forced that rename. .LIB is more natural to linker/etc anyway. When I compiled with TC30 it produced an executable that crashed. So I abandoned that idea and focused on BC31. >At some point, I'll do further cleanup and likely just get rid of all >of the TC30 conditionals/directories/etc. If you want to. I wanted to have the whole thing building so I could hack on the source and see the result. I don't care how messy the build system is. >5) I had to patch LIB/SOURCE/COUNTRY to include an additional component for >PPLC. >5) I had to patch MAIN/SOURCE/PPL/SCRMISC.CPP to add another conditional for >PPLC. > >LIB, MAIN and PPLC all build now. It's late, so I'll do a unified diff >tomorrow and validate it against a fresh copy of 0.004 then post it. > >As an aside, in looking at PCBXDOT that you provided elsewhere, the contents >of pcbkit_l that I made for PPLC is very different than what they were >shipping. So, I probably should rename the pcbkit_l I make in the PPLC >makefile just for future posterity. > >Their PCBKIT_L is simply most of LIB/SOURCE/TOOLKIT/ as a single library. >Their kit does include 2 things we don't appear to have source for: COMMDRV.OBJ >and FOSSIL.OBJ. COMMDRV is the modem multiport board support. CDC omitted that from the source, we can never build it. Doesn't matter anyway, nobody's going to use PCBoard in a high density modem setup. There is code that provides fossil support for standard COM ports, I use it. Perhaps FOSSIL.OBJ was the fossil interface to COMMDRV, so that won't matter either.
nice. I think commdrv was just thier custom digiboard driver. and how many are still using the 8 bit digigboards now. I can find the edonkey to download this.
> On Tue, 26 Feb 2013 21:54:23 -0800 (PST), Efudd <jason...@gmail.com> wrote: >4) I got rid of the *.lib->*.386 stuff you were doing. This was just >and edit of your new batch script and a modification to the pcboard >makefile, compile.bat and renaming a file in MAIN/153. I'm going to >say we don't care about TC30 at this point and removed the conditional >the forced that rename. .LIB is more natural to linker/etc anyway. When I compiled with TC30 it produced an executable that crashed. So I abandoned that idea and focused on BC31. >At some point, I'll do further cleanup and likely just get rid of all >of the TC30 conditionals/directories/etc. If you want to. I wanted to have the whole thing building so I could hack on the source and see the result. I don't care how messy the build system is. >5) I had to patch LIB/SOURCE/COUNTRY to include an additional component for >PPLC. >5) I had to patch MAIN/SOURCE/PPL/SCRMISC.CPP to add another conditional for >PPLC. > >LIB, MAIN and PPLC all build now. It's late, so I'll do a unified diff >tomorrow and validate it against a fresh copy of 0.004 then post it. > >As an aside, in looking at PCBXDOT that you provided elsewhere, the contents >of pcbkit_l that I made for PPLC is very different than what they were >shipping. So, I probably should rename the pcbkit_l I make in the PPLC >makefile just for future posterity. > >Their PCBKIT_L is simply most of LIB/SOURCE/TOOLKIT/ as a single library. >Their kit does include 2 things we don't appear to have source for: COMMDRV.OBJ >and FOSSIL.OBJ. COMMDRV is the modem multiport board support. CDC omitted that from the source, we can never build it. Doesn't matter anyway, nobody's going to use PCBoard in a high density modem setup. There is code that provides fossil support for standard COM ports, I use it. Perhaps FOSSIL.OBJ was the fossil interface to COMMDRV, so that won't matter either.
where is it?
Trifle Menot
Feb 27, 2013, 11:03:44āÆAM2/27/13
to
On Wed, 27 Feb 2013 07:54:15 -0800 (PST), VinylDoctor
<vinyld...@gmail.com> wrote:
>I can find the edonkey to download this.
>where is it?
If you need a Windows client:
<vinyld...@gmail.com> wrote:
>I can find the edonkey to download this.
>where is it?
www.emule-project.net
Trifle Menot
Feb 27, 2013, 2:01:58āÆPM2/27/13
to
On Tue, 26 Feb 2013 21:54:23 -0800 (PST), Efudd <jason...@gmail.com>
wrote:
>1) I've patched in my PPLC changes.
>2) I moved all of my changes to relative pathing.
>3) I've done a teeny bit of cleanup in the pcboard mak file.
Sounds good.
I may not always be available. If you can package up v0.005 yourself,
that would be great.
a) In pcbsrcv\changes.txt, add the next version number and summarize
your changes. You may notice that all my lines wrap at column 72 and
fill the line without any extra space padding. I keep rewriting the
text until it fits. To me, that's fun, like a crossword puzzle. But
don't worry about that, write the text in your style. You might also
want to put your initials after the version number.
b) Create a new version directory, in this case, 005.
c) Copy lib and main from 004 to 005.
d) Apply your diff to 005.
e) In the pcbsrcv directory, Create new patch files:
> diff -Nru --ignore-file-name-case 004\lib 005\lib >lib.005
> diff -Nru --ignore-file-name-case 004\main 005\main >main.005
and move them into the 005 directory.
f) Delete lib and main from 004. We only need to keep 000, 001, and the
most recent version, in this case, 005.
g) create a zip archive
> pkzip -rP src153.zip @src153.lst
src153.lst:
> di.bat
> dobc31.bat
> src153.txt
> b\c31\*.*
> lib\codebase\*.*
> pcbsrc\*.*
> pcbsrcv\*.*
However, DOS pkzip is reaching its size limit with an archive this big,
you can use any tool that works. This was just to illustrate what needs
to be in the archive.
h) Rename src153.zip to "PCBoard 15.3 source code v0.005.zip".
i) Share it via ed2k and post the link.
Having more than one person sharing it, would be much better than what
we have now.
wrote:
>1) I've patched in my PPLC changes.
>2) I moved all of my changes to relative pathing.
>3) I've done a teeny bit of cleanup in the pcboard mak file.
I may not always be available. If you can package up v0.005 yourself,
that would be great.
a) In pcbsrcv\changes.txt, add the next version number and summarize
your changes. You may notice that all my lines wrap at column 72 and
fill the line without any extra space padding. I keep rewriting the
text until it fits. To me, that's fun, like a crossword puzzle. But
don't worry about that, write the text in your style. You might also
want to put your initials after the version number.
b) Create a new version directory, in this case, 005.
c) Copy lib and main from 004 to 005.
d) Apply your diff to 005.
e) In the pcbsrcv directory, Create new patch files:
> diff -Nru --ignore-file-name-case 004\lib 005\lib >lib.005
> diff -Nru --ignore-file-name-case 004\main 005\main >main.005
and move them into the 005 directory.
f) Delete lib and main from 004. We only need to keep 000, 001, and the
most recent version, in this case, 005.
g) create a zip archive
> pkzip -rP src153.zip @src153.lst
src153.lst:
> di.bat
> dobc31.bat
> src153.txt
> b\c31\*.*
> lib\codebase\*.*
> pcbsrc\*.*
> pcbsrcv\*.*
However, DOS pkzip is reaching its size limit with an archive this big,
you can use any tool that works. This was just to illustrate what needs
to be in the archive.
h) Rename src153.zip to "PCBoard 15.3 source code v0.005.zip".
i) Share it via ed2k and post the link.
Having more than one person sharing it, would be much better than what
we have now.
Trifle Menot
Feb 27, 2013, 2:14:41āÆPM2/27/13
to
On Wed, 27 Feb 2013 19:01:58 +0000, Trifle Menot
<trifl...@protocol.invalid> wrote:
>f) Delete lib and main from 004. We only need to keep 000, 001, and the
>most recent version, in this case, 005.
I forgot to say, delete lib and main from pcbsrc too. It's just the
<trifl...@protocol.invalid> wrote:
>f) Delete lib and main from 004. We only need to keep 000, 001, and the
>most recent version, in this case, 005.
working build directory, and should be empty in the archive, except for
the one batch file, cleanit.bat.
Hmm, now that I think about it, it would be better to fix that in the
src153.lst file:
> di.bat
> dobc31.bat
> src153.txt
> b\c31\*.*
> lib\codebase\*.*
> pcbsrcv\*.*
Efudd
Feb 27, 2013, 7:40:41āÆPM2/27/13
to
On Wednesday, February 27, 2013 2:14:41 PM UTC-5, Trifle Menot wrote:
> *snip*
ed2k://|file|PCBoard%2015.3%20source%20code%20v0.005.zip|33549818|5EA0F9023E15B70C4CBAB8E073D7DD91|/
Let's see how this one goes. I've not shared via ed2k before, so hopefully that's a proper link....
This builds fine on WinXP. PCBoardM and PPLC both build (as well as the
libraries). I didn't test on win98 and will not. Win98 is now dead to me again.
This added PCBXDOT back into the archive.
I modified DOBC31.BAT to add a "root" variable. It defaults to empty.
So just set root=\P or \PCBS or leave it blank depending on where you drop
your source code.
I tested it at root, under subdirectories and through directory renames. I
think all the scripts clean up properly in that case now.
I'm probably done with this for a few days now unless there is something
busted.
-e
> *snip*
ed2k://|file|PCBoard%2015.3%20source%20code%20v0.005.zip|33549818|5EA0F9023E15B70C4CBAB8E073D7DD91|/
Let's see how this one goes. I've not shared via ed2k before, so hopefully that's a proper link....
This builds fine on WinXP. PCBoardM and PPLC both build (as well as the
libraries). I didn't test on win98 and will not. Win98 is now dead to me again.
This added PCBXDOT back into the archive.
I modified DOBC31.BAT to add a "root" variable. It defaults to empty.
So just set root=\P or \PCBS or leave it blank depending on where you drop
your source code.
I tested it at root, under subdirectories and through directory renames. I
think all the scripts clean up properly in that case now.
I'm probably done with this for a few days now unless there is something
busted.
-e
Trifle Menot
Feb 27, 2013, 10:43:17āÆPM2/27/13
to
On Wed, 27 Feb 2013 16:40:41 -0800 (PST), Efudd <jason...@gmail.com>
wrote:
>On Wednesday, February 27, 2013 2:14:41 PM UTC-5, Trifle Menot wrote:
>
>> *snip*
>
>ed2k://|file|PCBoard%2015.3%20source%20code%20v0.005.zip|33549818|5EA0F9023E15B70C4CBAB8E073D7DD91|/
>
>Let's see how this one goes. I've not shared via ed2k before, so hopefully that's a proper link....
Works for me.
>I modified DOBC31.BAT to add a "root" variable. It defaults to empty.
Good idea. I may change it to "basepath" because "root" is used in
PCBOARD.MAK:
>VERSION = 153
>ROOT = ..
>PROJ = $(ROOT)\MAIN
>LIBDIR = $(ROOT)\LIB\BCDOS\$(BCCOMPILER)
Having an environment variable of the same name, "root," suggests it can
override the makefile value, but I know that is not the intent.
>I tested it at root, under subdirectories and through directory renames. I
>think all the scripts clean up properly in that case now.
I tried a pplc build, got a path not found error, and some other
problems:
> del obj\pplc\\pcbkit_l tlib obj\pplc\\pcbkit_l + obj\pplc\\h2name TLIB 3.02 Copyright (c) 1992 Borland International
>Warning: 'H2NAME' already in LIB, not changed!
> tlib obj\pplc\\pcbkit_l + obj\pplc\\dosfopen TLIB 3.02 Copyright (c) 1992 Borland International
>Warning: 'DOSFOPEN' already in LIB, not changed!
> tlib obj\pplc\\pcbkit_l + obj\pplc\\dosfgets TLIB 3.02 Copyright (c) 1992 Borland International
>Warning: 'DOSFGETS' already in LIB, not changed!
> tlib obj\pplc\\pcbkit_l + obj\pplc\\crypt TLIB 3.02 Copyright (c) 1992 Borland International
>I'm probably done with this for a few days now unless there is something
>busted.
Take a break. I'll look at it closer tomorrow, and see what I can do.
Thanks for your work.
wrote:
>On Wednesday, February 27, 2013 2:14:41 PM UTC-5, Trifle Menot wrote:
>
>> *snip*
>
>ed2k://|file|PCBoard%2015.3%20source%20code%20v0.005.zip|33549818|5EA0F9023E15B70C4CBAB8E073D7DD91|/
>
>Let's see how this one goes. I've not shared via ed2k before, so hopefully that's a proper link....
>I modified DOBC31.BAT to add a "root" variable. It defaults to empty.
PCBOARD.MAK:
>VERSION = 153
>ROOT = ..
>PROJ = $(ROOT)\MAIN
>LIBDIR = $(ROOT)\LIB\BCDOS\$(BCCOMPILER)
Having an environment variable of the same name, "root," suggests it can
override the makefile value, but I know that is not the intent.
>I tested it at root, under subdirectories and through directory renames. I
>think all the scripts clean up properly in that case now.
problems:
> del obj\pplc\\pcbkit_l tlib obj\pplc\\pcbkit_l + obj\pplc\\h2name TLIB 3.02 Copyright (c) 1992 Borland International
>Warning: 'H2NAME' already in LIB, not changed!
> tlib obj\pplc\\pcbkit_l + obj\pplc\\dosfopen TLIB 3.02 Copyright (c) 1992 Borland International
>Warning: 'DOSFOPEN' already in LIB, not changed!
> tlib obj\pplc\\pcbkit_l + obj\pplc\\dosfgets TLIB 3.02 Copyright (c) 1992 Borland International
>Warning: 'DOSFGETS' already in LIB, not changed!
> tlib obj\pplc\\pcbkit_l + obj\pplc\\crypt TLIB 3.02 Copyright (c) 1992 Borland International
>I'm probably done with this for a few days now unless there is something
>busted.
Thanks for your work.
Efudd
Feb 27, 2013, 11:06:49āÆPM2/27/13
to
On Wednesday, February 27, 2013 10:43:17 PM UTC-5, Trifle Menot wrote:
> Having an environment variable of the same name, "root," suggests it can
> override the makefile value, but I know that is not the intent.
Ah ha. good catch. renaming it makes sense.
> Having an environment variable of the same name, "root," suggests it can
> override the makefile value, but I know that is not the intent.
> I tried a pplc build, got a path not found error, and some other
>
> problems:
> > del obj\pplc\\pcbkit_l tlib obj\pplc\\pcbkit_l + obj\pplc\\h2name TLIB 3.02 Copyright (c) 1992 Borland International
> >Warning: 'H2NAME' already in LIB, not changed!
> > tlib obj\pplc\\pcbkit_l + obj\pplc\\dosfopen TLIB 3.02 Copyright (c) 1992 Borland International
> >Warning: 'DOSFOPEN' already in LIB, not changed!
> > tlib obj\pplc\\pcbkit_l + obj\pplc\\dosfgets TLIB 3.02 Copyright (c) 1992 Borland International
obj\pplc\*
Odd though. I would have expected the rule for pcbkit, which includes a
command to delete the pcbkit_$(MODEL) to take care of that. I just tried
changing that to pcbkit_$(MODEL).LIB and still see the same attempt to
relink if I rerun pplc.bat.
> Take a break. I'll look at it closer tomorrow, and see what I can do.
> Thanks for your work.
I still get it built, at least....
-e
Efudd
Feb 27, 2013, 11:17:02āÆPM2/27/13
to
re: path not found...
In pplc.mak, line 231..
change 'del $(OBJPTH)\pcbkit_$(MODEL)' to: 'del $(OBJPTH)pcbkit_$(MODEL).LIB'
That'll fix both. It'll introduce "file not found" if the .LIB doesn't exist
to delete (like on an initial build)... but otherwise should be fine.
Apparently that deletion rule in makefile and/or cmd.exe is a little too precise
and gets update if you call "del obj\pplc\\pcbkit_l.lib" ....
-e
In pplc.mak, line 231..
change 'del $(OBJPTH)\pcbkit_$(MODEL)' to: 'del $(OBJPTH)pcbkit_$(MODEL).LIB'
That'll fix both. It'll introduce "file not found" if the .LIB doesn't exist
to delete (like on an initial build)... but otherwise should be fine.
Apparently that deletion rule in makefile and/or cmd.exe is a little too precise
and gets update if you call "del obj\pplc\\pcbkit_l.lib" ....
-e
Efudd
Mar 1, 2013, 12:31:55āÆAM3/1/13
to
trifle - you opposed to git?
I loathe this 001/002/003...
At least for myself, I've moved this all to a unix base, I'm going to put the
revisions under git branches, i've lowercased everything and then just use samba
to mount on windows XP for builds (until I decide to try to do that via dosemu
or something later).
If you are opposed to git, then I'll just write a script on my side to
properly generate the current format upon release....
-e
I loathe this 001/002/003...
At least for myself, I've moved this all to a unix base, I'm going to put the
revisions under git branches, i've lowercased everything and then just use samba
to mount on windows XP for builds (until I decide to try to do that via dosemu
or something later).
If you are opposed to git, then I'll just write a script on my side to
properly generate the current format upon release....
-e
Trifle Menot
Mar 1, 2013, 1:45:05āÆAM3/1/13
to
On Thu, 28 Feb 2013 21:31:55 -0800 (PST), Efudd <jason...@gmail.com>
wrote:
>trifle - you opposed to git?
I'm not categorically opposed to git, but I have no need for it now.
Maybe someday.
Seems like a good time to discuss our respective goals. We perhaps have
some in common, but not all.
On this project I'm like an archaeologist. I want to sift through the
ruins without disturbing them. Trying to clean up the build system is
futile, it's a big mess that cannot be fixed. I don't want to obscure
its history with aesthetic changes that don't fix bugs. Such as:
>diff -Nru --ignore-file-name-case 004/MAIN/153/PCBOARD.MAK 005/MAIN/153/PCBOARD.MAK
>--- 004/MAIN/153/PCBOARD.MAK 2013-02-26 23:46:00.000000000 -0500
>+++ 005/MAIN/153/PCBOARD.MAK 2013-02-27 18:21:30.802593024 -0500
>@@ -136,19 +136,13 @@
> GEN = $(GEN) -DPCB_DEMO
> !endif
>
>-!if $d(386) && ! $d(TC30) # TC 3.0 does not support 386 compilation
> COPT = $(COPT) -3 /DCPU386
> ASMOPT = $(ASMOPT) /DCPU386
>-EXT = 386
>-LIBEXT = 386
>-RES = PCB_$(BCCOMPILER).386
>-!else
>-EXT = RES
>+EXT = LIB
> LIBEXT = LIB
> RES = PCB_$(BCCOMPILER).RES
>-!endif
>
>-LIBS = $(VERSION)\LIBS$(BCCOMPILER).$(EXT)
>+LIBS = $(VERSION)\LIBS_$(BCCOMPILER).RES
>
> #source code generation options
> CODEOPT = -D$(GEN) -D$(COM) -D$(STATS) -D$(NUMNODES) -D$(DRV) -D$(DEFFIDO) -DKEY=KEY_$(NODES)
Don't get me wrong, I appreciate your work on pplc. But once I study it
and understand what you did, I may revise it and release v0.006.
I value our interaction, it has been insightful.
di.bat and dobc31.bat worked well for me, but not when distributed to
other environments. So now I've merged them into one file, pcbsrc.baz,
which is copied to pcbsrc.bat where local changes are kept.
How to proceed, I'm not sure. One step at a time I guess ...
wrote:
>trifle - you opposed to git?
Maybe someday.
some in common, but not all.
On this project I'm like an archaeologist. I want to sift through the
ruins without disturbing them. Trying to clean up the build system is
futile, it's a big mess that cannot be fixed. I don't want to obscure
its history with aesthetic changes that don't fix bugs. Such as:
>diff -Nru --ignore-file-name-case 004/MAIN/153/PCBOARD.MAK 005/MAIN/153/PCBOARD.MAK
>--- 004/MAIN/153/PCBOARD.MAK 2013-02-26 23:46:00.000000000 -0500
>+++ 005/MAIN/153/PCBOARD.MAK 2013-02-27 18:21:30.802593024 -0500
>@@ -136,19 +136,13 @@
> GEN = $(GEN) -DPCB_DEMO
> !endif
>
>-!if $d(386) && ! $d(TC30) # TC 3.0 does not support 386 compilation
> COPT = $(COPT) -3 /DCPU386
> ASMOPT = $(ASMOPT) /DCPU386
>-EXT = 386
>-LIBEXT = 386
>-RES = PCB_$(BCCOMPILER).386
>-!else
>-EXT = RES
>+EXT = LIB
> LIBEXT = LIB
> RES = PCB_$(BCCOMPILER).RES
>-!endif
>
>-LIBS = $(VERSION)\LIBS$(BCCOMPILER).$(EXT)
>+LIBS = $(VERSION)\LIBS_$(BCCOMPILER).RES
>
> #source code generation options
> CODEOPT = -D$(GEN) -D$(COM) -D$(STATS) -D$(NUMNODES) -D$(DRV) -D$(DEFFIDO) -DKEY=KEY_$(NODES)
Don't get me wrong, I appreciate your work on pplc. But once I study it
and understand what you did, I may revise it and release v0.006.
I value our interaction, it has been insightful.
di.bat and dobc31.bat worked well for me, but not when distributed to
other environments. So now I've merged them into one file, pcbsrc.baz,
which is copied to pcbsrc.bat where local changes are kept.
How to proceed, I'm not sure. One step at a time I guess ...
Efudd
Mar 1, 2013, 10:49:34āÆAM3/1/13
to
On Friday, March 1, 2013 1:45:05 AM UTC-5, Trifle Menot wrote:
>
> Seems like a good time to discuss our respective goals. We perhaps have
> some in common, but not all.
*nods*
>
> Seems like a good time to discuss our respective goals. We perhaps have
> some in common, but not all.
> On this project I'm like an archaeologist. I want to sift through the
> ruins without disturbing them. Trying to clean up the build system is
> futile, it's a big mess that cannot be fixed. I don't want to obscure
> its history with aesthetic changes that don't fix bugs. Such as:
Fair enough. Not sure my goals. For the 15+ years I was seeking the source,
my mental model was "pull it current!". Now my goal is just to hack on it.
I actually have a source tree where I ported all the ASM to 32bit and was
at least somewhat successful in linking it with visual studio after dropping
out all the c0 stuff.... that code is actually to the point of needing to
re-implement the console handling ansi assembly code in C... but that tree is
dead to me for now.
So .. if anything my goal is a streamlined tree that can build against BC31
and build the entire package (setup and all). In part for nostalgia and in
part for a baseline for future hacking on it with a good known baseline.
> Don't get me wrong, I appreciate your work on pplc. But once I study it
> and understand what you did, I may revise it and release v0.006.
> di.bat and dobc31.bat worked well for me, but not when distributed to
> other environments. So now I've merged them into one file, pcbsrc.baz,
> which is copied to pcbsrc.bat where local changes are kept.
repository here. I'd started creating scripts for managing my local enviro
outside of the distribution tree for exactly that purpose while maintaining
the "external" view.
> How to proceed, I'm not sure. One step at a time I guess ...
As an aside, I read earlier threads re: copyright. I ended up finding
some mention that fred had tried to sell the source rights for 40k under
another company name post-bankrupcy. Then other indications that Zion bank
owned the rights... did you ever find out anything any different? Zero
intention here other freely sharing code.. just trying to evaluate personal
liability when sharing ~18 year old dead code from a dead company with an
effectively dead user base.
Personally I'd really love to see a drop-in data file compatible version
with native tcp/ip and no comm support for modern OSes exist. The one person
who cares probably would enjoy it anyway. :-)
-e
Trifle Menot
Mar 1, 2013, 11:57:46āÆAM3/1/13
to
On Fri, 1 Mar 2013 07:49:34 -0800 (PST), Efudd <jason...@gmail.com>
wrote:
>Fair enough. Not sure my goals. For the 15+ years I was seeking the source,
>my mental model was "pull it current!". Now my goal is just to hack on it.
Trying to do more than that would be overly ambitious. It required a
dedicated team some years to create it. It would require much more than
a few isolated enthusiasts to renovate it.
>As an aside, I read earlier threads re: copyright. I ended up finding
>some mention that fred had tried to sell the source rights for 40k under
>another company name post-bankrupcy. Then other indications that Zion bank
>owned the rights... did you ever find out anything any different?
No.
>Zero intention here other freely sharing code
"Freely sharing" is not possible, considering the license of PCBoard,
bcc, and codebase. That's one reason I'm not interested in maintaining
a git repo that might start a party. Better to stay under the radar.
>just trying to evaluate personal liability when sharing ~18 year old
>dead code from a dead company with an effectively dead user base.
I doubt CDC/Fred will ever reappear to assert copyright. The license to
codebase is a question I have no desire to probe.
>Personally I'd really love to see a drop-in data file compatible version
>with native tcp/ip and no comm support for modern OSes exist. The one person
>who cares probably would enjoy it anyway. :-)
An interesting goal, if only in our dreams. :-)
wrote:
>Fair enough. Not sure my goals. For the 15+ years I was seeking the source,
>my mental model was "pull it current!". Now my goal is just to hack on it.
dedicated team some years to create it. It would require much more than
a few isolated enthusiasts to renovate it.
>As an aside, I read earlier threads re: copyright. I ended up finding
>some mention that fred had tried to sell the source rights for 40k under
>another company name post-bankrupcy. Then other indications that Zion bank
>owned the rights... did you ever find out anything any different?
>Zero intention here other freely sharing code
bcc, and codebase. That's one reason I'm not interested in maintaining
a git repo that might start a party. Better to stay under the radar.
>just trying to evaluate personal liability when sharing ~18 year old
>dead code from a dead company with an effectively dead user base.
codebase is a question I have no desire to probe.
>Personally I'd really love to see a drop-in data file compatible version
>with native tcp/ip and no comm support for modern OSes exist. The one person
>who cares probably would enjoy it anyway. :-)
VinylDoctor
Mar 1, 2013, 1:06:17āÆPM3/1/13
to
On Friday, March 1, 2013 8:57:46 AM UTC-8, Trifle Menot wrote:
> On Fri, 1 Mar 2013 07:49:34 -0800 (PST), Efudd <jason...@gmail.com> wrote: >Fair enough. Not sure my goals. For the 15+ years I was seeking the source, >my mental model was "pull it current!". Now my goal is just to hack on it. Trying to do more than that would be overly ambitious. It required a dedicated team some years to create it. It would require much more than a few isolated enthusiasts to renovate it. >As an aside, I read earlier threads re: copyright. I ended up finding >some mention that fred had tried to sell the source rights for 40k under >another company name post-bankrupcy. Then other indications that Zion bank >owned the rights... did you ever find out anything any different? No. >Zero intention here other freely sharing code "Freely sharing" is not possible, considering the license of PCBoard, bcc, and codebase. That's one reason I'm not interested in maintaining a git repo that might start a party. Better to stay under the radar. >just trying to evaluate personal liability when sharing ~18 year old >dead code from a dead company with an effectively dead user base. I doubt CDC/Fred will ever reappear to assert copyright. The license to codebase is a question I have no desire to probe. >Personally I'd really love to see a drop-in data file compatible version >with native tcp/ip and no comm support for modern OSes exist. The one person >who cares probably would enjoy it anyway. :-) An interesting goal, if only in our dreams. :-)
I might like git. the jackass just sits for hours and never gets my files. geez, I hope no one ever buys the rights to pcboard. I think I am the only one that ever bought a source license. so everything points to me as letting the source out. good thing it is just a hobby system now. I dought any companys are still using it anymore. clark used to make special versions for people, I heard. even the warez people dont want it anymore. can you send me the updated zip to my email?
> On Fri, 1 Mar 2013 07:49:34 -0800 (PST), Efudd <jason...@gmail.com> wrote: >Fair enough. Not sure my goals. For the 15+ years I was seeking the source, >my mental model was "pull it current!". Now my goal is just to hack on it. Trying to do more than that would be overly ambitious. It required a dedicated team some years to create it. It would require much more than a few isolated enthusiasts to renovate it. >As an aside, I read earlier threads re: copyright. I ended up finding >some mention that fred had tried to sell the source rights for 40k under >another company name post-bankrupcy. Then other indications that Zion bank >owned the rights... did you ever find out anything any different? No. >Zero intention here other freely sharing code "Freely sharing" is not possible, considering the license of PCBoard, bcc, and codebase. That's one reason I'm not interested in maintaining a git repo that might start a party. Better to stay under the radar. >just trying to evaluate personal liability when sharing ~18 year old >dead code from a dead company with an effectively dead user base. I doubt CDC/Fred will ever reappear to assert copyright. The license to codebase is a question I have no desire to probe. >Personally I'd really love to see a drop-in data file compatible version >with native tcp/ip and no comm support for modern OSes exist. The one person >who cares probably would enjoy it anyway. :-) An interesting goal, if only in our dreams. :-)
Efudd
Mar 1, 2013, 1:18:32āÆPM3/1/13
to
On Friday, March 1, 2013 11:57:46 AM UTC-5, Trifle Menot wrote:
> Trying to do more than that would be overly ambitious. It required a
> dedicated team some years to create it. It would require much more than
> a few isolated enthusiasts to renovate it.
Yea, likely true...
> Trying to do more than that would be overly ambitious. It required a
> dedicated team some years to create it. It would require much more than
> a few isolated enthusiasts to renovate it.
> "Freely sharing" is not possible, considering the license of PCBoard,
> bcc, and codebase. That's one reason I'm not interested in maintaining
> a git repo that might start a party. Better to stay under the radar.
to use it can.. those who don't, just stick with the current tree. :-)
--snip--
āā[efudd@wizard] - [~/Projects/pcboard] - [Fri Mar 01, 01:13]
āā[$] <git:(feature/build_cleanup*)> git tag
v0.000
v0.001
v0.002
v0.003
v0.004
v0.005
v0.005a
--snip--
I created release branches for each stage that had been done so far...
merged that code in... and merged it back to master with a tag to match
the state that that time.
TBH, I screwed up directory structures before v0.005a... :-)
My XP VM just mounts that pcboard directory as a drive letter for builds.
> I doubt CDC/Fred will ever reappear to assert copyright. The license to
> codebase is a question I have no desire to probe.
it wouldn't be too difficult to replace the codebase calls with something
free-er like sqlite.
> >Personally I'd really love to see a drop-in data file compatible version
> >with native tcp/ip and no comm support for modern OSes exist. The one person
> >who cares probably would enjoy it anyway. :-)
>
> An interesting goal, if only in our dreams. :-)
again for a few months...
-e
Trifle Menot
Mar 1, 2013, 1:19:26āÆPM3/1/13
to
On Fri, 1 Mar 2013 10:06:17 -0800 (PST), VinylDoctor
<vinyld...@gmail.com> wrote:
>the jackass just sits for hours and never gets my files
The jackass? LOL. You must have something misconfigured. I got v0.005
<vinyld...@gmail.com> wrote:
>the jackass just sits for hours and never gets my files
within an hour from efudd. Test your port setup to be sure you can talk
to the outside world.
>can you send me the updated zip to my email?
put it on 4shared if you still can't ride the donkey. :-D
Efudd
Mar 1, 2013, 1:23:38āÆPM3/1/13
to
On Friday, March 1, 2013 1:06:17 PM UTC-5, VinylDoctor wrote:
> I might like git. the jackass just sits for hours and never gets my files.
I assume by "the jackass" you mean ed2k? load http://upd.emule-security.net/nodes.dat into kad's node database and see what happens...
> I might like git. the jackass just sits for hours and never gets my files.
> geez, I hope no one ever buys the rights to pcboard.
anymore must less an owner offering it up for sell and a buyer appearing.
> I think I am the only one that ever bought a source license.
when they went under. :-)
> can you send me the updated zip to my email?
try the ed2k note thing above.. that may connect you to the correct places.
ed2k is weird...
can work out something else otherwise.
-e
Trifle Menot
Mar 1, 2013, 1:46:49āÆPM3/1/13
to
On Fri, 1 Mar 2013 10:18:32 -0800 (PST), Efudd <jason...@gmail.com>
wrote:
>I meant a .git repository in the released source.. those who know how
>to use it can.. those who don't, just stick with the current tree. :-)
With PCBXDOT, the .zip is already 32meg without a .git repo inside. I
want to keep it small enough to extract on real DOS with pkunzip.
>codebase isn't a huge concern to me. I haven't looked, but I'm betting
>it wouldn't be too difficult to replace the codebase calls with something
>free-er like sqlite.
Codebase is not sql, it's dbase compatible. They provided their source
code, and you can rebuild the codebase lib from its source. I did, and
you have the result.
You can study their source, rewrite their code, and share your work with
a free license (preferably Apache 2.0). Let me know when it's done. ;-)
wrote:
>I meant a .git repository in the released source.. those who know how
>to use it can.. those who don't, just stick with the current tree. :-)
want to keep it small enough to extract on real DOS with pkunzip.
>codebase isn't a huge concern to me. I haven't looked, but I'm betting
>it wouldn't be too difficult to replace the codebase calls with something
>free-er like sqlite.
code, and you can rebuild the codebase lib from its source. I did, and
you have the result.
You can study their source, rewrite their code, and share your work with
a free license (preferably Apache 2.0). Let me know when it's done. ;-)
Trifle Menot
Mar 1, 2013, 1:54:09āÆPM3/1/13
to
On Fri, 1 Mar 2013 10:23:38 -0800 (PST), Efudd <jason...@gmail.com>
wrote:
>ed2k is weird...
But cool, if you're looking for Borland C++ 4.52, or other hard to find
items.
wrote:
>ed2k is weird...
But cool, if you're looking for Borland C++ 4.52, or other hard to find
items.
Trifle Menot
Mar 1, 2013, 2:12:34āÆPM3/1/13
to
On Fri, 1 Mar 2013 10:18:32 -0800 (PST), Efudd <jason...@gmail.com>
wrote:
>??[efudd@wizard] - [~/Projects/pcboard] - [Fri Mar 01, 01:13]
>??[$] <git:(feature/build_cleanup*)> git tag
beat me to it, I'll just bump to v0.007 ...
But let's not consume numbers for every little change, rather, queue up
a batch of changes before releasing. Say, at least a week's worth.
wrote:
>??[efudd@wizard] - [~/Projects/pcboard] - [Fri Mar 01, 01:13]
>??[$] <git:(feature/build_cleanup*)> git tag
>v0.000
>v0.001
>v0.002
>v0.003
>v0.004
>v0.005
>v0.005a
>v0.001
>v0.002
>v0.003
>v0.004
>v0.005
>v0.005a
>TBH, I screwed up directory structures before v0.005a... :-)
If you have a new release before I do, go ahead and use v.006. If you
beat me to it, I'll just bump to v0.007 ...
But let's not consume numbers for every little change, rather, queue up
a batch of changes before releasing. Say, at least a week's worth.
Efudd
Mar 1, 2013, 2:23:42āÆPM3/1/13
to
On Friday, March 1, 2013 2:12:34 PM UTC-5, Trifle Menot wrote:
> If you have a new release before I do, go ahead and use v.006. If you
> beat me to it, I'll just bump to v0.007 ...
> But let's not consume numbers for every little change, rather, queue up
> a batch of changes before releasing. Say, at least a week's worth.
I'm gonna wait for your next release anyway...
> If you have a new release before I do, go ahead and use v.006. If you
> beat me to it, I'll just bump to v0.007 ...
> But let's not consume numbers for every little change, rather, queue up
> a batch of changes before releasing. Say, at least a week's worth.
Efudd
Mar 2, 2013, 1:19:32āÆAM3/2/13
to
... Well, poo.
I decided to start building some of the utilities. First with pcbsetup.
The make file there wants to link against vmdata.lib. A little more digging
through the various source code confirms other requirements for the same.
I THINK that this is referring to VMData for DOS that was manufactured by
Pocket Soft. No luck in finding it... I've not yet looked to see what
functionality the code uses from it.
Interestingly enough, pocket soft still exists... I think I'll email them.
-e
I decided to start building some of the utilities. First with pcbsetup.
The make file there wants to link against vmdata.lib. A little more digging
through the various source code confirms other requirements for the same.
I THINK that this is referring to VMData for DOS that was manufactured by
Pocket Soft. No luck in finding it... I've not yet looked to see what
functionality the code uses from it.
Interestingly enough, pocket soft still exists... I think I'll email them.
-e
VinylDoctor
Mar 2, 2013, 3:36:38āÆPM3/2/13
to
On Friday, March 1, 2013 10:19:26 AM UTC-8, Trifle Menot wrote:
> On Fri, 1 Mar 2013 10:06:17 -0800 (PST), VinylDoctor <vinyld...@gmail.com> wrote: >the jackass just sits for hours and never gets my files The jackass? LOL. You must have something misconfigured. I got v0.005 within an hour from efudd. Test your port setup to be sure you can talk to the outside world. >can you send me the updated zip to my email? I've already got updates queued for v0.006. When that's ready, I will put it on 4shared if you still can't ride the donkey. :-D
ok thanks, I will wait for the 4shared
> On Fri, 1 Mar 2013 10:06:17 -0800 (PST), VinylDoctor <vinyld...@gmail.com> wrote: >the jackass just sits for hours and never gets my files The jackass? LOL. You must have something misconfigured. I got v0.005 within an hour from efudd. Test your port setup to be sure you can talk to the outside world. >can you send me the updated zip to my email? I've already got updates queued for v0.006. When that's ready, I will put it on 4shared if you still can't ride the donkey. :-D
Efudd
Mar 2, 2013, 8:39:41āÆPM3/2/13
to
.. long thread is long ...
pcbdiag now builds and runs. It made me realize there is the potential for
hard to track run time failures if you link against the wrong thing. For
example, there is a function to read the pcboard data file... one in library
toolkit and one in library pcb.
If you link against the one in toolkit... it doesn't error.. and fills in
SOME of the appropriate data structures. If you link against the one in
pcb, everything works as one would hope.
It looks like the LIB/SOURCE/TOOLKIT were basically stub versions of many
functions that were implemented elsewhere. Those stub versions were what
got shipped to developers writing software to add on to PCBoard... at least,
that is what it appears.
Also, it seems that the version of code this is does NOT match the shipping
release of 15.3. For example, there is a simple conditional bug in the diag
utility code that prevents it from ever returning how the shipping diag
utility ran....
-e
pcbdiag now builds and runs. It made me realize there is the potential for
hard to track run time failures if you link against the wrong thing. For
example, there is a function to read the pcboard data file... one in library
toolkit and one in library pcb.
If you link against the one in toolkit... it doesn't error.. and fills in
SOME of the appropriate data structures. If you link against the one in
pcb, everything works as one would hope.
It looks like the LIB/SOURCE/TOOLKIT were basically stub versions of many
functions that were implemented elsewhere. Those stub versions were what
got shipped to developers writing software to add on to PCBoard... at least,
that is what it appears.
Also, it seems that the version of code this is does NOT match the shipping
release of 15.3. For example, there is a simple conditional bug in the diag
utility code that prevents it from ever returning how the shipping diag
utility ran....
-e
VinylDoctor
Mar 3, 2013, 9:21:03āÆPM3/3/13
to
On Saturday, March 2, 2013 5:39:41 PM UTC-8, Efudd wrote:
> .. long thread is long ... pcbdiag now builds and runs. It made me realize there is the potential for hard to track run time failures if you link against the wrong thing. For example, there is a function to read the pcboard data file... one in library toolkit and one in library pcb. If you link against the one in toolkit... it doesn't error.. and fills in SOME of the appropriate data structures. If you link against the one in pcb, everything works as one would hope. It looks like the LIB/SOURCE/TOOLKIT were basically stub versions of many functions that were implemented elsewhere. Those stub versions were what got shipped to developers writing software to add on to PCBoard... at least, that is what it appears. Also, it seems that the version of code this is does NOT match the shipping release of 15.3. For example, there is a simple conditional bug in the diag utility code that prevents it from ever returning how the shipping diag utility ran.... -e
yes. I think the toolkit was not needed for pcboard. it was like you said, for developers so they could see how to write addons for pcboard. it's just in my stuff because thats what they sent me on disc when I bought my license.
> .. long thread is long ... pcbdiag now builds and runs. It made me realize there is the potential for hard to track run time failures if you link against the wrong thing. For example, there is a function to read the pcboard data file... one in library toolkit and one in library pcb. If you link against the one in toolkit... it doesn't error.. and fills in SOME of the appropriate data structures. If you link against the one in pcb, everything works as one would hope. It looks like the LIB/SOURCE/TOOLKIT were basically stub versions of many functions that were implemented elsewhere. Those stub versions were what got shipped to developers writing software to add on to PCBoard... at least, that is what it appears. Also, it seems that the version of code this is does NOT match the shipping release of 15.3. For example, there is a simple conditional bug in the diag utility code that prevents it from ever returning how the shipping diag utility ran.... -e
0 new messages